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

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 10 Oct 2006 23:52:37 +0300 (EEST)

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

---

From: Xiaoming Fu <[email-masked]>
Date: Wed, 11 Oct 2006 07:57:01 +0200

Hi Jukka,

The CLS draft is actually a remapping of RSVP CLS parameters (and 
procedures) to NSIS.

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

-- 
Cheers,

Xiaoming
--
http://user.informatik.uni-goettingen.de/~fu

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Oct 2006 21:05:21 +0200

Hi Xiaoming,

I think Jukka was trying to find a QOSM that provides some information 
about the mapping of the mandatory QSPEC parameters to the one used by a 
QoSM. I also tried to find some guidance in existing QOSMs a couple of 
months ago as well and I couldn't find a lot.

Ciao
Hannes

---

From: Xiaoming Fu <[email-masked]>
Date: Wed, 11 Oct 2006 21:40:18 +0200

Well, for such an issue, I think in general it is hard for QOSMa to 
other non-QOSMa QSPEC-1 parameters defined by [draft-ietf-nsis-qspec-12] 
to (re)map QOSMa QSPEC-1 parameters. At least in CLS case I think one 
QNE can simply forward them without processing.
Xiaoming
Hannes Tschofenig wrote:
>> 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: "Kappler, Cornelia" <[email-masked]>
Date: Tue, 17 Oct 2006 10:42:25 +0200

Hi Hannes, 

this is not yet included in the draft. According to the discussions we had so far I think we'll state something along these lines:

- bandwidth is mapped to token bucket (we'll have to come up with a proposal for values for the missing TB parameters)

- the high-valued QoS Class parameters will receive CLS treatment (we expect the QNI includes a bandwidth parameter in the QSPEC, otherwise we cant do anything). The low-value QoS Class parameters get best-effort.

- Excess Treatment and Priority is orthogonal to the CLS concept, so CLS QNEs just have to deal with it. 

What you see from this is that a CLS QNE must be able to map the QoS Class parameters onto "high" and "low". This is the extent to which they must understand QoS class.

Cornelia

> -----Ursprüngliche Nachricht-----
> Von: Hannes Tschofenig [mailto:[email-masked]] 
> Gesendet: Mittwoch, 11. Oktober 2006 21:05
> An: Xiaoming Fu
> Cc: Jukka MJ Manner; [email-masked]; Kappler, Cornelia
> Betreff: Re: [NSIS] Question to the CL QoS Model authors
> 
> Hi Xiaoming,
> 
> receiver-initiated