Subject: RE: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 6 Jul 2006 15:43:34 +0100

hi all,

some wglc comments. most are minor/editorial-ish.

in general, i thought i could understand the document and follow what
it was defining. however, that might be because i am too close to the
subject matter to see the ambiguities. i wonder whether there might be
value in having space in an appendix for more examples (not that I have
anything specific to contribute here).

1) section 4.2 p9 para 3 ("When reserving..."): maybe worth clarifying
here that the terms ingress/egress apply to the direction of the RESERVE
rather than the direction of the flow. (possibly applies elsewhere.)

2) para 4 but also elsewhere: i found the formatting confusing in 
several places where lists get run together like this. for example,
i can't immediately tell whether the last sentence in the paragraph
applies to (c) or to (a) and (b) as well.

3) page 11 last para: this seems to assume that there is an INTSERV-QOSM
whereas in fact none is being defined. but it raises a more general
point:
where in the document to look for a summary of the QOSM concept. To me,
it would be good to have a (small) dedicated section somewhere near the
start.

4) page 12 para 3 ("Case 1"): I would prefer to replace phrasing like
'the QNx notifies the QNI' with something like 'the QNx generates a
RESPONSE'. partly this is because in the past there have been genuine
proposals that a QNx could send a message directly to the QNI, and
partly
because notify may get confused with NOTIFY. people who are fully
familiar
with the QoS-NSLP spec may be ok with this, but the casual reader may
not.
(also applies elsewhere.)

5) section 4.4.1: what treatment is required at the QNR? 

6) section 4.5 page 15 2nd last para, also 4.5.3: I found the tunneling 
description here rather confusing at first, and eventually came to the
conclusion that I don't like the T flag in the first place. my 
reasoning is as follows:

- there are several cases where a QNE has to make a judgement call about
whether it has strictly interpreted a parameter or not; in the latter
case it can set the <NON QOSM Hop> flag to say so.

- i see the tunnel case as just one more example of this, which is not
really special in its own right.

- for example, suppose a reservation goes across an MPLS cloud rather
than an RSVP aggregation cloud. no T flag would be set in the MPLS case
since it's just 1 hop across (a.k.a. the tunnelling is not visible at
the IP level). however, do we really believe that the interpretation 
is any more accurate because of that?

7) section 4.6 last para: i remember this point came up at the last
IETF and I still hold the view that it would be more sensible for this
information about Qspec-related codepoints to be in the Qspec document.
(this information isn't in any case in the extensibility document at
the moment.)

8) section 5.2.1: i think the grammar of this section could be more
clear about whether the sets of objects on the right hand side of '='
are alternatives, things you can have >1 of, options, etc.

9) section 5.2.2, all references to 'queuing delay bound': the
discussion
seems to imply that this parameter can be carried in the Qspec
independently
of PL, but I don't see how. (two occurrences in this section.)

10) section 5.2.2: there is no discussion of <Path PER>

11) section 5.2.2: there are multiple references to the QNR having to do
something for the egress link for the cumulative parameters. I don't
see what this could mean.

12) section 7.1: box diagram says 'Parameter ID' but text says
'Parameter Type'

13) section 7.2.7: i don't see how to relate the multiple priority 
parameters. What if someone provides both the rfc3181 parameters
and the admission/RPH parameters?

14) section 7.2.8/9/10/11: if N is set in these parameters when 
a QNE receives the message, does it still have to process the
parameter value?

15) section 7.2.9: if Y.1541 is needed to define the composition
function,
it should be a normative reference, and should be referred to from 
7.2.8 and 7.2.10 as well. OTOH since it is not freely available, would
it be possible to include the corresponding formulae here?

16) section 7.2.10/11: i assume the comments about microsecond time
resolution are cut&paste artifacts.

cheers,

