Subject: RE: [NSIS] QoS NSLP expectations

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 19 Nov 2003 11:52:07 +0100

Hi Sven,

|I agree with you that the scope of the work is fairly broad, 
|but I believe it is not broader then the suite of 
|RSVP-related RFCs that touch on the QoS signalling issue. 
|Are there any of the topics that we currently have in the
|draft that you feel we should not be addressing?

As compared to RSVP, NSLP QoS isn't optimised for 
mobility support. But it adds 
( - indicates difference):

message set - let's say nothing
signaling relations - end-to-end is desired
scoping - completely new
stacking - completely new
state models - reduced state and stateless added
aggregation - remains to be seen.

During the Minneapolis meeting I had the impression, that 
QoS NSLP may support service- and parameter negotiation.

I'd prefer the default NSLP QoS operation to offer the 
features of the RSVP suite (no multicast, but including 
aggregation). A few new "mandatory options" have to be 
implemented (like requesting congestion awareness and 
reliable transport from NTLP). Other features like 
scoping, stacking or negotiation should be purely 
optional (for implementation and support).

Before I comment on the new "state modes" I'd like to get 
a better understanding of what they mean. Which state is 
maintained in which case? How does a stateless node differ 
from a node not supporting NSIS at all?

End-to-end signaling may be desireable. It however touches 
on security issues, which I for now prefer to leave  
out of my considerations.

A currently missing aspect is operational stability. A later 
version of the draft must specify handling of unknown 
parameters and codings.

Regards, Rüdiger

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 19 Nov 2003 12:23:37 +0100

Hi Ruediger

Thank you for your remarks!
I totally agree with you that the default NSLP QoS operation may offer the
features of the RSVP suite (no multicast, but including
aggregation). I also agree with you that there will be few new "mandatory
options"
to be implemented (like requesting (or not requesting) congestion awareness
and
reliable transport from NTLP).
I also agree with you that there will be other features optional. Further
discussions on this
is needed. The reduced state and stateless modes are modes
will probably be purely optional (for implementation and support).
You might consider the RSVP aggregation support as an example of reduced
state operation type.
You might consider any MBAC (Measurement Based Admission Control) scheme as
an example
of stateless operation type.

Best Regards,
Georgios