[tcpm] Increasing the Initial Window - Notes

[Hagen Paul Pfeifer <[e-mail]>]

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