Subject: RE: [NSIS] QoS NSLP expectations

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 19 Nov 2003 12:44:46 +0100

Hi Georgios,

thanks for your answers. Agreed text deleted, two remarks:

|You might consider the RSVP aggregation support as an example 
|of reduced state operation type.

Great to hear, I hoped for that comment. 

|You might consider any MBAC (Measurement Based Admission 
|Control) scheme as an example of stateless operation type.

I don't think "any" would hold. Some MBAC algorithms expect 
prior knowledge source traffic characteristics. Others 
clearly benefit from knowing "per flow" characteristics. 
In the core this can only be derived from signaled 
information (unless individual flows are measured, which 
I don't regard as an option). Further, also MBAC schemes 
may require information about route changes (e.g. if they 
should accept "exceptional" loads as a result of a link 
failure they may need to be notified of the "exceptional"
status).

Regards, Rüdiger

|----- Original Message -----
|From: "Geib, Ruediger" <[email-masked]>
|To: <[email-masked]>
|Cc: <[email-masked]>
|Sent: Wednesday, November 19, 2003 11:52 AM
|Subject: RE: [NSIS] QoS NSLP expectations
|
|
|> 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
|>
|

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 19 Nov 2003 13:31:41 +0100

Hi Ruediger

> failure they may need to be notified of the "exceptional"

Agreed with you on the term "any".
There are some (not any) MBAC schemes that can be used as examples
of stateless operation type.

Best regards,
Georgios