Packet Reordering Metrics
draft-ietf-ippm-reordering-13

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'

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.

> 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.

  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.