Re: [tcpm] TCP tuning

[Jerry Chu <hkchu at google.com>]

Hi John,

On Wed, Feb 3, 2010 at 12:32 PM, John Heffner <johnwheffner at gmail.com> wrote:
> I would like to see tcpm take on the initial window issue, though as
> Joe notes we probably do not yet know enough to formally take this on
> as a charter item.  (Or, would this be a tsvwg item due to possible
> wider impact?)
>
> A couple thoughts:
> - A large initial window should probably only be used by mutual
> agreement.  Maybe via a TCP option during the handshake?

This may not be needed. A receiver can effectively constrain the
sender's window by advertising a smaller initial receive window.

Obviously this works for only the initial window, not the restart window.
(Oh, on a second thought this can be made to work for the restart
window too.)

> - A significant increase to the initial window might benefit from
> introduction of some form of pacing, since you won't have any ack
> clock yet.  This might help reduce losses and delay jitter.

Agreed. The question is, what is that threshold of window/burst size
beyond which pacing is required. My current guess is > 10.

Jerry

>
>  -John
>
>
>
> On Wed, Feb 3, 2010 at 9:28 AM, Lars Eggert <lars.eggert at nokia.com> wrote:
>> Hi,
>>
>> Jerry Chu has recently started the discussion on whether we need to think about tweaking TCP for the "modern Internet." Just came across another presentation from (AFAICT) another corner of Google that makes similar arguments.
>>
>> FYI: http://sites.google.com/a/chromium.org/dev/spdy/An_Argument_For_Changing_TCP_Slow_Start.pdf
>>
>> This topic seems to be gaining momentum, and the WG should take some time considering if there is work here for it.
>>
>> Lars
>> _______________________________________________
>> tcpm mailing list
>> tcpm at ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>>
> _______________________________________________
> tcpm mailing list
> tcpm at ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>