Subject: Re: [NSIS] AD comments on draft-ietf-nsis-qspec-21

From: Magnus Westerlund <[email-masked]>
Date: Fri, 23 Oct 2009 11:26:53 +0200

Hi Jerry,

I suggest changes looks fine unless commented. I have removed everything
where your response resolves the issues. Looking forward to a new version.

Gerald Ash skrev:
>> --- On Fri, 10/2/09, Magnus Westerlund <[email-masked]>
>> wrote:
>> 10. Section 3.3.2: What is the definition of path error ratio?
>  
> Per the definition in Y.1540 and Y.1541:
> "Packet error ratio is the ratio of total errored IP packet outcomes to
> the total of successful IP packet transfer outcomes plus errored IP
> packet outcomes in a population of interest, with a resolution of at
> least 10–9.  If lesser resolution is available in a value, the unused
> digits shall be set to zero."
> Will also add that the number of errored packets observed is directly
> related to the confidence in the result. 

Thanks, please add a reference to the definition.

>  
>> 11. This may seem out of context but I do want to know the answer to how
>> the situation is handled when QNI and QNR are neighbors on a non QoS
>> enabled network.
>  
> What "situation" are you referring to here?  IMO you can't have a QNI
> and QNR in a "non QoS enabled network".  By definition, a QNI and QNR
> are only defined in an NSIS enabled network (i.e., a QoS enabled network).

I am asking what is happening in these cases where a QNI has the QNR as
peer and there are no network support. Clearly you will not get any QoS,
but is it clear to both QNI and QNR that this is the situation?

>  
>> 15. Section 5.1.1:
>> "   Length: The total length of the QSPEC excluding the common header"
>>
>> Please make it clear that you count in 32-bit words (?) and add the "."
>> at the end of the sentence.
>  
> "Length" is defined at the beginning of Section 5.1 as follows:
> "   o Length has the units of 32-bit words, and measures the length of
> 
>      Value.  If there is no Value, Length=0.  The Object length
> 
>      excludes the header."
> 
>  
> 
> The sentence you quote above in Section 5.1.1 will also be clarified as
> follows:
> 
> "   Length: The total length of the QSPEC (in 32-bit words) excluding
> the common header"
>  

good, because it is not obvious that the text in 5.1 applies to the
common header as it isn't a TLV structure.

> 
>> 19. Section 5.2.3: The referenced documents does not define Path
>> latency, only minimal path latency. Not obvious that they are the same,
>> for example from a perspective of queuing delay or link ARQ.
> 
>  
> 
> The intention of the Path Latency parameter is the same as the Minimal
> Path Latency parameter defined in Section 3.4 of RFC 2215.  Note that it
> also says in RFC 2215:
> 
>  
> 
> "The purpose of this parameter is to provide a baseline minimum path
>    latency for use with services which provide estimates or bounds on
>    additional path delay, such as Guaranteed [RFC 2212]..  Together with
>    the queuing delay bound offered by Guaranteed and similar services,
>    this parameter gives the application knowledge of both the minimum
>    and maximum packet delivery delay."
> 
>  
> 
> This is also the intent of the parameter for use in the QSPEC.
> 

Yes, but nit-picking here I do think you could make it clear that the
QSPEC parameter is defined as "minimal path latency in RFC 2215".

> 
>> 27. Section 7.. QSPEC Procedures. This table is so confusing, I can't get
>> my head around what code point space is registered. And if there are a
>> second dimension for certain values and in that case which that is.
> 
>  
> 
> The QSPEC Procedures object being registered by IANA specifications in
> Section 7 is specified in Section 5.1.1 (Common Header Format). 
> The code point space consists of a Message Sequence sub-parameter and an
> Object Combination sub-parameter.  Section 4.3 explains the Message
> Sequence and Object Combination sub-parameters.  Object Combinations 0,
> 1, and 2 are explained in Section 4.3.1, 4.3.2, and 4.3.3,
> respectively.  Tables 1, 2, and 3 in Section 4.3 assign the Message
> Sequence ID to Object Combinations 0, 1, and, 2, respectively.  There is
> an error to be corrected in the IANA specifications: Object Combination
> 2 (Section 4.3.3) has only one Message Sequence ID, not 3 (this will be
> corrected.  Hopefully this explains whatever confusion there is here.
> 

I think one of the bigger issues is that it is compact without any line
spacing or indentation to make the structure clear.

>  
>> 28. References: Can you please ensure that there is a blank line between
>> each reference. Now it is very difficult to read the list.
> 
>  
> 
> OK
> 
>  
> 
>> Also, making
>> the reference using a hanging style makes it easier to find the
>> reference identifiers.
> 
>  
> 
> Not sure what you mean by "hanging style"?  Do you mean to indent the
> references, e.g.,
> 
>  
> 
> [3GPP-1] 3GPP TS 22.067 V7.0.0 (2006-03) Technical Specification, 3rd
>                Generation Partnership Project; Technical Specification Group
>                Services and System Aspects; enhanced Multi Level
> Precedence and
>                Preemption service (eMLPP) - Stage 1 (Release 7).
> 
>  
> If so, OK.

Yes, that is what I mean.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 24 Oct 2009 07:33:55 +0000

Hi Magnus

>but is it clear to both QNI and QNR that this is the situation?

I think that the solution for this situation is provided by QoS-NSLP. In
particular, this situation is detected by uing the generic flag BREAK
(B), see Section 5.1.1 Common header, in the QoS-NSLP draft, see below:

BREAK (B) - when set, indicates that there are routers along the path
where QoS cannot be provided.

Maybe it will be good to add a sentence in the QSPEC draft that
emphasizes."

"As specified in QoS-NSLP, when there are routers along the path between
QNI and QNR where QoS cannot be provided then the QoS-NSLP generic flag
BREAK (B) is set."

Best regards,
Georgios

---

From: Gerald Ash <[email-masked]>
Date: Mon, 26 Oct 2009 10:48:05 -0700 (PDT)

Hi Georgios,
 
I agree with your suggestion, thank you for that.
 
Magnus, does Georgios' suggestion take care of your comment #11?
 
Thanks,
Regards,
Jerry

--- On Sat, 10/24/09, Georgios Karagiannis <[email-masked]> wrote:

From: Georgios Karagiannis <[email-masked]>
Subject: Re: [NSIS] AD comments on draft-ietf-nsis-qspec-21
To: "Magnus Westerlund" <[email-masked]>, "Gerald Ash" <[email-masked]>
Cc: "David Black" <[email-masked]>, "[email-masked]" <[email-masked]>, "NSIS" <[email-masked]>
Date: Saturday, October 24, 2009, 3:33 AM

Hi Magnus

Best regards,
Georgios

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 29 Oct 2009 17:49:39 +0100

Hi,

Yes, I was more interested in the answer than necessary addition to the
documents. However, the text proposal is good.

Sorry for not being able to respond before the cut-off.

/Magnus

Gerald Ash skrev:
> --- On *Sat, 10/24/09, Georgios Karagiannis /<[email-masked]>/*
> wrote:
> 
> 
>     Cc: "David Black" <[email-masked]>,
>     "[email-masked]"
>     <[email-masked]>, "NSIS" <[email-masked]>

-- 

Magnus Westerlund