Subject: RE: [NSIS] QoS-NSLP comments

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Tue, 28 Oct 2003 10:16:52 +0100

Hi Paulo,

I tried to answer some of your points, please see my comments inline.

Best regards, Attila

> -----Original Message-----
> From: Paulo Mendes [mailto:[email-masked]]
> Sent: Friday, October 24, 2003 6:37 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [NSIS] QoS-NSLP comments
> 
> 
> Hi Sven,
> 
> Some general comments about the QoS-NSLP draft:
> 
> a) Terminology:
> - Why isn't a reduced-state QNE defined?
 
I think it is, 4th from last.

> - 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)?
> 
Well you are right, it could be better formulated. I think the description is based on the assumption that QoS model is defined by QSpec and Control Info. I think both nesting of QoS models and nesting of QSpec objects are needed. The connection with tunnel management is that QoS model or QSpec object, used outside the tunnel, can be tunneled.   

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

I think it is not said. It is said that QNEs provide info about the NSLP stateless (reduced state) situation.

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

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

---

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

hi Attila,

Comments inline..

>I think it is, 4th from last.
Ups.. It is correct..

>Well you are right, it could be better formulated. I think the description is based on the assumption that QoS model is defined by QSpec and Control Info. I think both nesting of QoS models and nest…
Since different QoS models have different QSpecs, I think it is enough 
to refer to nesting of QSpecs instead of nesting of QoS models by 
stacking QSpecs.

>I think it is not said. It is said that QNEs provide info about the NSLP stateless (reduced state) situation.
Agree. What is said is that the stateless NSLP informs the NTLP about 
its situation. But, the focus that I wanted to give to my question  was 
on the "state" issue. On 2.7 it is said "Stateless and reduced state 
QoS-NSLP operation makes the most sense when (some nodes of) the 
underlying NTLP is (are) able to operate in a stateless way as well.". 
This means that neither the NSLP nor the NTLP keep state, right? In this 
case, how does a QNE know to want peer it should relay a message?

So, I think the core question is related with the definition of state. 
Does "state" only refers to reservation state, as mentioned in the 
definition of statefull, reduced-state and stateless operations, or does 
it refer to any state, including for instance reverse path state?
If "state" is referred to any state, my question stands. Otherwise, my 
question is how much state has a QNE to keep besides the reservation state?

This question has something to do with a previous Geib's e-mail, where 
he asked about "session state". In the same e-mail Sven said  "Section 
2.7 introduces the fact that some QoS models supported by the QoS NSLP 
might not keep (per-flow) state."

By now he have references to reservation state, session state and flow 
state. I think that the draft needs a clear definition of what is meant 
by state.

In what concerns Geib's question about the maximum per session state 
maintenance requirements. If by "state" it is meant reservation state, 
then I agree with Sven, when he said that that is a QoS model issue. But 
if "state" means any control information, I think that the draft should 
indicate what is that control state (not reservation state) required by 
QoS-NSLP (forwarding state, fragmentation state, congestion control 
state, security state, ....). Any way, I think any control information 
is important, not only reservation state.

Cheers,
Paulo