Note: This ballot was opened for revision 12 and is now closed.
Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.
> Metrics defined in this memo SHOULD be registered in the IANA IPPM
> METRICS REGISTRY as described in initial version of the registry
I think it would be better to say "IANA is asked to register..."
instead of using SHOULD.
I wasn't completely clear that this definition is IP-version
independent (for example, there is a generic reference
to RFC 791 but not RFC 2460).
Gen-ART review comments from Sharon Chisholm:
1. In section 2, first paragraph, the term 'backwards step' is used but
not defined, either explicitly or with reference to another document.
Similarly, the terms 'non-reversing reference value' is also used
without definition of reference.
2. In section 3.5, I had difficulty parsing the second paragraph my
first pass or two. Does it mean:
'It is possible to detect Sequence Discontinuities with payload byte
numbering, but only when the complete pattern of payload sizes is
stored at the Destination, or when payload size is constant and then,
IN THIS CASE, the byte numbering adds needless complexity over
I might be a good idea to have a recommended value for dT.
The C code would be more useful if it had a license under which it could be
Please clearly distinguish active measurement and passive measurement.
At times, it is unclear which setting was being discussed.
In Section 3, given the recent discussion about "monotonically
increasing" sequence numbers on the IETF list, it would be good to be
clear about what is required here.
In Section 3.5 says:
> It is possible to detect Sequence Discontinuities with payload byte
> numbering, but only when the complete pattern of payload sizes is
> stored at the Destination, or when payload size is constant and then
> the byte numbering adds needless complexity over message numbering.
Does the complete pattern really need to be stored at both sides? If
there is an active stream, one can pseudorandomly generate the sizes
with a shared seed. Please explain further?
Section 4.2.4 says:
> If a receiver intends to restore order, then its buffer capacity
> determines its ability to handle packets that are reordered. For
> cases with single reordered packets, the extent e gives the number
> of packets that must be held in the receiver's buffer while waiting
> for the reordered packet to complete the sequence. For more complex
> scenarios, the extent may be an overestimate of required storage
> (see section 4.4 on Reordering Byte Offset and the Examples
It seems like this does not give a correct buffer size estimate for
protocols like TCP which adaptively retransmit and do not need to
keep all reordered packets. Since this is supposed to be a generic
algorithm, it is probably sufficient to describe the situation.