Re: [NSIS] QSPEC Questions

["Hannes Tschofenig" <[e-mail]>]

Hi Elwyn, 

Thanks for your feedback.  

>-----Original Message-----
>From: Elwyn Davies [mailto:[e-mail]] 
>Sent: 02 November, 2008 12:14
>To: Hannes Tschofenig
>Cc: [e-mail]
>Subject: Re: [NSIS] QSPEC Questions
>
>
>
>Hannes Tschofenig wrote:
>> Based on Dan's AD review comments for 
>> draft-ietf-dime-qos-parameters-06 I need to ask a few 
>questions regarding the QSPEC draft:
>>
>> * There is no description of the differences between TMOD-1 
>and TMOD-2.
>> Useful to say something about the difference?
>The reason for two TMODs given in the Qspec draft is (from s3.3.1):
>
>   Two TMOD parameters are defined in Section 5, <TMOD-1> and <TMOD-2>,
>   where the second (<TMOD-2>) parameter is specified as could 
>be needed
>   to support some DiffServ applications.  For example, it is typically
>   assumed that DiffServ EF traffic is shaped at the ingress 
>by a single
>   rate token bucket.  Therefore, a single TMOD parameter is sufficient
>   to signal DiffServ EF traffic.  However, for DiffServ AF traffic two
>   sets of token bucket parameters are needed, one token 
>bucket for the 
>   average traffic and one token bucket for the burst traffic.
>   [RFC2697] defines a Single Rate Three Color Marker (srTCM), which
>   meters a traffic stream and marks its packets according to three
>   traffic parameters, Committed Information Rate (CIR), 
>Committed Burst
>   Size (CBS), and Excess Burst Size (EBS), to be either green, yellow,
>   or red.  A packet is marked green if it does not exceed the CBS,
>   yellow if it does exceed the CBS, but not the EBS, and red 
>otherwise.  
>   [RFC2697] defines specific procedures using two token buckets that
>   run at the same rate.  Therefore 2 TMOD parameters are sufficient to
>   distinguish among 3 levels of drop precedence.  An example is also
>   described in the Appendix to [RFC2597].
>
>A piece of this probably needs to be in the dime doc.
>
I wonder how I was able to have missed that description. 

>>   
>>
>> * Where does the description for <Path Jitter>, <Path PLR> and <Path 
>> PER> come from? There is no reference to another RFC given 
>in these sections.
>>
>> * Why is Path Jitter STAT4(Reserved) included in the <Path Jitter> 
>> parameter?
>>
>> * The encoding of the  <RPH Priority> Parameter is not inline with 
>> http://tools.ietf.org/id/draft-ietf-tsvwg-emergency-rsvp-09.txt. The 
>> ALRP Priority and the Reserved octets positions are inversed.
>>
>> * <DSTE Class Type> Parameter
>>
>> The QSPEC draft says:
>> "
>>  DSTE Class Type: Indicates the DSTE class type.  Values currently
>>    allowed are 0, 1, 2, 3, 4, 5, 6, 7.
>> "
>>
>> RFC 4124 does not define a value of 0. Where does 0 come from? 
>> In RFC 4124 the field is only 3 bits long. Why is it 8 bytes long in 
>> the QSPEC document?
>>   
>Technically 0 is reserved in RFC4124.   This  probably ought to be 
>reproduced in the Qspec and DIME docs.
>I take it you meant 8 bits long.  Actually, the CLASSTYPE is 32 bits in
>RFC4124 with 29 bits reserved.
>In practice it seems unlikely any extra classes will be 
>defined so the different definitions are unlikely to cause 
>issues, but given that each TLV has 32 bits it might have been 
>sensible to match the RFC4124 definition.

I have changed the description in the DIME document to use the RFC 4124
CLASSTYPE as is. 

>
>I note that RFC 4124 does not offer an IANA registry for DSTE values: 
>But the Qspec and DIME docs generate two separate registries.  
>Since the meanings are supposed to be common this doesn't make 
>a lot of sense.  
>This may apply to other Qspec and DIME registries.

I removed the registry for the  DSTE Class Types from the DIME document. 
When someone registers new values then they have to think about the
definition of registering a new QoS parameter, if necessary. 
Since these QoS parameters aren't registered too frequently I don't expect
too many actions. 

Ciao
Hannes
>
>/Elwyn
>
>> Your feedback is appreciated!
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> nsis mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nsis
>>
>>   
>

_______________________________________________
nsis mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nsis