Subject: [NSIS] QoS NSLP open issue on priority

From: [email-masked]
Date: Thu, 26 Feb 2004 15:26:04 +0100

Hi all,

The current version of the QoS NSLP specification discusses priority in two
ways:
- priority of the signalling message transport (requirement on GIMPS)
- priority of the reservation (related to preemption)

In the TE-WG, the concepts of setup priority and holding priority were used
to implement similar behaviour for DiffServ TE. Clearly, any given QoS
model can include support for setup and/or holding priority. The question
is whether people feel this functionality to be generally apllicable
(enough) to different QoS models to warrant inclusion of it in the QoS NSLP
spec.

Looking forward to your views,
Sven

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 27 Feb 2004 09:20:46 -0000

hi sven.

> (enough) to different QoS models to warrant inclusion of it 

my view: no. 

reason: i don't see any gain in integrating this aspect of operation
with the rest of the NSLP protocol description.

(your first point about GIMPS might be more interesting, but it
isn't clear if you are asking for anything specific. in any case,
you can do so by commenting on section 8.5 of the current GIMPS
draft, where the question is raised and left open. so far, the
only specific comment i have had on it is that this capability is
not necessary...)

r.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 27 Feb 2004 10:35:37 +0100

Hi Sven,

I agree with Robert on the issue of preemption: it is no generic 
NSLP functionality.

Regards, Rüdiger

|> Hi all,
|> 
|> The current version of the QoS NSLP specification discusses 
|> priority in two
|> ways:
|> - priority of the signalling message transport (requirement on GIMPS)
|> - priority of the reservation (related to preemption)
|> 
|> In the TE-WG, the concepts of setup priority and holding 
|> priority were used to implement similar behaviour for DiffServ TE. 
|> Clearly, any given QoS model can include support for setup and/or 
|> holding priority. 
|> The question is whether people feel this functionality to be 
|> generally apllicable (enough) to different QoS models to warrant 
|> inclusion of it in the QoS NSLP spec.
|
|my view: no.

---

From: "McDonald, Andrew" <[email-masked]>
Date: Fri, 27 Feb 2004 09:36:35 -0000

[email-masked] wrote:
> The current version of the QoS NSLP specification discusses priority
> in two ways:

I think this is the interesting part of the "priority" issue.

When does it matter that one message has priority over another?
The main situations seem to be:
- in the presence of network congestion (at the sending node)
- where there is flow control (from the receiving node)

As Rob points out, section 8.5 of the GIMPS draft talks about using multiple associations to do this. Usually the API to the underlying protocols doesn't tell you whether you are flow controlled or congestion controlled. Continuing to force data out (through an alternative association) when you are in a state of congestion control might well be considered impolite.

There is also a (now expired) draft talking about some of these issues:
http://www.watersprings.org/pub/id/draft-hancock-nsis-overload-00.txt

> In the TE-WG, the concepts of setup priority and holding priority
> were used to implement similar behaviour for DiffServ TE. Clearly,
> any given QoS model can include support for setup and/or holding
> priority. The question is whether people feel this functionality to
> be generally apllicable (enough) to different QoS models to warrant
> inclusion of it in the QoS NSLP spec.

This can be provided in any case at the QoS model level, so providing support at the QoS NSLP level is only necessary if there is a useful, general way of doing this. I'm not convinced at the moment that it is needed.

Andrew