Subject: RE: [NSIS] draft-qosmodel-controlledload-04

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Mon, 3 Jul 2006 08:34:43 +0200

Hi Hannes, see below,

Attila
> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Saturday, July 01, 2006 10:23 PM
> To: Hannes Tschofenig
> Cc: Attila Báder (IJ/ETH); [email-masked]
> Subject: Re: [NSIS] draft-qosmodel-controlledload-04
> 
> 
> Hi all,
> 
> I should have read the latest QSPEC draft version before I sent this 
> mail. The most recent draft talks about this aspect and it says in 
> Section 4.7:
> "
> A QOSM specification MUST define how the mandatory parameters are to
>     be mapped onto the QSPEC parameters used by the QOSM, however the
>     mapping MAY result in slight modification to the intended
>     specification when an exact mapping is not possible.
> "
> 
> Attila, you did this for the token bucket parameter and 
> described that 
> it can be mapped to the bandwith parameter.
> 
> Now, the only question remains whether a QOSM also have to define a 
> mapping for all mandatory parameters. This would address the case 
> mentioned below: The QOSM does not make use of all mandatory 
> parameters 
> listed in the QSPEC.
> 

When the QSpec is translated to a local QSpec, I think the relevant mandatory parameters has to be mapped and this mapping should be defined in QOSM. Parameters which are not relevant in a QoS domain can be ignored. 

The main question is how to fill in mandatory parameters for another QOSM if it is not appliceble in the local QOSM. This should be defined in a QOSM.

In case of RMD it is not a problem: RMD QOSM is used as a local domain, and the original parameters are always handed over to the Egress edge, so all necessary info is available there.

> Ciao
> Hannes
> 
> 
> Hannes Tschofenig wrote:
> > Hi Attila,
> > 
> > Attila Báder (IJ/ETH) wrote:
> > 
> >> Hi Bernd, This is the case in RMD as well. In RMD domain resource
> >> reservation is based on one parameter: Bandwidth. If, for example,
> >> the resource request arriving to the Edge is a token bucket, it
> >> should be translated to a single Bandwidth parameter. This may be a
> >> peak value, or an effective value.
> > 
> > 
> > I guess Bernd's question was focusing on a different aspect. What 
> > happens if you receive a request that contains the 
> parameter 'Y.1541 QoS 
> > Class with the value set for Class 0?
> > 
> > Ciao
> > Hannes
> > 
> > 
> >>
> >> Best regards, Attila
> >>
> >>
> >>> -----Original Message----- From: Bernd Schloer
> >>> [mailto:[email-masked]] Sent: Thursday, June 29,
> >>> 2006 3:01 PM To: [email-masked] Subject: [NSIS]
> >>> draft-qosmodel-controlledload-04
> >>>
> >>>
> >>> Hi,
> >>>
> >>> the first open issue in the appendix B is about what to do with
> >>> mandatory QSPEC parameters which are not needed for CLS.
> >>>
> >>> Does a QOSM have to understand (and provide information about) all
> >>> mandatory parameters, even if they are not used? The QSPEC-draft
> >>> says in section 5 that all parameters listed in the next sections
> >>> are mandatory. The QSPEC-draft also says in section 4.1 that "a
> >>> given QOSM defines which of the mandatory and optional parameters
> >>> it uses, ..."
> >>>
> >>> Are there any specific parameters which makes the open 
> issue B.1.1.
> >>> clearer? Following the QSPEC-draft there doesn't seem to be a 
> >>> conflict, if nothing is done with the unneeded parameters.
> >>>
> >>> Thanks, Bernd
> >>>
> >>>
> >>>
> >>> _______________________________________________ nsis mailing list 
> >>> [email-masked] https://www1.ietf.org/mailman/listinfo/nsis
> >>>
> >>
> >>
> >> _______________________________________________ nsis mailing list 
> >> [email-masked] https://www1.ietf.org/mailman/listinfo/nsis
> >>
> >>
> > 
> > 
> > _______________________________________________
> > 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: Hannes Tschofenig <[email-masked]>
Date: Mon, 03 Jul 2006 10:27:55 +0200

