Subject: [NSIS] questions on y1541-qosm

From: Bernd Schloer <[email-masked]>
Date: Tue, 11 Jul 2006 16:54:38 +0200

Hi Jerry,

I have some questions on your draft. Section 2.2 says:

     262    It MUST be possible to perform the following QoS-NSLP signaling
     263    functions to enable Y.1541-QOSM requirements:
     264
     265    a. accumulate delay, delay variation and loss ratio across the
     266       end-to-end connection, which may span multiple domains

How can the delay be identified across the path? AFAIK only the QNI can 
calculate the RTT since no timestamp of the QUERY msg is available at QNEs. 
Including e.g. a 32-bit long value containing the seconds since the Epoch would 
solve this.

But how can the delay variation (and loss ratio) be gathered? Is this the 
variation of every single packet, e.g. voice streaming data, compared to the 
agreed delay rate? Since multiple values are requiered this can't be done with a 
single QUERY.

These methods describe only the actual state, but don't say anything about 
future values. The values can change depending on the load of the routers.

What does it mean when a QNI gets a RESPONSE with <Y.1541 QoS Class> 0? Is this 
a guaranty that the delay never exceeds 100ms, the delay variation is always 
<=50 ms and the loss ratio <=10^-3?

Or does the network service provider has to ensure these limits as mentioned in 
section 2.1?

Thanks,
Bernd

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

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 11 Jul 2006 21:29:42 -0500

Hi Bernd,

Please see below. 

> -----Original Message-----
> From: Bernd Schloer [mailto:[email-masked]] 
> Sent: Tuesday, July 11, 2006 10:55 AM
> To: Ash, Gerald R (Jerry), ALABS
> Cc: [email-masked]
> Subject: questions on y1541-qosm
> 
> Hi Jerry,
> 

The <Path Latency> parameter is not intended as a RTT measurement from
the QNI.  As described in Section 7.2.8 of the QSPEC draft
http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt:

  "The Path Latency is a single 32-bit integer in network byte order.
   The composition rule for the <Path Latency> parameter is summation
   with a clamp of (2**32 - 1) on the maximum value.  The latencies are
   average values reported in units of one microsecond. A system with
   resolution less than one microsecond MUST set unused digits to zero.
   An individual QNE can advertise a latency value between 1 and 2**28
   (somewhat over two minutes) and the total latency added across all
   QNEs can range as high as (2**32)-2. If the sum of the different
   elements delays exceeds (2**32)-2, the end-to-end advertised delay
   SHOULD be reported as indeterminate.  A QNE that cannot accurately
   predict the latency of packets it is processing MUST raise the
   not-supported flag and either leave the value of Path Latency as is,
   or add its best estimate of its lower bound.  A raised not-supported
   flag indicates the value of Path Latency is a lower bound of the
   real Path Latency.  The distinguished value (2**32)-1 is taken to
   mean indeterminate latency because the composition function limits
   the composed sum to this value, it indicates the range of the
   composition calculation was exceeded."

Hence average values are used by each QNE in the path to determine the
cumulative <Path Latency>, which could include propagation delay,
average queuing delay, etc.
 
> agreed delay rate? Since multiple values are required this 
> can't be done with a 
> single QUERY.

<Path Jitter> and <Path PLR> are determined in analogous ways.  E.g.,
the <Path Jitter> is accumulated as described in Section 7.2.9 in the
QSPEC draft:

  "The Path Jitter is a set of three 32-bit integers in network byte
   order.  The Path Jitter parameter is the combination of three
   statistics describing the Jitter distribution with a clamp of
   (2**32 - 1) on the maximum of each value. The jitter STATs are
   reported in units of one microsecond. A system with resolution less
   than one microsecond MUST set unused digits to zero.  An individual
   QNE can advertise jitter values between 1 and 2**28 (somewhat over
   two minutes) and the total jitter computed across all QNEs can range
   as high as (2**32)-2. If the combination of the different element
   values exceeds (2**32)-2, the end-to-end advertised jitter SHOULD be
   reported as indeterminate.  A QNE that cannot accurately predict the
   jitter of packets it is processing MUST raise the not-supported flag
   and either leave the value of Path Jitter as is, or add its best
   estimate of its STAT values.  A raised not-supported flag indicates
   the value of Path Jitter is a lower bound of the real Path Jitter.
   The distinguished value (2**32)-1 is taken to mean indeterminate
   jitter.  A QNE that cannot accurately predict the jitter of packets
   it is processing SHOULD set its local parameter to this value.
   Because the composition function limits the total to this value,
   receipt of this value at a network element or application indicates
   that the true path jitter is not known.  This MAY happen because one
   or more network elements could not supply a value, or because the
   range of the composition calculation was exceeded.

   NOTE: The Jitter composition function makes use of the <Path Latency>
   parameter.  Composition functions for loss, latency and jitter may be
   found in [Y.1541]."
 
> future values. The values can change depending on the load of 

These are 'average' values rather than instantaneous or 'future' values.
 
> <=50 ms and the loss ratio <=10^-3?

It means that the cumulative <Path Latency> is < 100 ms., cumulative
<Path Jitter> < 50 ms., etc.

> Or does the network service provider has to ensure these 

As explained in Section 2.1, the Y.1541 QoS classes enable the service
provider to define SLAs based on the QoS requirements; the SP needs to
ensure that the requirements are recognized and receive appropriate
treatment (as discussed above) in the network.

Thanks,
Jerry

---

From: Bernd Schloer <[email-masked]>
Date: Wed, 12 Jul 2006 21:16:40 +0200

Hi Jerry,

ok, average values are used. But how do I get these values? The sections about 
<Path Latency> and <Path Jitter> don't describe a method which can be 
implemented. Are there any examples or source which is commonly used?

How do I get this Y.1541 Recommendation? I'm only allowed to register at itu.int 
when I belong to a certain company.

Bernd

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 13 Jul 2006 16:27:07 -0500

Hi Bernd,

Please see below. 

> Sent: Wednesday, July 12, 2006 3:17 PM
> Subject: Re: questions on y1541-qosm
> 
> Hi Jerry,
> 

The methods for cumulative <Path Latency>, <Path PLR>, <Path PER> are
described in Section 8 of the pre-published Y.1541 Recommendation
http://home.comcast.net/~acmacm/IDcheck/y1541_Rev_04.doc posted last
August to the NSIS mailing list (see
http://www1.ietf.org/mail-archive/web/nsis/current/msg05320.html).
'Average' values more or less apply to these computations, as described.
For <Path Jitter>, the cumulative computation is described in the
updated Y.1541 recommendation now being published.  This computation
estimates the pseudo range of jitter, 99.9-tile of delay minus minimum,
and uses the mean, variance, and the percentile of individual domain
distributions.

> when I belong to a certain company.

Anyone can download 3 ITU-T recommendations for free per year per email
address from the ITU web-site at
http://www.itu.int/publications/template.aspx?lang=e&menu=main&media=dow
nload&target=/publications/EBookshop.html.  With more than one email
address (easy to obtain), any number of free recommendations can be
downloaded.

Thanks,
Regards,
Jerry