Re: [tcpm] Increasing the Initial Window - Notes

[Jerry Chu <[e-mail]>]

Anantha,

Thanks for point out the following to Hagen. Yes I must apologize. The
draft has been
overdue for a major revision for a while. We first tried to do it
after summer IETF but
were all busy with other work (and some involves new "Make the Web Faster"
proposal to IETF that we will present in the near future). We will try
to get a major
revision done and published before year end. In the meantime one has
to go back to
the list and slides from the past.

Thanks,

Jerry

On Wed, Nov 10, 2010 at 8:04 AM, Anantha Ramaiah (ananth)
<[e-mail]> wrote:
> I think the stuff which you are suggesting below has already been
> mentioned in earlier conversations (mailing lists, online during the
> earlier presentations). Things like "tomorrow someone will come with IW
> = 23 etc.,", using the cached information also has been mentioned. The
> IW=10 is a fundamental change to TCP and hence the suggestion of moving
> this work item to ICCRG also was mentioned before. Someone also pointed
> out "will this work in Africa"?  Also using a TCP option to agree upon
> the IW was mentioned (which is probably less useful since you have to
> wait for the 3 way HS to complete and also it is not about end hosts
> supporting higher IW, it is about the network property as you rightly
> mention below)
>
> Actually it would be nicer if the authors mention these things in the
> document and respond with what their stance is on each of the questions.
> This way anyone who reads the document are well informed of the current
> stance.
>
> $0.02,
> -Anantha
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Hagen Paul Pfeifer
> Sent: Wednesday, November 10, 2010 7:29 AM
> To: Jerry Chu; tmrg; Matt Mathis; tcpm; Lars Eggert
> Subject: [tcpm] Increasing the Initial Window - Notes
>
> 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
>