Packet Reordering Metrics
Note: This ballot was opened for revision 12 and is now closed.
( Lars Eggert ) Yes
Jari Arkko No Objection
Comment (2006-04-27 for -)
> Metrics defined in this memo SHOULD be registered in the IANA IPPM > METRICS REGISTRY as described in initial version of the registry > [RFC4148]. I think it would be better to say "IANA is asked to register..." instead of using SHOULD.
( Ross Callon ) No Objection
( Brian Carpenter ) No Objection
Comment (2006-04-24 for -)
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 message numbering'
( Lisa Dusseault ) No Objection
( Bill Fenner ) No Objection
( Ted Hardie ) No Objection
( Sam Hartman ) No Objection
( Russ Housley ) (was Discuss) No Objection
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 > section). > 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.
( Cullen Jennings ) No Objection
Comment (2006-04-27 for -)
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 used.