Re: AD comments on draft-ietf-nsis-qspec-21

Hi Magnus,

Thank you for the review. Your comments seemed valid to me, and I'd like 
to hear the authors' replies and estimation when we could have an 
updated draft.

Cheers,
Jukka (on to analyzing my own feedback on the nslp ;)

Magnus Westerlund wrote:
> Hi,
> 
> Very sorry for the long delay in getting this review completed.
> 
> 1. Section 1. last paragraph: I don't think "worked example" is easily
> understood. Can you find another word?
> 
> 2. Section 3.1:
> - QSPEC parameter behavior for new QSPEC parameters the QOSM
>      behavior (tear down preempted reservation) is not followed (see
>      specification defines
>    - define what happens in case of preemption if the default QNI
>      Section 4.3.5)
> 
> Some editing issues here around the second parenthesis in the first
> bullet. It closes in the second bullet.
> 
> 3. Section 3.2:
> "QSPEC
>    parameters are the parameters appearing in a QSPEC, which must
>    include traffic (TMOD),  ..."
> 
> I do believe there is a missing word between traffic and "(TMOD).
> 
> 4. Section 3.2, second paragraph:
> 
> "IANA
>    assigns a new QSPEC version number when changes that are not
>    backwards compatible are made to the QSPEC and this document is
>    reissued. "
> 
> and
> "Later QSPEC versions MUST be
>    backward compatible with earlier QSPEC versions."
> 
> The two sentences are contradicting. Please make it clear when new
> version is needed.
> 
> 5. Section 3.3.1: The 4 sub-parameters can you please specify units for
> them?
> 
> 6. Section 3.3.1: You don't seem to have a definition of what "minimum
> policed unit" is. I assume that this definition from RFC 2211 is
> applicable, but still either include it or reference it.
> 
>    The minimum policed unit, m, is an integer measured in bytes.  All IP
>    datagrams less than size m will be counted against the token bucket
>    as being of size m."
> 
> 7. Section 3.3.1: What is the definition of peak rate? I understand that
> the "rate" is a uniform filling rate of the token bucket. However, peak
> rate implies that it is not a smoothed value nor has its own bucket
> depth parameter. So please provide a definition.
> 
> 8. Section 3.3.2: " This delay
>    results from the combination of speed-of-light propagation delay,"
> 
> Wouldn't it be clearer to say "link" instead of speed-of-light.
> Especially in cases where the link has retransmission or other features
> that makes the links propagation delay not solely be dependent on the
> speed-of-light in the medium used.
> 
> 9. Section 3.3.2: "Furthermore, the
>    QNI MUST add the propagation delay of the ingress link, if this link
>    exists."
> 
> How, is the QNI supposed to know the propagation delay of the ingress
> link? I agree that there are cases where this can be configured, but
> there appear to be a number of cases when it would not be the case.
> Therefore I am a bit questioning a MUST on something that may not be
> possible to perform.
> 
> 10. Section 3.3.2: What is the definition of path error ratio?
> 
> 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.
> 
> 12. Section 4.2.1:
> "Note that
>    the TMOD parameter and all QSPEC parameters with the M flag set MUST
>    be examined by the RMF, and all QSPEC parameters with the M flag not
>    set SHOULD be examined by the RMF, and appropriately flagged."
> 
> What is meant with appropriately flagged in the above sentence?
> 
> 13. Section 5.1.1: Even if version numbers are assigned by IANA I think
> the spec should be explicit on which version this one defines. Also as
> being the first version, I think assigning it yourself would be fully
> appropriate.
> 
> 14. Section 5.1.1.: QSPEC Type: I think this should have a pointer to
> the IANA registry.
> 
> 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.
> 
> 16. Section 5.1.2: "Parameter ID: Assigned to each parameter (see below)"
> 
> The text below this does not discuss parameter ID in any useful way.
> Please correct that or provide a better reference to where it is discussed.
> 
> 17. Section 5.2.1:
> "he <TMOD> parameters are represented by three floating point
>    numbers in single-precision IEEE floating point format followed by
>    one 32-bit integer in network byte order."
> 
> Please add a reference for the IEEE floating point format.
> 
> 18. Section 5.2.1: I don't think the reference in the section title is
> particular helping. I definitely prefer explicit references for each
> item so that you easily can find them. There is also a risk for
> confusion if multiple references are not agreeing on a parameter
> definition. For example take the "minimum policed unit". What it is is
> defined in RFC 2210, but there is also redundant interpretation text in
> RFC 2215. I also have a hard time determining if any reference is missing.
> 
> 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.
> 
> 20. Section 5.2.4: Once more the references are unclear. Especially as
> RFC 3393 doesn't use "jitter". You need to be explicit about what is what.
> 
> 21. Section 5.2.5: First of all I am not convinced by looking in Y.1541
> that packet loss ratio has a clear definition. I am missing what type of
> averaging is assumed in the value. If you going to measure this value
> you need to do it over sufficiently many packets, measuring over 7
> packets with one loss doesn't say much.
> 
> 22. Section 5.2.5: " An
>    individual QNE can advertise a PLR value between zero and 10^-2
>    and the total PLR added across all QNEs can range as high as 10^-1."
> 
> Isn't the restriction to advertise a link PLR no higher than 10^-2 a to
> strict limit. Doesn't there exist links out there that has that level of
> loss. Maybe not ones that you usually request QoS over, but anyway.
> 
> 23. Section 5.2.11:
> "When the shaping causes
>    unbounded queue growth at the shaper traffic can be dropped."
> 
> To me the shaping seems unclear, as it contains a unknown factor of the
> queue used. Both queue depth and dropping model would influence how the
> shaping happens.
> 
> 24. Section 5.2.11:
> Remark Value (6 bits): indicates either drop (set to 0) or DSCP
>                           value [RFC2474] to remark packets to when
>                           identified as excess
> 
> So you can't remark traffic into the best-effort traffic class? Isn't
> that a severe limitation? And why are there need for two ways of marking
> drop as excess treatments?
> 
> 25. Section 5.2.12:
> 
>    0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |M|E|N|r|           12          |r|r|r|r|          1            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | DSCP      |0 0 0 0 0 0 0 0 0 0|            (Reserved)         |
>    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> 
> Two comments about the field definition for the third 16-bit word.
> 
> First, why is one of the possible field value represented rather than
> giving the field a name. That way one can make it clear that the
> possibility for different structures in that 16-bit word. I would
> probably have defiend it as:
> 
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> | PH Field Value            |EN |
> 
> I do understand that would be different from how RFC 3140 is
> representing the information, but be equivalent. As an alternative I
> would simple change the first diagram to say instead of DSCP   | 0 0 ...
> to say PHB Field. Anyway, I think the current representation is unclear.
> 
> 26. Section 7. There are registries that requires standard action for
> new registrations. I think that is not consistent with publishing this
> as experimental. Please address.
> 
> 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.
> 
> 28. References: Can you please ensure that there is a blank line between
> each reference. Now it is very difficult to read the list. Also, making
> the reference using a hanging style makes it easier to find the
> reference identifiers.
> 
> 29. Appendix B has alignment issues in the Protocol header length table.
> 
> 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 protected]
> ----------------------------------------------------------------------
> _______________________________________________
> nsis mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nsis

-- 
Jukka MJ Manner, Professor, PhD.  Phone:  +358+(0)9+451 2481
Helsinki University of Technology Mobile: +358+(0)50+5112973
Department of Communications      Fax:    +358+(0)9+451 2474
and Networking (Comnet)           Office: G320 (Otakaari 5A)
P.O. Box 3000, FIN-02015 TKK      E-mail: [email protected]
Finland                           WWW:    www.comnet.tkk.fi