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

From: "Gary Kenward"<[email-masked]>
Date: Thu, 4 Apr 2002 12:37:41 -0500

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
>

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 05 Apr 2002 13:07:51 +0200

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