Subject: RE: [NSIS] attempted summary of pre-emption thread

From: "Gary Kenward"<[email-masked]>
Date: Tue, 9 Apr 2002 21:32:06 -0400

Martin:

 Could you expand upon your point for me. I do not understand
the tight relationship being assigned between (bearer traffic?)
pre-emption, and signalling semantics.

Gary

> -----Original Message-----
> From: Martin Karsten [mailto:[email-masked]]
> Sent: April 9, 2002 19:18
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'James M. Polk'; Hancock, Robert; [email-masked]
> Subject: Re: [NSIS] attempted summary of pre-emption thread
> 
> 
> >   Robert's email was clear to me, and well stated. He was 
> saying that if
> > there is a requirement for pre-emption, then it can be 
> captured in the
> > data description (hopefully, an opaque TLV data chunk) for 
> the QoS, and
> > there is no need for a change in the requirements for NSIS.
> 
> I have to admit that I did not follow the complete thread, 
> but maybe it
> helps to distinguish "preemption" from "priority".
> 
> The "priority" of a request can be encoded in the QoS 
> specification, but
> "preemption" capability (beyond packet preemption aka "drop" 
> ;-), including
> informing all participating entities, mandates a certain asynchronous
> communication pattern, which must be taken into account when 
> designing the
> signalling protocol and thus, seems to belong to the requirements.
> 
> Martin
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>

---

From: Martin Karsten <[email-masked]>
Date: Wed, 10 Apr 2002 13:03:47 +0200 (CEST)

It might be obivous not to do, but someone could have the idea to design
e.g. the following signalling protocol:

1) initiator sends QoS request and waits for confirmation (or reject)
2a) a network entity rejects the request and sends reject towards initiatior
2b) all network entities accept the request, so it arrives at remote end
3) remote end sends confirmation
4) transmission time (maybe including periodic state refresh)
5) initiator sends teardown (maybe through state timeout)
6) (optional) remote end sends tear confirmation

Then the initiator would never be prepared to handle an asynchronous tear
notification. If preemption capability shall be supported properly, however,
the initiator must be prepared to receive such a notification.

This is the most simple example that comes to my mind, of how preemption
capability might influence the communication pattern. There might be other
and more complex examples, depending on the rest of the requirements. Maybe
James can jump in clarify whether this captures his view.

Martin

> > >   Robert's email was clear to me, and well stated. He was saying that
> > > if there is a requirement for pre-emption, then it can be captured in
> > > the data description (hopefully, an opaque TLV data chunk) for the
> > > QoS, and there is no need for a change in the requirements for NSIS.
> > 
> > I have to admit that I did not follow the complete thread, but maybe it
> > The "priority" of a request can be encoded in the QoS specification, but
> > "preemption" capability (beyond packet preemption aka "drop" ;-),
> > including informing all participating entities, mandates a certain
> > asynchronous communication pattern, which must be taken into account
> > when designing the signalling protocol and thus, seems to belong to the
> > requirements.
> > 
> > Martin
> >