Subject: Re: [NSIS] Question to the CL QoS Model authors

From: Bernd Schloer <[email-masked]>
Date: Wed, 6 Dec 2006 14:21:10 +0100 (MET)

Hi,

with the proposed e2e QSPEC object remapping is not necessary any more. Since CLS
relies on Token Bucket as the only parameter, no local QSPEC needs to be defined.
I assume QoSClass and Priority is ignored by CLS QOSM from now on. Still interesting
could be two different queues to handle CL and Best Effort traffic.

The interoperation with RSVP is another open issue. The table in section 7 shows
a mapping of objects and parameters between QoS NSLP and RSVP.

A RSVP PATH message contains a Sender TSpec and an ADSpec object. The Sender TSpec
describes the traffic specification while the ADSpec probes for available Bandwidth.
The ADSpec can be mapped to <QoS Available> (Bandwidth) and the Sender TSpec +
FlowSpec to <QoS Desired> and opt. <Minimum QoS> (both Token Bucket).

Compared to the table in section 6.4.2 of the QSPEC Template the <QoS Desired> is
missing in the QUERY and RESERVE message. How does this fit together? The Object
Combination is not optional from my understanding. The CLS-draft mentions that
Sender-TSpec and ADSpec cannot be mapped easily. Does this mean multicast flows
and merged FlowSpecs?

Where is the difference between one-pass, One Pass with Advertising(OPWA) and the
two-pass reservation model? Are there more? When the Sender includes an ADSpec in the
Path message, it's OPWA, without ADSpec it's one-pass. The Receiver-Initiated Reservation
is two-pass?

There are three examples in Appendix B.2 showing how the QSPEC in a QUERY message
can be composed and interpreted.

1.The Sender (QNR) collects information about the available bandwidth with a QUERY
message containing <QoS Available>. The Receiver (QNI) generates a RESERVE message
with <QoS Desired> based on <QoS Available>. The Sender (QNR) sends back a RESPONSE
with <QoS Reserved> which carries information about the performed reservation.
According to the QSPEC Procedures <QoS Available> is missing in the QUERY and RESERVE.

The next two examples are not quite clear to me.
2.  When the QNR composes the <QoS Desired> based on <QoS Available> it uses a Token
Bucket (QNE-readonly). A Resource QUERY can get <QoS Available>. I'm not sure if this
is draft-conform: The QNR could pretend to be a QNI for the QUERY to make then a
Receiver-Initiated Reservation as QNR. From my understanding a QNR can't do a Resource
QUERY along the path to the QNI.

3. Peak-Rate can be mapped to Bandwidth. The Traffic object contains both, Token Bucket
and Bandwidth. Using Bandwidth avoids mapping and interpreting certain fields of TB,
but each QNE along the path should know how to deal with the new <QoS Available>.

Comments?

Bernd

Xiaoming Fu wrote:
> Hi Jukka,
> 
> The CLS draft is actually a remapping of RSVP CLS parameters (and 
> procedures) to NSIS.
> 
In the table in section 7 <QoS Desired> (QUERY and RESERVE) is not mentioned
as in the QSPEC Procedures. The same with <QoS Available> for RESPONSE. Also
in section 5.3 <QoS Desired> is not mentioned. Are these parameter optional? > In the QSPEC-1 parameters specified in [draft-ietf-nsis-qspec], there
> are the following two types:
> 
> - <Excess Treatment> is an optional parameter in QNI, namely it can be 
> included or excluded in the CLS control information. If it is included 
> in a message, then CLS QNE must interpret and populate it.
> 
> - <QoS Desired> and <QoS Reserved> are mandatory for all (QNI QNEs QNR)
> including other QoSMs; <QoS Available> mandatory for receiver-initiated 
> reservation, but optional for sender-initiated reservation.
> 
> however, we didn't discuss how exactly the objects other than Token 
> Bucket(s) inside the QoS Desired etc should be handled. We thought a QNE 
> doesn't need to include (for QNI/QNR) nor interpret any of them.
> 
> Any remarks on this?
> Xiaoming
> 
> Jukka MJ Manner wrote:
> 
>> Hi Xiaoming and Cornelia,
>>
>> I was wondering if you have some ideas on how the CL QoS Model would 
>> handle all the current QSPEC-1 parameters? Your draft lists that as an 
>> open issue.
>>
>> Cheers,
>> Jukka
>>
>> _______________________________________________
>> 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: Bernd Schloer <[email-masked]>
Date: Wed, 6 Dec 2006 23:05:37 +0100 (MET)

Hi,

the question about one and two pass was wrong. I'm more interested in which
one is interesting for the QOSM CLS.

Bernd

Bernd Schloer wrote:
> in section 5.3 <QoS Desired> is not mentioned. Are these parameter 
> optional? > In the QSPEC-1 parameters specified in 
> [draft-ietf-nsis-qspec], there
> 
>> including other QoSMs; <QoS Available> mandatory for 
>> receiver-initiated reservation, but optional for sender-initiated 
>> reservation.
>>
>> Bucket(s) inside the QoS Desired etc should be handled. We thought a 
>> QNE doesn't need to include (for QNI/QNR) nor interpret any of them.
>>
>> Any remarks on this?
>> Xiaoming
>>
>> Jukka MJ Manner wrote:
>>
>>> handle all the current QSPEC-1 parameters? Your draft lists that as 
>>> an open issue.
>>>
>>> Cheers,
>>> Jukka
>>>

---

From: Xiaoming Fu <[email-masked]>
Date: Mon, 11 Dec 2006 13:19:10 +0100

Hi Bernd,

> relies on Token Bucket as the only parameter, no local QSPEC needs to be 
True.

> could be two different queues to handle CL and Best Effort traffic.
This is clear enough to all, I think. Any open issue on this?

> Sender-TSpec and ADSpec cannot be mapped easily. Does this mean 
Please do not confuse here: multicast is not considered with current 
NSIS CLS.
The mapping of RSVP Path Sender-TPSEC (key parameter: Token bucket) 
should be clear now, as QoS NSLP Query shall have a key CLS parameter: 
QoS Available which has token bucket as part of "Traffic" now.
RSVP ADSPEC contains MTU, which we didn't include in CLS QoS Available 
(probably can add in the next version?).
> Receiver-Initiated Reservation
This can be found in some tutorial. For NSIS I don't think this is a 
fundamental question while specifying CLS service: QoS NSLP simply 
provides necessary facility for CLS service users to use.

> According to the QSPEC Procedures <QoS Available> is missing in the 

Ok - will fix in Query, but QoS Available might be optional for RESERVE 
(it already contains QoS RESERVED!) here I think.
> QUERY along the path to the QNI.

I don't get at it. Your assumption of having QNR to act as QNI is not 
necessarily true, if sufficient security measures are provided.

> but each QNE along the path should know how to deal with the new <QoS 

Sorry, what is the question?
Xiaoming