Subject: [NSIS] QSPEC Questions

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 1 Nov 2008 21:11:57 +0200

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?  

* 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? 

Your feedback is appreciated!

Ciao
Hannes

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

---

From: Xiaoming Fu <[email-masked]>
Date: Sun, 02 Nov 2008 02:24:02 +0100

Some remarks to Hannes' comments:
> Useful to say something about the difference?  

I suppose the intention was alike SENDER_TSPEC and FLOWSPEC in 
[rfc2210], respectively? (But a quick read into current version of QOSMs 
does not entail TMOD-2.)
> come from? There is no reference to another RFC given in these sections.

QSPEC ID suggested packet jitter is based on [rfc3393], but I am not 
sure whether (nominal) jitter values are directly addable across 
multiple hops.
Also, is PLR or PER directly addable (or just a multiplication)?
Xiaoming

(... snip)

---

From: Elwyn Davies <[email-masked]>
Date: Sun, 02 Nov 2008 10:14:07 +0000

> 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.

> In RFC 4124 the field is only 3 bits long. Why is it 8 bytes long in the
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 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.

/Elwyn

---

From: Elwyn Davies <[email-masked]>
Date: Sun, 02 Nov 2008 15:18:41 +0000

> come from? There is no reference to another RFC given in these sections.
Y.1541... 
http://www.watersprings.org/pub/id/draft-ietf-nsis-y1541-qosm-06.txt
> * Why is Path Jitter STAT4(Reserved) included in the <Path Jitter>
Repeat of something in Y.1541 QOSM
Don't have a copy of Y.1541 itself and there is no justification in the 
draft.

/E

---

From: Gerald Ash <[email-masked]>
Date: Sun, 2 Nov 2008 10:40:35 -0800 (PST)

Hannes,
 
> From: Hannes Tschofenig <[email-masked]>
> Subject: [NSIS] QSPEC Questions
> To: [email-masked]
> Date: Saturday, November 1, 2008, 3:11 PM
> 
> 
 
Discussed in some detail in Section 3.3.1 (as Elwyn pointed out).

> come from? There is no reference to another RFC given in these sections.
 
References for <Path Jitter> are [RFC3393], [Y.1540], [Y.1541], as given in Section 3.3.2.
Reference for <Path PLR> is [Y.1541], as given in Section 3.3.2.
Reference for <Path PER> is [Y.1541], as given in Section 3.3.2.
 
These references should also be added to the headings of Sections 5.2.4, 5.2.5, and 5.2.6, respectively.

> * Why is Path Jitter STAT4(Reserved) included in the <Path Jitter>
 
The computation of Path Jitter is discussed in [Y.1541], including numerical examples.  Perhaps Al Morton (editor of [Y.1541]) can provide explanatory text to add to the QSPEC document.

> In RFC 4124 the field is only 3 bits long. Why is it 8 bytes long in the
 
I agree with Elwyn that the QSPEC DSTE Class Type parameter should be aligned with RFC 4124.  It also appears that an IANA registry is not needed since none is defined in RFC 4124.
 
Jerry

---

From: Gerald Ash <[email-masked]>
Date: Sun, 2 Nov 2008 10:53:04 -0800 (PST)

> Don't have a copy of Y.1541 itself 
 
Available at http://www.itu.int/rec/T-REC-Y.1541/en.
 
All ITU Recommendations are freely available at http://www.itu.int/ITU-T/publications/recs.html.
 
Jerry

---

From: Al Morton <[email-masked]>
Date: Thu, 06 Nov 2008 12:43:50 -0500

At 09:24 PM 11/1/2008, Xiaoming Fu wrote:
>...
>sure whether (nominal) jitter values are directly addable across multiple hops.

It's possible to accumulate Jitter values, if they're measured
and specified in the appropriate form.
The more detailed references include Rec Y.1541,
http://tools.ietf.org/html/draft-ietf-ippm-spatial-composition-07
http://tools.ietf.org/html/draft-ietf-ippm-delay-var-as-01
>Also, is PLR or PER directly addable (or just a multiplication)?