Hi Attila,

please find my comment below:

Attila Báder (IJ/ETH) wrote:
> Hi Hannes, see below,
> 
> Attila
> 
>> -----Original Message----- From: Hannes Tschofenig
>> [mailto:[email-masked]] Sent: Saturday, July 01, 2006
>> 10:23 PM To: Hannes Tschofenig Cc: Attila Báder (IJ/ETH);
>> [email-masked] Subject: Re: [NSIS] draft-qosmodel-controlledload-04
>> 
>> 
>> Hi all,
>> 
>> I should have read the latest QSPEC draft version before I sent
>> this mail. The most recent draft talks about this aspect and it
>> says in Section 4.7: " A QOSM specification MUST define how the
>> mandatory parameters are to be mapped onto the QSPEC parameters
>> used by the QOSM, however the mapping MAY result in slight
>> modification to the intended specification when an exact mapping is
>> not possible. "
>> 
>> Attila, you did this for the token bucket parameter and described
>> that it can be mapped to the bandwith parameter.
>> 
>> parameters listed in the QSPEC.
>> 
> 
> 
> When the QSpec is translated to a local QSpec, I think the relevant
> mandatory parameters has to be mapped and this mapping should be
> defined in QOSM. Parameters which are not relevant in a QoS domain
> can be ignored.

The QSPEC template draft does not say anything like that.
I wonder whether this is inline with th mandatory parameter concept. If 
your QOSM does not understand it then it ignores it does not sound like 
"must be interpreted".

In fact, Section 4.6 (about QSPEC Extensibility) says about defining a 
new QSPEC draft version:

" Furthermore, all QOSM
    definitions must be updated to include how the new mandatory
    parameter is to be interpreted in the respective QOSM.
"

To me that indicates that the new mandatory parameter (which was 
obviously not relevant in the QOSM previously) needs to be dealt with.

> 
> The main question is how to fill in mandatory parameters for another
> QOSM if it is not appliceble in the local QOSM. This should be
> defined in a QOSM.

I am not sure I understood this statement. Can you reformulate it a bit?

> 
> In case of RMD it is not a problem: RMD QOSM is used as a local
> domain, and the original parameters are always handed over to the
> Egress edge, so all necessary info is available there.

Ciao
Hannes

>> Ciao Hannes
>>>> Hi Bernd, This is the case in RMD as well. In RMD domain
>>>> resource reservation is based on one parameter: Bandwidth. If,
>>>> for example, the resource request arriving to the Edge is a
>>>> token bucket, it should be translated to a single Bandwidth
>>>> parameter. This may be a peak value, or an effective value.
>>> 
>>> 
>>> Ciao Hannes
>>>>> [mailto:[email-masked]] Sent: Thursday, June
>>>>> 29, 2006 3:01 PM To: [email-masked] Subject: [NSIS] 
>>>>> the first open issue in the appendix B is about what to do
>>>>> with mandatory QSPEC parameters which are not needed for CLS.
>>>>> 
>>>>> 
>>>>> Does a QOSM have to understand (and provide information
>>>>> about) all mandatory parameters, even if they are not used?
>>>>> The QSPEC-draft says in section 5 that all parameters listed
>>>>> in the next sections are mandatory. The QSPEC-draft also says
>>>>> in section 4.1 that "a given QOSM defines which of the
>>>>> mandatory and optional parameters it uses, ..."
>>>>> 
>>>>> _______________________________________________ nsis mailing
>>>>> list [email-masked]
>>>> _______________________________________________ nsis mailing
>>>> list [email-masked] https://www1.ietf.org/mailman/listinfo/nsis
>>>> 
>>>> 
>>> 
>>>