Subject: Re: [Tsvwg] draft quick start comments part 1 of: D : sums of Requested rates

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

Mitchell -

>	Sums of Requested rate
>
>	D) If you accept that requestors are forced to choose
>	the best N value (I will cover A.2 Exact request rate
>	later), then we must acknowledge that the sums of the
>	requested rates must be greater than the amount of
>	available bandwidth to fully utilize the link's
>	capacity.
>
>	This somewhat clarifies why the 2. Assumptions ...
>	should take into account that the "approve a request
>	for a higher sending rate if the output link is
>	underutilized".
>
>	My suggested added principle:
>
>	A QS aware router should not deny a request based just
>	on the current sums of the requested rates.

I think that a router will have to consider the current sums of the
requested rates, and I will try to clarify this in the draft.

QS is intended to be completely discretionary on the part of the
router, with any router free to deny any QS request for any reason
it would like.  The draft is quite careful not to specify the
algorithms used by routers in processing QS requests.  The only
standardization is in the *semantics* of approving a QS request,
in the first paragraph of Section 3.3:

  "A router should only approve a Quick-Start
  request if the output link is underutilized, and if the router
  judges that the output link will continue to be underutilized if the
  request is approved."

I will add more to the draft about why the document does not
specify the algorithms for use in routers (or in the IP layer of
end nodes) for approving QS requests.

- 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 13:35:12 -0800

Sally Floyd,

	An alternative is to code N equal to 5 bits which could
	still keep the wireless rates and decrease the diff
	between values.

	----------

	But given a 4 bit N value........

	The problem lies with the DIFFERENCEs of the  N
	values in our example. A simple set of random values
	ranging in the higher N values should show the problem
	with the power-of-two increments.

	A non random set could be 50,000, 100,000, 200,000,
	300,000, 400,000, 500,000, 600,000 = 2,150,000 against
	aprox 2,800,000 approval which is a 75% usage and will
	can quickly drop to close to 50% and we approach N=15.

	The requestors are the entities that select their kbps 
	values. Without requiring (impossible to enforce) that 
	the requestors select the min of the N value and their
	wished value, the selected N value rate HAVE to be
	50% on average INCORRECT.

	Much smaller N rate differences will guarantee that
	the N value requested CAN Closely match the needs of
	the requestor.

	If we were able to force the requestors to minimize the
	N values or have routers assume over-subcription and
	minimize the values themselves. Assuming that we are in
`	Congestion Avoidance, the requestor could be force to
	generate many round trip times to achieve the utilization
	of the link that was originally supposely significantly
	removed by QS.

	FYI, if you were interested, the reasons why I don't
	like either suggestion is..

		First, if we assume that requestor flows make
		make a significant percentage of new flows.

		For the linear N=15 power of two rate to be
		spread over 15 values approx 86k diff will
		exist between the rate values.

		Is their really a need to have a requestor 
		exactly request its rate if we limit the
		differences to be on the order of 10% when
		we use 4 bits for N?

		Could we suggest a "final rate request" to match
		the requested table? What would be the result if
		a number of routers have different values that
		they will accept.

		...

		NOT all new flows will request rates. Some will be
	 	SS TCP, others UDP. Thus, the fine granuality would
		be for the benefit of the requestor.

		Thus, if my basic premise is to minimze the request
		granuality to closely match any exact request, then
		the other factors (some listed above) should prevent
		the need for A.2 and to hopefully aid in the
		scalability to track / policy the flows.

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