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

From: "Gary Kenward"<[email-masked]>
Date: Tue, 9 Apr 2002 16:01:38 -0400

James:

  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.

  There may be, and Robert did not address this, a need to change the IETF
definitions
for QoS, iff the intent is to have pre-emption supported as part of the
standard offerings.
E.g. if a pre-emptive EF PHB is required, then the Diff Serv wg must make
the change, not
NSIS.

  In addition, there is no reason why the NSIS protocol cannot carry
network,
and even device specific TLV data chunks. However, the contents of these
data
chunks need not be visible to NSIS - how would the fact that the QoS
contained
a specification for pre-emption change the semantics of the NSIS protocols?
Given
that the answer, as far as I can tell is no, then as long as the NSIS syntax
allows
for the information to be conveyed, it is not necessary to identify the
meaning of
the QoS specification in the NSIS standard because it is not used by NSIS.

  This is a very different approach from SS7, UNI, SSCPS, GSM, UMTS, .... IP
is an
internetworking protocol, and must work across many different networks. NSIS
should
also work across all (predominant) networks. Given the alternative of
defining variants
of the protocol for every network, it is often more productive to define a
generic capability,
and leave the network specific stuff to the respective SDOs.

Regards,
Gary

-----Original Message-----
From: James M. Polk [mailto:[email-masked]]
Sent: April 9, 2002 15:09
To: Hancock, Robert; [email-masked]
Subject: Re: [NSIS] attempted summary of pre-emption thread

At 03:06 PM 4/9/2002 +0100, Hancock, Robert wrote:

I'm confused by your conclusions. Let me quote you, but rearrange what you
wrote to show this below. 

You stated 2 times that QOS information was necessary in the signaling:
>
>3. QoS signalling has to carry enough information to enable the network to 
>make this decision (and that information might have to be authenticated or 
>otherwise processed to classify the session securely); 

>If this is complete, the implications for NSIS would seem to be:
>A) from (3), the QoS data carried has to include particular information - 

and that if preemption does occur, the "network" should tell someone:

>4. if a session is pre-empted, the network might (should?) want to tell 
>affected users that their QoS has been degraded.
>==================
>
yet state this information now *doesn't* need to be included here:

>however, this 
>information does not need to be visible to the signalling protocol.
>

and conclude with "no new requirement" for preemption:

>but since this is opaque to us anyway, there is no new requirement here.

>So, no new requirements. 
>
>I've thought hard in the past but can't think of any new requirements for 
>NSIS from this topic. I'd be interested to see any.

Your logic within your email is flawed and poorly written, and doesn't
support the conclusion you wrote. Please review what you wrote that I've
highlighted above near the top and tell me how you stated that this
information "~ ...has to include particular (identifying) information (for
preemption to properly be performed)....", yet conclude that it "~...isn't
needed....So, no new requirements."

>robert h.
Robert - you didn't read my email obviously as I stated many networks that
have this capability that NSIS *won't* be an appropriate QOS mechanism for
interfacing with if this is not included... 

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com

---

From: Martin Karsten <[email-masked]>
Date: Wed, 10 Apr 2002 01:18:02 +0200 (CEST)

> 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: Marcus Brunner <[email-masked]>
Date: Wed, 10 Apr 2002 13:56:07 +0200

Martin,

then you think a requirement for the support of asynchronous feedback is 
the way to go?

Marcus

--On Wednesday, April 10, 2002 1:18 AM +0200 Martin Karsten 
<[email-masked]> wrote:

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

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

---

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

Maybe. I have no definite opinion about whether preemption capability may
have further implications. I just noticed that there seemed to be confusion
in the discussion because of overloaded terminology and wanted to help
sorting this out.

Martin