Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG draf t)

From: "Gary Kenward"<[email-masked]>
Date: Fri, 5 Apr 2002 10:07:28 -0500

Interesting. Why would this not be a policy decision?

gary

> -----Original Message-----
> From: Marcus Brunner [mailto:[email-masked]]
> Sent: April 5, 2002 06:08
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Geib, Ruediger;
> [email-masked]
> Cc: [email-masked]
> Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG
> draf t)
> 
> 
> We are not talking about priority of data traffic overothers, 
> but on the 
> case of the capacity already completly give away and a new 
> service request 
> arriving. One can then specify, whether it is possible to preempt 
> guaranteed reservations.
> 
> I would like see whether this is worth a reqirement.
> 
> Marcus
> 
> --On Thursday, April 04, 2002 12:37 PM -0500 Gary Kenward 
> <[email-masked]> wrote:
> 
> >
> > I guess my main issue is that this "requirement" seems to embed
> > definitions of flow treatment in the definition of the signalling
> > protocol. This, to me, is simply the wrong thing to do, unless there
> > is not clear reason why the two cannot be kept separate. I haven't
> > heard this reason.
> >
> > BTW: the priority of a flow IS coupled to it's QoS requirements.
> > As a counter example, what does an low priority EF flow mean?
> > Could you support EF PHB for a flow if it had a "lower 
> priority" (where
> > lower priority implies a higher liklihood of pre-emption of service)
> > then an AF or BE flow within a router? The answer is, very 
> probably not.
> >
> > Let's not debate QoS definitions in NSIS. I think John has 
> stated that
> > QoS definition is out of scope for NSIS, and declaring a 
> particular flow
> > treatment such as priority as not being QoS doesn't help.
> >
> > Gary
> >
> >> -----Original Message-----
> >> From: Marcus Brunner [mailto:[email-masked]]
> >> Sent: April 4, 2002 06:40
> >> To: Geib, Ruediger; [email-masked]
> >> Cc: [email-masked]
> >> Subject: pre-emption (was RE: [NSIS] proposals related to
> >> NSIS WG draft)
> >>
> >>
> >> As Ruediger I would like to hear some other opinions as well.
> >> I think the
> >> whole fault handling is an open issue anyway and preempting
> >> flows might
> >> play a roll in fault handling as well.
> >>
> >> Marcus
> >>
> >> --On Tuesday, April 02, 2002 4:27 PM +0200 "Geib, Ruediger"
> >> <[email-masked]> wrote:
> >>
> >> > Hi Sven,
> >> >
> >> > the comment is a bit late, but I've been offline for a while.
> >> > Nevertheless:
> >> >
> >> >> * New requirements
> >> >> - in section MUST support priority
> >> >>   The priority of a flow is essentially decoupled from
> >> >>   its QoS requirements. Therefore the protocol MUST
> >> >>   support priority. As a consequence, it MUST support
> >> >>   preemption of traffic flows in case of congestion or
> >> >>   failure. A preemption action MAY trigger an attempt
> >> >>   to resetup the request by means of another instance
> >> >>   of an NSIS signaling protocol.
> >> >
> >> > Could you provide some clearer argumentation why
> >> > preemption is a requirement? I'd classify preemption
> >> > as a "nice to have" feature, no more than a "MAY"
> >> > requirement. I'd especially insist on preemption being
> >> > completely decoupled from QoS and any other service
> >> > related signalling.
> >> > I.e. if it is not supported by an opperator, no
> >> > parameters or messages related to preemption are
> >> > to be transported.
> >> >
> >> > I'd like to ask other representatives of operators for
> >> > their view.
> >> >
> >> > Regards, Rüdiger
> >> >
> >> > _______________________________________________
> >> > nsis mailing list
> >> > [email-masked]
> >> > https://www1.ietf.org/mailman/listinfo/nsis
> >>
> >>
> >>
> >> --------------------------------------
> >> Dr. Marcus Brunner
> >> Network Laboratories
> >> NEC Europe Ltd.
> >>
> >> E-Mail: [email-masked]
> >> WWW:    http://www.ccrle.nec.de/
> >> personal home page: http://www.brubers.org/marcus
> >>
> >>
> >>
> >> _______________________________________________
> >> nsis mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/nsis
> 
> 
> 
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
> 
> E-Mail: [email-masked]
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
> 
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>

---

