[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[NSIS] AD comments on draft-ietf-nsis-qspec-21
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: magnus.westerlund at ericsson.com
----------------------------------------------------------------------