robert h.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 26 June 2006 11:31
> To: [email-masked]; [email-masked]
> Subject: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt
> 
> 
> Hi all,
> 
> Jerry has submitted the QoS NSLP QSPEC Template.  You can find the
> announcement & Jerry's comments below.
> 
> The WGLC will run until July 7th.  After that, Jerry can summarize all
> issues and we will discuss them at the next IETF meeting in Montreal.
> 
> thanks,
> John 
> 
> >-----Original Message-----
> >From: ext Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
> >Sent: 23 June, 2006 23:16
> >To: [email-masked]
> >Cc: Ash, Gerald R (Jerry), ALABS
> >Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-10.txt 
> >
> >Hi All,
> >
> >The updated 'QoS-NSLP QSPEC Template' I-D is available at 
> >http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt.
> >
> >The updates are in response to comments and discussion since IETF-65:
> >
> >1. rewrote Section 2 (Introduction) for clarity 2. added 
> >clarifications on mandatory parameters in Section 4.2; added 
> >discussion of forwarding options when a domain supports a 
> >different QOSM than the QNI 3. expanded Section 4.5 on error 
> >code handling, including redefined E-Flag and editorial 
> >changes to the N-Flag and T-Flag discussions 4. made some 
> >editorial clarifications in Section 4.6 on defining new 
> >mandatory parameters 5. Section 4.7 added to identify what a 
> >QOSM specification document must include 6. clarified the 
> >requirements in Section 5 for defining a new QSPEC Version 7. 
> >made editorial changes to Section 6 (Procedures), and added 
> >procedures for handling preemption 8. removed QOSM ID 
> >assignments in Section 9 (IANA Considerations); clarified 
> >procedures for defining new mandatory parameters; added 
> >registry for QOSM error codes
> >
> >There are no further outstanding changes/comments pending and 
> >no open issues currently identified.
> >
> >Thanks,
> >Regards,
> >Jerry 
> >
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]
> >Sent: Friday, June 23, 2006 3:50 PM
> >To: [email-masked]
> >Cc: [email-masked]
> >Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-10.txt 
> >
> >A New Internet-Draft is available from the on-line 
> >Internet-Drafts directories.
> >This draft is a work item of the Next Steps in Signaling 
> >Working Group of the IETF.
> >
> >	Title		: QoS NSLP QSPEC Template
> >	Author(s)	: J. Ash, et al.
> >	Filename	: draft-ietf-nsis-qspec-10.txt
> >	Pages		: 53
> >	Date		: 2006-6-23
> >	
> >The QoS NSLP protocol is used to signal QoS reservations and 
> >is independent of a specific QoS model (QOSM) such as IntServ 
> >or DiffServ.  Rather, all information specific to a QOSM is 
> >encapsulated in a separate object, the QSPEC.  This document 
> >defines a template for the QSPEC, which contains both the QoS 
> >description and QSPEC control information. The QSPEC format is 
> >defined, as are a number of QSPEC parameters.  The QSPEC 
> >parameters provide a common language to be re-used in several 
> >QOSMs.  To a certain extent QSPEC parameters ensure 
> >interoperability of QOSMs.  Optional QSPEC parameters aim to 
> >ensure the extensibility of QoS NSLP to other QOSMs in the future.
> >The node initiating the NSIS signaling adds an Initiator QSPEC 
> >that must not be removed, thereby ensuring the intention of 
> >the NSIS initiator is preserved along the signaling path.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt
> >
> >_______________________________________________
> >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: "Roy, Radhika R." <[email-masked]>
Date: Tue, 11 Jul 2006 13:51:34 -0400

Robert:

I agree with you. In addition, I have added my comments inline [RRR]
with more elaboration.

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Hancock
Sent: Tuesday, July 11, 2006 12:58 PM
To: 'Ash, Gerald R (Jerry), ALABS'; 'NSIS'
Subject: RE: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt

hi jerry,

some comments on some of the comments:

> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 

> > From: Hancock, Robert [mailto:[email-masked]] 

[snip]

> Can you point us to what "QSPEC-related codepoints" you're 
> referring to here?

the paragraph in question is
"   Guidelines on the technical criteria to be followed in evaluating
   requests for new codepoint assignments are given for the overall NSIS
   protocol suite in a separate NSIS  extensibility document
   [NSIS-EXTENSIBILITY]."

This applies to all NSIS codepoints. My point is that it still seems 
preferable (to me) that Qspec related codepoints - i.e. the registries
you define in section 9 - should have the guidelines in the qspec
itself.

[RRR] Robert is right as QSPEC is the generic draft that will provide
the general guidelines for the codepoints that are not specific to any
QoS models. Y.1541 draft will deal with its QoS-model-specific
codepoints.

> I'm not sure what is unclear in the references to QNR actions.  E.g.,
> for jitter is says:
> 
> " Each QNE MUST add the jitter of its outgoing link, which
>    includes the QNR adding the associated jitter for the egress link.
>    Furthermore, the QNI MUST add the jitter of the ingress link."
> 
> Any suggestions on how to make this clearer?

maybe if i understood it...

