Subject: [Tsvwg] Re: draft quick start comments part 1 of: B : no small N values

From: Sally Floyd <[email-masked]>
Date: Sat, 25 Mar 2006 19:57:13 -0800

Mitchell -

>	No small N values:
>
>	B) 3.1 Rate request table.
>
>	I can understand the N = 0 value, but the other
>	N=1, N = 2, .... lower values IMO are redundant
>	to normal slow start.
>
>	Slow start gives us 4 MTU sized segments which is
>	equal to 1,500bytes per normal IP MTU * 4MTU segs * 8 bits/byte
>	equals 48k bits.
>
>	If the lower values are not equvalent to slow start
>	for wireless or any other type of connection, then why? What 
>	do we gain, with small N values vs TCP slow start?

Slow-start gives an initial window of at most 4380 bytes (35 Kb)
[specified in RFC 3390].  Some of the wireless scenarios interested
in using QuickStart have round-trip times greater than one second,
so slow-start gives them an initial sending rate of less than 18
Kbps.  In such a scenario, a rate request of 80 Kbps could be quite
useful.

- Sally
http://www.icir.org/floyd/

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Erblichs <[email-masked]>
Date: Mon, 27 Mar 2006 11:35:47 -0800

Sally Floyd,

	You are the expert, but I think QS is solving
	a different item than what you are stating here..

	QS potentially significantly reduces the number of 
	round trips to allow a flow to achieve a application / link
	bandwidth equality.

	The difference in 80kbps and 35kbps is 1 round trip
	time assuming we set slow start thresh-hold high
	enough.

	However, slow start on 100Mbps links requires my
	guess hundreds of round trips without a congestion
	event to achieve 90%+ utilization and

	potentially many thousands with 1 - 10Gb links.

	So, sorry, QS is a potentially "fantastic" way to
	move from slow-start far into congestion-avoidance
	within a few round trip times.
	
	And in my opinion should be skewed to achieve this.

	This is wasted for wireless environments where potentially
	many dropouts (congestion events) are normal AND

	Lastly, a moot point is that most of my experiences with
	wireless has 100 - 250 millisecs round trip times and that
	anything greater than 1 sec RTT, is going to need other
	mods to prevent coarse time-outs from occuring. My later
	suggestions leave 2 reserved bits, where one of them could
	be used to suggest a 5 or a 10 sec time-out. Without this
	IMO, false retransmits are going to be a bigger issue with
	longer RTT.

	Mitchell Erblich
	-------------------