Subject: Re: [NSIS] QoS-NSLP comments

From: [email-masked]
Date: Wed, 29 Oct 2003 08:37:25 +0100

Hi Paulo, Attila,

Please find my take on things inline ...

Best regards,
Sven

Paulo Mendes <[email-masked]> on 28/10/2003 21:13:18

To:    "Attila Báder (IJ/ETH)" <[email-masked]>
cc:    [email-masked], Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
Subject:    Re: [NSIS] QoS-NSLP comments

hi Attila,

Comments inline..

Attila Báder (IJ/ETH) wrote:

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]: [email-masked]: [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.

Ups.. It is correct..

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.

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.

Sven>> I think the reason for the formulation that was chosen is the
following: The parameters of a QoS model are carried in the QSpec. The way
the QSpec is treated by QNEs may be influenced by Control Information.
Therefore, each QSpec could have its associated Control Information.
Therefore, we refer to the nesting of QoS models as stacking of QSpec and
Control Information. Note that this model could also cover the case that no
Control Information is present. This means that Control Information only
refers to the next QSpec. I think by allowing to stack just QSpec, you
would create confucion in the interpretation of which Control Information
applies to which QSpecs, which is something to avoid. Therefore, I would
prefer to always think about this in QSPec/CI pairs.

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.

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.

Sven>> You are right. We should be more precise and qualify the use of the
word state when we use it. Let me try: A stateless QNE is a QNE that does
not keep per-flow reservation state (note that no NSLP entity will ever
keep forwarding state). The main reason to have stateless QNEs is to reduce
state keeping requirements. Those will be the sum of the reservation state
keeping requirements of the QNE and the forwarding state keeping
requirements of the NE. If the NE keeps per-flow forwarding state, the
NE+QNE stills scales with the number of flows. Hence the comment that
stateless QNEs make the most sense combine with NEs that can take advantage
of this fact. One way of taking advantage is for the QNE to indicate to the
NE that it does not require its per-flow forwarding state keeping (e.g.
because no messages will ever be sent upstream on the reverse path). Then,
the NE could always forward messages of that flow based on the destination
IP address and reverse state keeping is not needed. Does this make any
sense?

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

--
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]://www.docomoeurolabs.de/

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