Re: [tcpm] Increasing the Initial Window - Notes

["Anantha Ramaiah (ananth)" <[e-mail]>]

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