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

From: [email-masked]
Date: Fri, 5 Apr 2002 09:11:16 +0200

Gary,

>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.

I absolutely disagree on this one. Priority is related to the question how
badly you want a certain connection to be set up and how badly you want to
keep it in place once it is there. QoS refers to the characteristics for
the flow once it is set up. In the TE-WG we came to the same conclusion
regarding DiffServ and priority. They are completely orthogonal.

Sven.

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

---

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

Sven:

  Yes, I misinterpreted the application of priority. My apologies.
I do not agree that DS and priority are orthogonal, but the application
of priority to admission of new flows is a different dimension on the
problem.

  I say that they are not orthogonal, because it would seem to me that if 
you were going to make a decision on whether or not to pre-empt established 
traffic for new traffic, then you must consider QoS. Example: the nature of 
the decision to admit new BE flows should be completely different then the 
decision to admit new EF flows because of the tighter, more deterministic, 
constraints on resource allocation for EF versus BE.

  More important is the consideration that from a user perspective, QoS is 
ultimately part of the service contract, implicit or explicit, between the 
network and the user (or between two networks). Any pre-emption actions must

fit within the agreed upon service model, and this is a policy decision, 
not a routing decision nor is it an admission control decision, in the 
strictest sense of admission control. The possibility that a users flows
could be dropped for reasons outside the control of the user is part of the
quality of the service offering.

  BTW: when I refer to "policy", I do not necessarily imply that a policy 
management system is required. While there are, perhaps, advantages to a PM
approach, the policy decisions and enforcement could be performed in other
fashions,
e.g. through a local, access network dependent mechanism. 

  And so, it is not clear to me why NSIS has to be worried about this
admission
"priority", per se. If relevant to the network, it should be encapsulated in

the TLA, which should be encapsulated in the QoS description, whatever form
that 
description takes.

  The net benefit here is by putting this priority where it belongs, in the
QoS description, NSIS is not implying a preferred operational model for the
access network, nor preferred functionality. And, still, the capability can
still be supported.

  Again, making priority explicitly in NSIS is still defining QoS models.

Regards,
Gary

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: April 5, 2002 02:11
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]'; Geib, Ruediger; 
> [email-masked];
> [email-masked]
> Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG
> draf t)
> 
> 
> Gary,
>

---

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

The issue is whether this is a new feature that needs to be addressed by
an NSIS solution or whether it is an interworking issue.

NSIS should not be attempting to replace the existing IETF solutions unless
there is a clear issue to be resolved.

Gary

> From: [email-masked] [mailto:[email-masked]]
> Sent: April 5, 2002 10:46
> Subject: Re: pre-emption (was RE: [NSIS] proposals related to NSIS WG
> draft)
> 
> 
> 
> 
> > Gary Kenward a écrit :
> > 
> > Interesting. Why would this not be a policy decision?
>  
> 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. 
> 
> 
> 
> > gary
> > 
> > > 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]
> > > 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.
> > > >
> > > > 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
> > > >
> > > >> 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
> > > >> >
> > > >> --------------------------------------
> > > >> 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
> > > >>
> > > >>
> > > >>
> > > --------------------------------------
> > > 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
> > >
> > >
> > >
> -- 
> 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: "Gary Kenward"<[email-masked]>
Date: Fri, 5 Apr 2002 12:18:07 -0500

Alban:

  I agree with most of what you have said, but really, it is not up
the end system to determine whether it's traffic should pre-empt flows
from other end systems. The decision to pre-empt can only be
made by the network (ignoring the trivial case of an end-host requesting
pre-emption of it's own flows).

  At best, pre-emption is the result of a negotiation between a host and
the network. This does not have to be a dynamic negotiation: the ability
to pre-empt could be part of the agreed upon QoS (first class passengers
get to board and leave the airplane before other passengers). The dynamic
case can be treated as simply part of QoS negotiation. 

I believe the only important question is whether there are special
signalling
requirements that can only be addressed by an explicit NSIS protocol
semantics,
rather then the identified requirement for NSIS to negotiate QoS.

In an earlier email, I did ask for some explanation of these special QoS 
signalling semantics for pre-emption, and I am interested in hearing
the rationale.

Cheers,
Gary

> Sent: April 5, 2002 11:58
> To: Roland Bless
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]'; Geib,
> Ruediger; [email-masked]; [email-masked]
> Roland Bless a écrit :
> > 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.
> 
> 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
> 
> > Regards,
> >  Roland
> > 
> > > > Gary Kenward a écrit :
> > > >
> > > > > Subject: RE: pre-emption (was RE: [NSIS] proposals 
> related to NSIS
> > > > WG
> > > > > draf t)
> > > > >
> > > > >
> > > > > > definitions of flow treatment in the definition of 
> the signalling

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 8 Apr 2002 08:40:18 +0200

Dear preemption discussion group,

if NSIS is ought to provide a universal service
establishment protocol and preemption/priority 
is orthogonal to QoS and a local matter, why 
then not to separate signaling?
The idea is to have one NSIS message set 
signaling QoS and another one to signal 
preemption (should signaling be required to 
support priority/preemption). An example:

- a roaming customer may learn by a policy 
  enquiry whether and how QoS and/or priority 
  are supported locally.
- in a "set up" message, QoS reservation 
  information may be joined by piggy backed 
  priority information if it is related to the 
  same reservation ID (otherwise the priority 
  information may be sent with it's own set up 
  message, always carrying a reservation ID of 
  the prior service reservation it is related
  to).
- The mechanism would work also across domains
  not supporting priority if the priority TLV is 
  marked as "discard/ignore if you don't 
  understand" or the local provider discards it
  at its border.

Please take the example only as clarification of
the basic idea. I'm not suggesting to follow 
exactly this solution.

Regards, Rüdiger

Rüdiger Geib
Senior Expert 
T-Systems Nova GmbH
Technologiezentrum
Am Kavalleriesand 3, 64295 Darmstadt
Germany
Fon: +49 6151 832138
Fax: +49 6151 838103
mailto:[email-masked]
http://www.t-nova.de