see the first two refs above.
Al

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 6 Nov 2008 22:14:45 +0200

Al, 

shouldn't we provide that type of context in the document as well? 
They document does not appear self contained enough so that a regular reader
can understand it easily. 

Ciao
Hannes

>-----Original Message-----
>From: Al Morton [mailto:[email-masked]] 
>Sent: 06 November, 2008 19:44
>To: Xiaoming Fu; Hannes Tschofenig
>Cc: [email-masked]
>Subject: Re: [NSIS] QSPEC Questions
>
>>>* 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.
>>

---

From: Al Morton <[email-masked]>
Date: Thu, 06 Nov 2008 16:10:15 -0500

>shouldn't we provide that type of context in the document as well?

I agree, perhaps that's why I dug-up the details
and shared them on the list. These are non-trivial
calculations in some cases, but procedures exist.

Al

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 8 Nov 2008 17:27:49 +0200

Hi Elwyn, 

Thanks for your feedback.  

>From: Elwyn Davies [mailto:[email-masked]] 
>Sent: 02 November, 2008 12:14
>To: Hannes Tschofenig
>Cc: [email-masked]
>> 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:
>>
I wonder how I was able to have missed that description. 

>> http://tools.ietf.org/id/draft-ietf-tsvwg-emergency-rsvp-09.txt. The 
>> ALRP Priority and the Reserved octets positions are inversed.
>>
>> In RFC 4124 the field is only 3 bits long. Why is it 8 bytes long in 
>> the QSPEC document?
>>   
>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. 

>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.  

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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 8 Nov 2008 18:15:34 +0200

Hi Jerry, 
 	
			Hannes,
	 
	> From: Hannes Tschofenig <[email-masked]
<mhtml:{B096A9AC-8D5F-4D5A-AACE-EC56A1B5E65A}mid://00000166/!x-usc:mailto:Ha
[email-masked]> >
	> Subject: [NSIS] QSPEC Questions
<mhtml:{B096A9AC-8D5F-4D5A-AACE-EC56A1B5E65A}mid://00000166/!x-usc:mailto:ns
[email-masked]> 
	> Based on Dan's AD review comments for
draft-ietf-dime-qos-parameters-06 I

Thanks. 

	> come from? There is no reference to another RFC given in these
sections.
	 
	References for <Path Jitter> are [RFC3393], [Y.1540], [Y.1541], as
given in Section 3.3.2.
	Reference for <Path PLR> is [Y.1541], as given in Section 3.3.2.
	Reference for <Path PER> is [Y.1541], as given in Section 3.3.2.
	 
	These references should also be added to the headings of Sections
5.2.4, 5.2.5, and 5.2.6, respectively.

Thanks. 

	> * Why is Path Jitter STAT4(Reserved) included in the <Path Jitter>
	 
	The computation of Path Jitter is discussed in [Y.1541], including
numerical examples.  
    Perhaps Al Morton (editor of [Y.1541]) can provide explanatory text to
add to the QSPEC document.

Thanks. 

	> http://tools.ietf.org/id/draft-ietf-tsvwg-emergency-rsvp-09.txt
<mhtml:{B096A9AC-8D5F-4D5A-AACE-EC56A1B5E65A}mid://00000166/!x-usc:http://to
ols.ietf.org/id/draft-ietf-tsvwg-emergency-rsvp-09.txt> . The ALRP
	> In RFC 4124 the field is only 3 bits long. Why is it 8 bytes long
in the
	 
	I agree with Elwyn that the QSPEC DSTE Class Type parameter should
be aligned with RFC 4124.  It also appears that an IANA registry is not
needed since none is defined in RFC 4124.

I deleted the IANA registry from the DIME document and aligned the parameter
encoding with the one described in RFC 4124. 

Ciao
Hannes

	Jerry