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

[Alexander Zimmermann <[e-mail]>]

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
//