Subject: Re: [tcpm] draft on congestion window limiting

From: "Armando L. Caro, Jr." <[email-masked]>
Date: Mon, 06 Feb 2006 19:54:51 -0500

Jana,

I finally got around to reading this draft. I don't have much to add to
the discussion. I agree that experimenting should be done. I wonder how
much micro-bursts are a concern given that macro-bursts exist. Are
micro-bursts just a little bit of noise in the bigger scheme of things,
or do they really add up when you aggregate many TCP flows?

I also have some comments below...

Janardhan Iyengar wrote:

> As far as the buggy receiver is concerned, I'm not sure that we should
> aim to demonstrate trade-offs in such cases. But, IIUC, your core point
> is that under the same conditions, a sender with burst-mitigation might
> be at a disadvantage with respect to a sender without burst-mitigation.
> There is also the possibility that a sender without burst-mitigation
> loses packets in the network due to the burst when a sender with
> burst-mitigation does not. So, I agree that there is a tradeoff. And
> that we should write it out clearly.

Well, this tradeoff is fairly obvious I think. You could include for
completeness I suppose. I'm not too concerned about this topic, because
we always face this tradeoff when dealing with correct congestion
control. Correct congestion control almost always trades off a sender's
throughput with the network's health. So, if sender's wanted to be
greedy, they COULD avoid congestion control altogether. However, we
don't see this as a default behavior in major operating systems.

Nit picky comments...

First sentence in Section 2: your missing the word "sender" after "TCP".

Second paragraph in Section 3: I would end add another sentence to the
end of the paragraph: "Also, CWV is unnecessary if CWL is used."

Second paragraph in the first bullet of Section 3: I find this paragraph
confusing. The sentence "An additional drawback..." seems out of place
here. What's the other drawback? The beginning of the paragraph goes
back and forth of whether two controls are good or not, so this sentence
threw me off.

Again, I think that experimenting should be done to determine whether
micro-bursts are an issue or not. Unfortunately, I don't have
suggestions of where to start. I'll need to think more on that topic...

-- 
Armando

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: John Heffner <[email-masked]>
Date: Tue, 7 Feb 2006 15:36:17 -0500

Janardhan Iyengar wrote:
> Pasi,
> 
> Thank you for your comments, and for spending your time on this document.
> 
>> I believe experimenting with burst mitigation algorithms in real
>> networks could be possible for many of us. At least Linux has
>> implemented a similar scheme for years, though I don't know what's the
>> status of TCP in the latest kernel versions.
> 
> 
> Thank you for this bit of information. The scheme mentioned in the paper 
> looks like the "Use it or Lose it" scheme mentioned in the draft. I did 
> probe the Linux community recently about whether a micro-burst 
> mitigation scheme was deployed in Linux. The response I got was that 
> there wasn't any such scheme currently deployed, but patches were 
> available. I am not sure at this time if there is or isn't a scheme in 
> Linux (I haven't looked at the code myself yet). I would be happy if 
> someone could confirm for me which one is currently the case.

Linux does implement a somewhat similar scheme, with the primary 
differences being that it only applies the burst limit upon exit from a 
reorder/recovery state rather than on every ack, and it does not set ssthresh 
when reducing cwnd.  This actually makes its behavior substantially 
different.

One issue I see is if the delayed ack factor is greater than BLimit/MSS 
this breaks.  Or for that matter, if there are persistent stretch-acks, say, 
from a cpu-bound receiver or reordering on the reverse path.  Actually, I 
think persistent reordering on the forward path also causes problems.

I'm wondering if setting BLimit to the initial window may be too conservative.  
If I have a 1000 segment window, most likely a burst of 5 segments isn't 
going to hurt too much.

As for (dis)inscentives, some of this competing bursting/non-bursting senders 
issue is described in "Understanding the Performance of TCP Pacing" by 
Aggarwall, et. al. 
(http://www-cse.ucsd.edu/~savage/papers/Infocom2000pacing.pdf).  Though this 
isn't pacing as they describe it, I think some of the issues are very 
similar.

  -John

---

From: Pasi Sarolahti <[email-masked]>
Date: Wed, 08 Feb 2006 09:25:00 +0200

> don't see this as a default behavior in major operating systems.

Well, this is an experimental modification that makes TCP sender
behaviour more conservative than "correct congestion control" by
reducing cwnd after FlightSize drops suddenly. So it might be worthwhile
to think about possible scenarios for a while, to figure out if there
are cases (due to network behaviour, or due to behaviour of the other
end) where this approach could be unnecessarily disadvantageous compared
to the standard and "legal" TCP flows. Buggy receivers was not the best
of examples, but I was looking for a possible case where FlightSize
would be frequently reduced by more than BLimit for some reason, and
thereby TCP sender would not be able to increase its cwnd in a normal
way. Some nonconventional SACK flavor, or a buggy delayed ack
implementation is obviously a problem that receiver itself should fix,
but on the other hand, at the same time your neighbour might be able to
deliver the data effectively just by following the standard congestion
control rules.

The other side of the trade-off is that it is unknown how harmful
transient micro-bursts are, and whether they are better dealt with
Active Queue Management, Rate-based pacing, or some other mechanism.

- Pasi