Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes

[David Borman <[e-mail]>]

I've been thinking about the whole IW issue, and trying to step back a bit from IW itself.  So I ask myself, what is the main issue with having a large IW?  If the network has the bandwidth, there isn't any practical problem.  But if the network doesn't have the bandwidth, a bunch of TCP connections starting up with a larger IW can lead to congestion.  So then I ask myself, what is wrong with congestion?  The data is going to back up somewhere, so does it matter?  Of course, the answer is that yes, it does matter, because we don't have a lossless network.  When there is congestion in routers, if there isn't enough buffering, the way to deal with that is to drop packets, which in turn leads to retransmissions.

But I don't think it is congestion itself and the dropping of packets that is the problem, the issue is we don't want that congestion to turn into congestion collapse.  So, it seems to me that the issue about whether or not it is safe to increase the IW should be focused more on, if increasing the IW leads to increased congestion, is the network still able to properly respond to that congestion and avoid congestion collapse?  If the answer is "yes", then I think that greatly reduces the risks of increasing the IW.  But if the answer is "no", then we have a bigger problem that is lying in wait and can be triggered by other factors than just increasing the IW.

			-David Borman


On Nov 17, 2010, at 1:58 AM, Alexander Zimmermann wrote:

> Hi Richard,
> 
> exactly, this is the point!
> 
> IMO, two things are crystal clear:
> 
> 1. We have to touch/increase the IW
> 2. We have to do it now
> 
> Also, IMO he have a rough consensus on these two points.
> 
> What I like two see now, or discuss now, is a strategy how we can progress.
> 
> Mark proposed something, but what are thoughts from the document author/
> other group members/chairs/AD on this point?
> 
> Alex
> 
> Am 16.11.2010 um 17:41 schrieb Scheffenegger, Richard:
> 
>> 
>> Group,
>> 
>> Just one additional data point: Obviously, there are already applications in the wild, that use persistent connections and disable the slow-start-restart mechanism on these sessions. The expectations of the programmers making use of these socket options is to reduce the latency for their appliaction... In effect, these Apps seem use IW=44 (and hurting themselves more than anybody else).
>> 
>> See "Profiling Network Performance in Multi-Tier Data Center Applications", Section 6.1, "cwnd failing to prevent sudden bursts", http://www.cs.princeton.edu/~jrex/papers/snap10.pdf
>> 
>> 
>> IMHO this is evidence that some action in this space is absolutely needed (even if it is "only" strong advice to apps programmers), or there will be even more proliferation of clumsy workarounds that are even less well understood and investigated than IW10 already is. Keeping IW3 "forever" may be more problematic than addressing emerging application needs with well-tested transport-layer approaches...
>> 
>> 
>> Richard Scheffenegger
>> 
>> 
>>> -----Original Message-----
>>> From: Fred Baker [mailto:[e-mail]] 
>>> Sent: Dienstag, 16. November 2010 15:10
>>> To: "Ilpo Järvinen"
>>> Cc: tcpm; tmrg
>>> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes
>>> 
>>> 
>>> On Nov 16, 2010, at 10:01 PM, Ilpo Järvinen wrote:
>>> 
>>>> On Tue, 16 Nov 2010, Fred Baker wrote:
>>>> 
>>>>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote:
>>>>> 
>>>>>> I wonder what factors will argue that the initial quantum 
>>> can't be changed?
>>>>>> Someone has argued in the past IW10 effectively "disable 
>>> CC algorithm".
>>>>>> But haven't we already done that years ago when moving up 
>>> IW from 1 
>>>>>> to 3 if one insisted then that the initial quantum must be 1?
>>>>> 
>>>>> Actually, no. I may be the person who said that this effectively 
>>>>> disables congestion control in the average case; my reason 
>>> for saying 
>>>>> that is that per what little data I have, the average TCP 
>>> transfer is 
>>>>> on the order of 15K bytes, which is about ten 1460 byte segments.
>>>> 
>>>> It only "disables" it if there was no congestion to control in the 
>>>> first place.
>>> 
>>> How do you turn off something that's not on?
>>> 
>>> I refer to this as in the average case turning off congestion 
>>> control because the transmission requires ten data packets 
>>> and they all get sent in a single burst. There is no 
>>> congestion control, with IW=10, in the case of the 
>>> average-sized (which is actually gar above the median-sized) 
>>> file transfer.
>>> 
>>>> Could you on your behalf answer how does IW=3 affect 
>>> parallel sessions 
>>>> on the same kind of environment? ...I've done research on this (and 
>>>> Jerry has
>>>> too) and I know that the answer is not an intuitive one. Then we 
>>>> changed to IW10 in the same environment and observe no (consistent) 
>>>> change. The results are driven by problems already with IW3 so IW10 
>>>> won't make it any worse or the effect is just too small to 
>>> be measured 
>>>> among the other troubles that happen.
>>> 
>>> That may be true. I have asked to see data describing the 
>>> impact. I haven't seen the data. Maybe I missed something?
>>> _______________________________________________
>>> tcpm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>> 
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
> 
> //
> // Dipl.-Inform. Alexander Zimmermann
> // Department of Computer Science, Informatik 4
> // RWTH Aachen University
> // Ahornstr. 55, 52056 Aachen, Germany
> // phone: [phone], fax: [phone]
> // email: [e-mail]
> // web: http://www.umic-mesh.net
> //
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm