Re: [tcpm] Increasing the Initial Window - Notes

[Jerry Chu <[e-mail]>]

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,

TCP's slow start being too slow for not just HTTP traffic but also
median size data
transfers has been a well-known issue in the community and active research on
faster startup schemes has been ongoing for years. But you seem to be against
the rest of us and saying this is not a problem at all?

>
> and probably other networks too, operates multi-hop radio networks with a
> bandwidth of less then 100kB/s.

Folks from Nokia have been actively investigating the effect of IW10 in a radio
network so I'll defer to their findings. I'd only make two points from
our testbed
study on slow (96Kbps) links:

1. There is no denying that IW10 tends to cause higher packet drop rate during
congestion. (Don't get too turned off by some high packet drop rate in my slides
because some of the testcases were designed to be extreme in order to get to
the worst case, and it looks like the worst case we've found for IW10, it was
also terrible for IW3 (e.g., UCT > 50secs).

2. Regardless of IW10's higher packet drop rate, it's flow completion time has
been consistently better, or at least not worse than IW3's. Some explanation
of it was given in my slides.

3. In a multi-hop multi-congestion-point mobile network the high packet drop
rate may cause more damage due to the waste of bandwidth on the path
leading to the final congestion drop point. Our testbed has only one congestion
point so doesn't exhibit this problem. I think folks from Nokia are concerned
with this problem and I'll defer this to them.

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

Do you have any real numbers to backup your claim here? Numbers from our live
tests at Google's frontends seem to contradict to your statement here.

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

See past email threads and slides.

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

You are late to the party :). All the above and more has been
presented/discussed/
debated in the past already. To make it short, we first tried tweaking Linux dst
cache like you described above but found it not very effective (e.g., cache hit
rate was low...) Then we tried an off-line history database approach
but found it
too complicated. Finally we decided a moderate increase of IW is the right, and
timely solution (until someone else like you could find the optimal or
completely
scalable solution to solve the global warming problem :). Following the KISS
principle, we'd open to any amendment based on info collected during 3WHS
but will be prejudiced against any other states that need to collected and kept
from the past.

I see your name on the attendee list. If you like to chat more you can find me
at CONEX this morning. I'll probably take a front row seat there.

Best,

Jerry

>
>
> Best regards, Hagen