Subject: Re: [Tsvwg] draft quick start comments part 1 of: F : Temporary bit

From: Sally Floyd <[email-masked]>
Date: Tue, 28 Mar 2006 10:58:42 -0800

Mitchell -

>	Temporary bit.
>
>	F) The assumption with QS is that a QS flow's
>	capacity will be be moved from the QS requested
>	flow to a the aggregated flow in the next
>	time inteval.
>
>	However, a number of flows may have a different
>	set of characteristics, 
>
>	Some flows need a short burst of data,
>	   then can go quiet for a period of time
>	   or will only need to trickle data after
>	the burst. The result is that the capacity
>	of the link will be under-utilized.
>
>	To maximize the capacity usage of the link,
>	3.1 specifies unused bits within the Requested
>	rate field. My suggestion is to allocate 1 bit
>	to specify that the flow is only requested for
>	1 interval period and should not be counted in
>	the next time period.

I will add the Temporary bit to Appendix D on "Possible Additional
Uses for the Quick-Start Option".

The main function of Quick-Start is to "allow" flows to start up
with a higher sending rate when the output link is significantly
underutilized.  In particular, Quick-Start is intended to work in
cases where routers do not maintain per-flow state, but only maintain
state about the recent link utilization, and about the aggregate
Quick-Start bandwidth approved in a recent period of time.

I think that a Temporary bit would only make sense in an environment
where routers were keeping fairly detailed per-flow state, and were
targeting high link utilization and low delay.  Quick-Start is not
tuned to help routers achieve such a goal - Quick-Start is a fairly
coarse-grained mechanism intended to be of use in underutilized
environments.  The Quick-Start mechanism is not designed to help
routers achieve full link utilization.  I will try to make sure
that this is explicit in the draft.

- Sally

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

---

From: Erblichs <[email-masked]>
Date: Tue, 28 Mar 2006 13:22:34 -0800

Sally Floyd,

	First, thanks for seeing some merit in this suggestion:

	2nd, I don't see where the this bit is requiring
	per flow state, IF we assume that the requestor will
	use the allowed rate. If he does or doesn't, two values
	could be kept: expected recent link utilization 
	(based on requested/ accepted QS N bit rates) and
	actual link utilization. If they minimally differ:
	
		we have two intuitive scenarios:

	1) The requestors used their requested bit rates
	   and the majority of the older flows maintained
	   their usage.
	2) The requestors used less than their requested
	   bit rates and non QS flows consumed their decrease,
	   while the older flows maintained their usage.

	Note: if they vary drasticly, I would expect that the
	probability of passage of a QS request would decrease
	signficantly.

	Thus if the QS draft assumption holds that recent utilization
	is indicative of future link utilization plus QS flow
	requests, we then should be able to decrease expected
	contribution of the temporary flows. The amount is
	an implementation issue based on factors as the percentage
	of temporary QS flows vs non temporary QS flows, etc.

	Yes/no, I see two different type of TCP services where
	some some administrators want at least their WAN type 
	expensive links to have a high level of usability and
	support a bit rate without slow-start delay ramp-ups.

	Yes, I agree that QS is a coarse-grained mechanism,
	IF just because their are non QS TCP flows, non
	flow controlled UDP flows, etc transiting the same
	links as "QS flows".

	And, IF we assume that most requestors will use QS to
	transition directly into CA, then the per QS flow
	should slowly increase and not be a factor for
	coarseness level. I don't think a requestor
	would want a small request that is below ssthresh.

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