Subject: Re: [Tsvwg] draft quick start comments part 1 of: E : Priority bit

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

Mitchell -

>	Priority bit
>
>	E) 3.1 Requested rate N field uses 4 of the 8 available
>	bits. The issue is that requestors requests are handled 
>	on a first-come-first-serve basis. This may prevent later
>	important sessions from being able to use QS.
>
>	However, it is also common that the last percentage of
>	available resources are normally consumable by
>	special requestors.
>
>	To resolve both issues, I suggest that at least a
>	single bit be allocated from the rate request field,
>	called the priority bit.
>
>	Priority requests SHOULD be accmpanied by small N
>	values and is meant as a hint that this session
>	establishment has a significant level of importance.
>
>	The amount of last available space reserved for priority
>	requestors should be a router implementation issue.
>
>	A router can ignore this priority bit and deal with the
>	request as a normal QS rate request.

I don't think this is a viable way to deal with priority.  However,
connections with Quick-Start requests might include not only
best-effort traffic, but traffic of higher and/or lower
(lower-than-best-effort) priorities, as indicated by the diff-serv
codepoint in the packet header.  The router is certainly free to
take into account the diff-serv codepoint in considering QS requests.
The router is also free to use its own understanding of priorities.
I will add a paragraph about this in the document, in Section 9.3
on "Quick-Start with QoS-enabled Traffic".

- 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:06:09 -0500

> I don't think this is a viable way to deal with priority.  

Me either.  At the risk of being mostly redundant:

  * First, everyone will set the priority bit.  Why wouldn't you?

  * QS is about a quick check.  I think this is needless complication.
    If a router is significantly underutilized then why are we expecting
    more traffic with higher priority?  It might well happen.  But, it's
    gotta be just as likely to not happen.

allman

---

From: Erblichs <[email-masked]>
Date: Wed, 29 Mar 2006 00:58:58 -0800

Mark Allman and Sally Floyd, et al,

	Their are two questions here.

	1) Why wouldn't every QS requestor set this
	bit?
		Summary: the normal requestor will
		want to maximize the bit rate request
		AND and the priority requestor will
		request small bit rate requests.

	Isn't this obvious from my original suggestion??

 	-- A router can ignore this priority bit and deal with the
        request as a normal QS rate request. It is an extra bit
	that CAN be checked IFF... (implementation dependent)

	-- Priority is only needed when the link is becoming 
	fully utilized AND/AND/AND the router is attempting 
	to prioritize the requestors. The important section
	below clarifies "fully utilized".

	-- By including the following in my 
	   ORIGINAL suggestion:

"Priority requests SHOULD be accompanied by small N
values and is meant as a hint that this session
establishment has a significant level of importance."

	The normal requestor will want to maximize the
	bit rate! The priority request will want to
	minimize the bit rate request so that its
	request will be accepted.

	This says I am willing to sacrafice bit rate
	for POSSIBILY better handling, IFF...]
	
	Thus the entity that sets the requested bit rate
	can choose the type of service it wants/needs.
	The simplicity is that the requestor limits
	his initial needs!!!!

	2) Can this solve a possible problem and do it
	with MINIMAL complication / overhead?

	Important
	-->The general issue that I am addressing here with this and
	my other suggestions are aimed at those src/dst paths where 
	one or more intermediate links will have the aggregated flows.

	-->These few links probably will determine whether the QS
	request passes. They will be the bottleneck links and
	this draft needs to make sure that those links have the
	ability to attempt to achieve high utilization. All the other
	Intermediate Systems (ISs) will have normal to low utilizations..

>     more traffic with higher priority? 

	 priority generates backpressure on the requestors to
	minimize their requested bit rates, so it effectively
	decreases the bit rate requirements for a set of QS flows.
	This decrease in bit rates, increases the abilty of a router
	to handle more flows because the avg bit request should drop.
	
	With priority we can attempt to allocate towards a higher
	link utilization. We effectively can move from a tail drop
	methodolgy (deny all QS flow requests) of all flows when we 
	hit a high utilization TO a RED methodolgy at maybe a higher 
	utilization point because hi-pri flows will have lower
	bit rate requests.
	
	Mitchell Erblich
	--------------------

>   * First, everyone will set the priority bit.  Why wouldn't you?
		the normal requestor will
		want to maximize the bit rate request
		AND and the priority requestor will
		request small bit rate requests.

>   ------------------------------------------------------------------------
>    Part 1.2Type: application/pgp-signature