Subject: [NSIS] QoS-NSLP comments

From: Paulo Mendes <[email-masked]>
Date: Fri, 24 Oct 2003 18:36:41 +0200

Hi Sven,

Some general comments about the QoS-NSLP draft:

a) Terminology:
- Why isn't a reduced-state QNE defined?

- Policy Object: Policy in QoS related issues leads me to think more about dropping of packets that do not comply with some QoS profile, than with authentication issues.

b) On section 1.1 it is said that "The design of QoS-NSLP is conceptually similar to RSVP...". How can these two concepts be similar when QoS-NSLP uses peer-to-peer messages and RSVP uses end-to-end messages?

c) On section 2.5 it is said "In order to allow some local selection of which QoS Model to use without destroying all end-to-end aspects of the signalling QoS-NSLP allows a nesting of QoS Models by 'stacking' more than one pair of Control Information / QSpec object within a message". Shouldn't this sentence be more general to allow the stacking of QSpec instances within the same QoS model? For example, in DiffServ type of QoS models, one statefull edge router might use the same message to signal another statefull edge router, while signalling all reduced-state interior routers in the path. Since QSpec to signal edge routers might be different from the one to signal interior routers, these models might need to stack edge-QSpec inside interior-QSpec.
Another question about this issue is: How much related with section 7.3.2 (tunnel management) is section 2.5 (nested protocol operation)?

d) Reverse Path State: On section 2.7 it is said that a stateless and reduced state QNEs will be able to provide the underlying NTLP with some information, namely reverse path state. How can this be done in the case of stateless operation, in which QNEs are supposed to keep no state? Why can't QNEs operating in a statefull mode provide also the NTLP with such information?

e) Peer-to-peer routing of NSLP messages: On section 6.2 it is said "There are several circumstances where it is necessary for a QNE to identify the adjacent QNE peer...". Shouldn't this knowledge be useful in any circumstances? Since the next QNE can be more than one hop away, information about the next QNE needs to be kept by the QNE: not only the SII to identify the source of the application message but also the identification of the downstream peer. Considering that the next QNE can also be more than one NTLP hope away, why should SII be kept by the NTLP, as said in section 3.1?
Also about this topic, nothing is said about the discovery of next-peer QNE.

Cheers
Paulo

-- 
Paulo Mendes
DoCoMo Communications Laboratories Europe GmbH
Landsberger Str. 312
80687 Munich, Germany
Tel. +49-89-56824-226
Fax. +49-89-56824-300
E-mail: [email-masked]
http://www.docomoeurolabs.de/

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

---

From: Roland Bless <[email-masked]>
Date: Mon, 27 Oct 2003 11:03:49 +0100

Hi Paulo,

> - Policy Object: Policy in QoS related issues leads me to think more
> about dropping of packets that do not comply with some QoS profile,
> than with authentication issues.

What you think of is _policing_ (at the network edge), not policy. While
policing is part of traffic conditioning (DiffServ terminology), policy
is important to let providers express their administrative preferences
by a rule set. Thus, you have to consider not only resource
based-admission control, but also policy-based admission control (see
also rap WG). The latter determines whether the user has administrative
permission to make a reservation (see policy control definition in nslp
draft). For example: customer A is not allowed to make reservations for
a certain service class X, but is allowed to make a reservation for
service class Y from 08:00 till 18:00. Therefore, you also need to know
the user's identity and that's where authentication comes in.

Regards,
 Roland

---

From: Paulo Mendes <[email-masked]>
Date: Tue, 28 Oct 2003 21:07:38 +0100

hi Roland,

You're right. I was thinking about policing schemes. This thread is over :).

Cheers,
Paulo