Subject: RE: [NSIS] RE: questions on y1541-qosm

From: "Roy, Radhika R." <[email-masked]>
Date: Wed, 12 Jul 2006 09:57:33 -0400

Hi, Bernd:
 
The draft makes some "factual" statements to "gather" statistics of "e2e
delay, e2e jitter, and e2e path loss." The field are there also defined.
 
These answers have made one of the technical clarifications: All statistics
gatherings are based on "average."
 
Like you, I am also confused due to the following:

1.	

	ITU-T Y.1541 QoS model is based on the "precise" value of each
performance parameter of "e2e delay, e2e jitter, and e2e path loss" for each
so-called QoS class. So, the Y.1541-QOSM draft MUST define the "exact" clear
mechanism for calculation of each parameter using mathematical formulae that
need to be used by all Service Providers (SPs) so that no technical dispute
arises. For example, in RSVP standard, mathematical formulae are being
defined how to proceed with calculations of delay, jitter, etc.
2.	

	The Y.1541-QOSM draft MUST also provide the actual technical
mechanisms for measurements/calculations instead of "factual" statements
like: "statistics gathering," and those statistics represent "average"
values. If this draft does not define this, what value does this draft add
to the IETF because there can be a wide variations in "values" of the
so-called statistics collections if they are not based on the same
mathematical formulae as can be seen as an example in RSVP?
3.	

	Will the Y.1541-QOSM draft not sew the seeds for technical discords
among the service providers if it does not define the exact mathematical
formulae for measurements/calculations where a variation of " a few 10s of
milliseconds in delays and jitters" will cause changes from one Y.1541 QoS
class to another or even non-compliance of QoS-classes service contracts?

Please more inline [RRR].
 
Best regards,
Radhika R. Roy

  _____  

From: [email-masked] on behalf of Ash, Gerald R (Jerry), ALABS
Sent: Tue 7/11/2006 10:29 PM
To: Bernd Schloer
Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
Subject: [NSIS] RE: questions on y1541-qosm

Hi Bernd,

Please see below.

> -----Original Message-----
> From: Bernd Schloer [mailto:[email-masked]
<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,
>
> 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.

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.

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

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

These are 'average' values rather than instantaneous or 'future' values.

[RRR] What is the mathematical formula used to calculate these performance
parameters representing "AVERAGE" that all SPs can use?

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

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

[RRR] What is the mathematical formula used to calculate these performance
parameters so that all SPs can use to have a common reference, for example,
similar to that defined in RSVP?

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

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

> Thanks,
> Bernd

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

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

---

From: "Roy, Radhika R." <[email-masked]>
Date: Thu, 13 Jul 2006 19:12:49 -0400

Bernd and all:
 
Has not been instructed by AD last time that ITU-T specs need to be posted
in a Web site, like IETF's Web site, that can be accessed by all IETF
members?
 
If so, why do the IETF members need to download those ITU-T specs with fees
because it not for anyone's personal use?
 
Where is this liaison for between the IETF and the ITU-T to create
standards? 
 
Best regards,
Radhika R. Roy

  _____  

From: [email-masked] on behalf of Ash, Gerald R (Jerry), ALABS
Sent: Thu 7/13/2006 5:27 PM
To: Bernd Schloer
Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
Subject: [NSIS] RE: questions on y1541-qosm

Hi Bernd,

.

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
<http://www.itu.int/publications/template.aspx?lang=e&menu=main&media=dow>
&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.