From: [email-masked]
Date: Fri, 05 Apr 2002 17:46:19 +0200

> Gary Kenward a écrit :
 
I dont understand the trouble here. We are making signaling, which is
per se the interface to an admission control function. Admission
control's role is to reject (hopefully not too much) users who want to
consume concurrently the same resources (such as an EF).
The first feature we can add to a "rough" signaling, is priority. For
example, when I want to call 911, I want the same QoS than a normal
call, this is normal voice, but I prefer not to be rejected by the
admission control.

A way to implement priority is preemption. Which  means to me to
interrupt the EF marking of already accepted flows, and notifying this
"normal" EF users they have no more the EF/voice quality.
There are other ways. For instance, an admission control can refuse
normal calls when some treshold is reached, and then only accept
priority calls.
 
So I would conclude that preemption is not a requirement for NSIS, but
priority should be supported by nsis. 

-- 
Alban Couturier
---------------------------------------------------------------------
Alcatel Research and Innovation
Ets de Marcoussis R&I/ULC
Route de Nozay                      mailto:[email-masked]
F-91461 Marcoussis CEDEX                       tel: +33 1 69 63 11 97
---------------------------------------------------------------------

---

From: Roland Bless <[email-masked]>
Date: Fri, 05 Apr 2002 18:28:46 +0200

Hi Alban,

the question is: is it really required to signal the priority
of a reservation? I think Gary just said that both priority
and preemption can be determined by the provider policy.
Otherwise end-users can always signal highest priority
for their requests, so the provider has to decide when to preempt
and what to preempt anyway. While a preemption mechanism for
reservations is perfectly reasonable (e.g. for 911 or possibly 
for handovers), I currently don't see a real requirement or 
benefit to _signal_ reservation  priority. This should rather 
be a (local) policy issue.

Regards,
 Roland

---

From: [email-masked]
Date: Fri, 05 Apr 2002 18:57:41 +0200

> be a (local) policy issue.

Hi Gary and Roland

My question is  how can the provider know that a particular flow deserve
a higher priority when a user requests QoS? 
Sometimes a user want not to be prempted or really wants its request to
be satisfied because he calls his boss, or the police etc... Sometimes,
the same user wants a "regular" call or session, which implies that the
network may refuse it because there is in competition a call to 911 or a
session with a big boss.
So only the initiator could signal to the network that a session is
really more important than another. It's just a question of a
high/medium/normal tag in a request. The network could then accept this
priority, or not, depending on policy/user profile... In case of network
failure, the QoS controller could also react in order to reestablish the
high priority flows before the others.

The only other solution i see could be to put this priority information
in the service description. But again, this type of solution mixes
admission control performed by the QoS controller, and the provisionning
of QoS. This lead to difficulties in network provisionning, or/and to a
poor design in the QoS controller that will be QSC dependant.

Regards

---

From: Roland Bless <[email-masked]>
Date: Mon, 08 Apr 2002 12:03:36 +0200

Hi Alban,

> a higher priority when a user requests QoS? 

He should derive this from the service definition.

> network may refuse it because there is in competition a call to 911 or a

Agreed, but this refers to application-dependent priority.

> really more important than another. It's just a question of a

I don't see how this may help the network provider, because you cannot
assume an objective priority request from users (there are always some
users who think they are (always) more important than others). If you 
only consider user suggested priority, how should the network know to 
prefer an emergency call before someone else's boss call when both 
requests had the highest possible signaled priority? Furthermore, how 
should the network decide that user A's boss is somehow more important 
(from A's view) than user B's call/boss? How should A set his priority
to preempt B's call?

> high priority flows before the others.

Given the possibility to signal a priority for reservations:
how would you prevent (selfish/malicious) users to not always signal the 
highest possible priority? In this case the network must decide by other
means what should be preempted anyway, so I don't see the benefit of a
user signaled priority. Surely, the user may know the importance of his
own flows, but then he can also tear down less important reservations
before starting a new more important "call".

> poor design in the QoS controller that will be QSC dependant.

I would suggest that this implied by the service. So one would have
a special service for emergency calls, maybe a special service
for "more important" (but also more expensive) premium calls and a 
service for regular calls (all three may even use the same QoS
mechanisms, but admission control differs).

Regards,
 Roland

-- 
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358
Phone: +49 721 608-6413 Fax: +49 721 388097