Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st?

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 28 Jul 2006 09:12:59 +0200

Hannes,

thanks for the clarification. If the QOSM philosophy is 
as you describe it below then it's probably not producuing 
what I would regard as QoS. I think that it is not possible 
to define the service you will get if parameter 
interpretation starts to be a local matter instead of 
a standardised e2e behaviour. 

Regards,

Rüdiger

|> you raise an important aspect here.
|> 
|> |What is missing today in QOSMs is a mapping of mandatory 
|> |parameters to the QOSM behavior. If you look at the 
|> |QOSMs being standardized today 
|> |then they do not necessarily use all mandatory parameters. It 
|> |is, IMHO, important to specify what a node that implements a 
|> |particular QOSM would do when it receives a message with a QSPEC 
|> |object that contains an unknown  QOSM. For example, what do all 
|> |the currently specified mandatory parameters mean in the context of 
|> |RMD? I have asked this question in the past already; I never 
|> |saw an answer.
|> 
|> The draft should at least say, that the reservation must be 
|> released/refused if a node doesn't understand a QOSM.
|
|Well, that's not what a node should do. Instead it should try todo 
|anything it can to produce a meaningful QoS reservation 
|whereby the idea 
|is that this 'meaningful' reservation can be accomplished by just 
|looking at the mandatory QoS parameters of a QSPEC object (with the 
|details of that particular QOSM being unknown).
|
|  If a
|> different behaviour is operated, every implementor of a QOSM 
|> may design own interworkings and if several different 
|> implementations appear along a path, the (usually value added) 
|> service may not behave in way as expected by the QNI.
|
|The QNI might still learn that there are some domains along the end to 
|end path that did not support the QOSM it signaled. It might still 
|accomplish some QoS treatment although it will not be the one it 
|initially expected. This is our 'better than nothing QoS' (inline with 
|the 'better than nothing security' approach).
|
|
|> 
|> A reservation should only continue if there's a standardised 
|> interworking between different QOSM's along a path.
|
|That's the place where the QSPEC template guys would disagree with you.
|If the group would only worry about this aspect then we wouldn't need 
|the QSPEC template draft.
|
|  I don't
|> however favour a solution, where everey standardised QOSM 
|> is obliged to interwork with every other standardised 
|> QOSM.
|
|Sure. That would put a massive burden on new QOSMs and it might not be 
|feasible given that other SDOs can also define their QOSMs.
|
|
|  Standardisation of these interworkings should follow
|> the trends of the operational Internet to this regard. 
|> Interworkings between a few popular QOSMs may be useful.
|I agree with you.
|This is, however, largely independent of the 'mandatory' QoS parameter 
|idea.
|
|Ciao
|Hannes
|
|> 
|> Regards,
|> 
|> Rüdiger
|> 
|> 
|

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 29 Jul 2006 11:38:04 +0200

Hi Ruediger,

it might not be what you would ideally expect. But consider that we are 
dealing with a failure case here (in some sense) that might in fact 
happen quite frequently in a transition period where access networks 
implement some QoSMs but the core network does not process any QoS 
signaling messages. With a sender-initiated reservation the edge node of 
the access network of the data receiver may receive a QoS signaling 
message with a QSPEC object containing a QoSM used in the data sender's 
access network.

Then, you still receive some QoS treatment although it is not as perfect 
as it could be -> better than nothing.

Ciao
Hannes