Re: [tcpm] Increasing the Initial Window - Notes

[Yuchung Cheng <[e-mail]>]

Hagen,

Please see my earlier response to the caching suggestions and
simulation/experiment questions.

Our draft suggests TCP MAY set the initial window of 10. The host can pick
their best initial cwnd based on their network properties if appropriate or
implement  RFC2140.

If raising IW upper bound is too aggressive and should be rejected as a MAY
clause, I argue IW3 is also too aggressive for some networks too. But RFC
3390 suggests raising IW3 primarily because of web objects size distribution
at that time. Further, we do not propose changing the response function of
TCP, which is the most critical part of maintaining the network stable.

Let's do a reality check: today browsers open tens of flows simultaneously
to work around small TCP IW (http://www.browserscope.org/  the "network
tab). A study from AT&T and U of Mich also show 15% TCP flows observed in
AT&T network already go over IW3. We want to bring this issue to the IETF
community/experts to stop this downward spiral of sneaky unfair latency
"tune-ups".

Cheers,

Yuchung



On Wed, Nov 10, 2010 at 7:29 AM, Hagen Paul Pfeifer <[e-mail]> wrote:

> Cause tomorrow Jerry will talk about the IW10 topic my 50 cents in advance.
> First some skeptical notes, secondly a alternative approach to increase the
> IW.
>
> I am skeptical about this draft because IMHO renounce the conservative
> principle
> towards a aggressive and HTML centric approach (the HTML example is a bad
> allegation, but for FTP and friends slow start is fast enough ;-). My
> costumer,
> and probably other networks too, operates multi-hop radio networks with a
> bandwidth of less then 100kB/s.
>
> An increased IW of 10 define 10*~MSS byte as the smallest atomic in-flight
> value. New data are always pushed into the network in this quantum - a way
> to
> much for the standard TCP CC mechanism to tune into a steady state for
> network
> with a low BDP.
>
> In the discussion I miss the impact of the proposed modification regarding
> networks that operates already at a functioning boundary. Are we at a time
> where we loss these types of networks? Where are the simulation results
> that
> show that the impact at this kind of networks is acceptable?
>
>
>
> Alternative idea: can we shift the idea towards a more robust basis. What
> about
> a increased IW of 10 if we know that the path is capable of an increased
> IW?
>
> Pseudo Algorithm for a new connection:
>
>        a) No cached CC data available
>
>                IW = 4 (standard mechanism a la RFC 5681, 3390)
>                CC mechanism as usual but save CC parameters - especially
> cwnd - per route
>
>
>        b) CC data per route is available
>
>                IF (cached_cwnd >= 10)
>                        IW = 10
>                else
>                        IW = 4
>
>
> After n minutes, previously saved CC data is marked as invalid, similar to
> the
> existing "back to slow start after n minutes idle" mechanism.
>
> Idea: networks with a low BDP will signal by packet drop or ECN marking
> that
> congestion occur and the BDP is saturated. Why not use actual network
> information to setup the IW but preserve the conservative nature of TCP?
>
> Maybe this is an approach for further discussions, I have a curious feeling
> that in 2 years the same discussion will start with a IW of 23 ... So maybe
> we
> should drop the static IW approach completely and define IW as
> cached_steady_state_cwnd / 2 for cached routes and IW = 4 for startup all
> other
> cases.
>
>
> Best regards, Hagen
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>