take the trivial situation of a single link:

QNI ----------- QNR

the draft says (here for jitter): 
  "Each QNE MUST add the jitter of its outgoing link, which
   includes the QNR adding the associated jitter for the egress link. 
   Furthermore, the QNI MUST add the jitter of the ingress link."

my question is, how many contributions to the e2e jitter are there?
i would have thought that for a single link the expression would be
a single term, but the draft implies two terms (one from QNI and one
from QNR). but adding one more link would add only one term. i don't
see how this would work.

[RRR] I see, if it is end-to-end codec, for example voice/video, it will
be able to measure the end-to-end jitter per packet/frame on "aggregate"
to playing out the buffer. Again, in no way, this jitter will provide
any meaningful statistics specific to a given packet/frame of
voice/video traffic. The same is also applicable for "end-to-end delay"
and "packet loss."

[RRR] Then the most interesting question comes is this that Robert has
already raised the valid technical skepticisms: 1. How will it work to
specify/measure the "jitter" individually in the "middle" of the network
that Y.1541 is attempting to specify/measure as contributions as a part
of the e2e jitter/delay/packet loss of a given packet that is a part of
IP network layer (not in the "specific" e2e codec application layer at
the "last" end) where contributions in jitter/delay/packet loss may come
many different sources? 2. Is it possible to do so in the real-network
per QNI/QNR basis as Y.1541 envisions?

[RRR] The more important question is this: What does Y.1541 performance
parameter (e2e delay, e2e jitter, or e2e packet jitter) specify? Is it
the over all "aggregate" behavior of "any" packet that passes over
between the QNI/QNR? Or, is it for each packet that each application
(e.g., audio, video, or data) sends?

[snip]

cheers,

r.

---

From: "Roy, Radhika R." <[email-masked]>
Date: Wed, 12 Jul 2006 10:17:40 -0400

Hi, Robert;
 
As I also mentioned in Bernd's email, the gathering of statistics of "e2e
delay, e2e jitter, and e2e path loss" between QNI and QNR is rather a
"factual" statement. The key questions are as follows: 

*	

	How do we measure/collect the statistics if the draft does not
provide the precise mathematical formulae for all these performance
parameters as can be seen as an example in RSVP?
*	

	How will the Service Providers (SPs) ensure that the "average"
statistics collected by all parameters are the based on the common
mathematical formulae/measurements 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 see inline [RRR].
 
Best regards,
Radhika

> from QNR). but adding one more link would add only one term. i don't

I think you picked up a problem with the text that I hadn't noticed
before:

  "Each QNE MUST add the jitter/delay of its outgoing link, which
   includes the QNR adding the associated jitter/delay for the egress
link.
   Furthermore, the QNI MUST add the jitter/delay of the ingress link."

Should say:

  "Each QNE MUST add the jitter/delay of its outgoing link (if it
exists).
   Furthermore, the QNI MUST add the jitter/delay of the ingress link
   (if it exists)."

The diagram we had in mind for your 'single link trivial situation' is a
follows:

    a                b               c
----------- QNI ----------- QNR -----------

The QNI adds the jitter/delay of links a and b (if it exists), and the
QNR adds the jitter/delay of link c (if it exists).  If link a and/or
link c do not exist, then the delay/jitter is not included of course in
the cumulative value.

[RRR] Please see note provided above.

Thanks,
Regards,
Jerry

---

From: "Roy, Radhika R." <[email-masked]>
Date: Wed, 12 Jul 2006 10:42:08 -0400

Hi, Bernd, Robert, and all:
 
Now it is also time to collect all information from ITU-T related to Y.1541
through IETF liaison to establish the rational and creditability for all
precise "values" of all performance parameters. The followings are noted,
not limited to:

1.	

	Simulation results and/or mathematical analysis for rational in
defining the precise values of e2e delay, e2e jitter, and e2e path loss in
defining each Y.1541 QoS class.
2.	

	Mathematical formulae for calculations/measurements of e2e delay,
e2e jitter, and e2e path loss.

If nothing is available from ITU-T, we, in IETF, have to define at least
item 2 before the Y.1541-QOSM draft goes forward.

Best regards,

Radhika R. Roy

  _____  

From: Roy, Radhika R.
Sent: Wed 7/12/2006 10:17 AM
To: Robert Hancock; [email-masked]
Cc: NSIS
Subject: RE: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt

Hi, Robert;

*	

Please see inline [RRR].
 
Best regards,
Radhika