Subject: [Tsvwg] Re: draft quick start comments part 1 of: C : Compressed N values

From: Sally Floyd <[email-masked]>
Date: Sat, 25 Mar 2006 20:02:47 -0800

Mitchell -

>	  Compressed N values: 
>
>         C) 3.1 Rate request table.
>
>	This request rate table has a major implied over-subscription
>	problem as N increases. Why?
>
>	If a rate request of 700,000 kbps is needed a requester
>	is forced to specify a N= 15 value. This N value forces
>	a waste of approx 610kbps during QS. It is then wasting
>	almost 45% of the needed bandwidth.
>
>	In theory, IMO the N values should increase, but significantly
>	less dramaticly. If my B suggestion of removing the lower
>	N values, then the rate request table could look something
>	like this. These numbers were just thown out to "TRY" to
>	allow a rate request and minimize the amount of waste.

There have been other proposals for more fine-grained rate encodings;
you could look at Appendix A.2 of draft-ietf-tsvwg-quickstart-02.txt
for some examples.  However, my own (strong) view is that a
powers-of-two encoding is an appropriate encoding for Quick-Start,
because Quick-Start is not intended for a fine-grained optimization
of throughput.  Further, flows using Quick-Start can continue in
slow-start and double their sending rates each subsequent round-trip
time, if allowed by the transport protocol.

If Quick-Start is approved for Experimental and deployed in controlled
scenarios, then we can learn more about what is needed from Quick-Start
encoding functions.

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

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

---

From: Mark Allman <[email-masked]>
Date: Tue, 28 Mar 2006 13:01:32 -0500

> There have been other proposals for more fine-grained rate encodings;

For quite a while I wanted to be more fine-grained in the request and
response.  But, I have come around to Sally's way of thinking on this.
We really need to keep our eye on the ball here.  We're trying to get
the sending rate boosted into the ballpark of OK quite fast.  And, we're
only doing this on uncongested networks whereby the contention for the
resources is not the overwhelming concern.

FWIW.

allman

---

From: Erblichs <[email-masked]>
Date: Wed, 29 Mar 2006 23:24:30 -0800

Mark Allman,

	First, what is "OK quite fast"?

	Second, you are trying to move from basicly a single RTT
	time well into CA that could would have taken 100s to 1000s 
	of RTTs in standard TCP.

	Third, we are discussing this proposal given the 3.1 rate
	request table with surgical changes that have a extremely
	high benefit to cost ratio. The other fined grained proposals
	need to be discussed separately.

	THUS, Please tell me what are the negative reasons for increasing
	the number of requested bit rate plateaus with the allocation
	of say 5 bits for N to remove the power-of-two increment.

	Please let Murphy's requestor of a needed 700kbits and
	forcing a N=15 1,3xx,000 kbits be used as the worst case
	example.

	Secondly, a multiple hop path will 99% most likely traverse
	multiple bit rate capacity links. If we assume the most simple
	case of making them equal in bit rate capacity and only a single
	ingress router and 1 egress router for the path. If we also
	assume 5,000,000 kbits is the path bit rate, no previous bit
	rate consumption, and any request that puts the sum of 50% or
	greater request usage will fail, then the results are:

	Current
	--------
	1st 1,3xx,000 request : pass
	2nd 1,3xx,000 request : failed : 
			Request Utilization is 1,300,000/5,000,000 = 26%
			Actual  Utilization is 700,000  /5,000,000 = 14%

	Proposeed
	1st - 3 requests pass of 700,000 kbits = 2,100,000 / 5,000,000 =
	Request and Actual Utilization = 42% of 50% max

	Yes, in the current bit rate table, smaller requests can still
	consume utilization, however the actual will remain below 25%.

	This is easily fixed by removing the power-of-two increments
	with either a higher minimium or 32 bit rates using 5 bits.

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

Mark Allman wrote:
>   ------------------------------------------------------------------------