Subject: [ippm] Comments on Reordering Def. in draft-ietf-ippm-reporting-04.txt

From: Al Morton <[email-masked]>
Date: Mon, 28 Jun 2010 15:30:18 -0400

IPPM,

At the last IPPM meeting, Matt Z. alerted us to a possible problem
with the reordering metric definition in section 4.5 of
http://tools.ietf.org/html/draft-ietf-ippm-reporting-04#section-4.5

>4.5.  Reordering
>
>    Reordering is the fraction of packets sent but not lost for which the
>    sequence number of the packet received immediately before the first
>    copy of the given packet is not the decrement of the sequence number
>    of the given packet.  For the purposes of determining the sequence
>    number of the preceding packet in this definition, assuming sequence
>    numbers starting with 1, an extra packet at the start of the stream
>    of received packets, with a sequence number of 0, is considered to be
>    present (this extra packet, of course, is not counted for the
>    purposes of computing the fraction).
>
>    For more information, refer to section 4.1.3 (Type-P-Reordered-Ratio-
>    Stream) of RFC 4737 [RFC4737] (Packet Reordering Metrics), and
>    supporting text.
>
>    {Comment: As the non-normative sample code in Appendix A below shows,
>    this is also related to the amount of 1-reordering (Section 5.3 RFC
>    4737 [RFC4737]).  It is not, however, the degree of 1-reordering in
>    5.3; because that divides by the number of all packets received,
>    instead of the number of non-duplicate packets received.}

We reached consensus long ago that this reporting draft would not
define any new metrics, it would simply re-use the existing metrics
in a "short term" (10 second) repeated reporting scenario.

Specifically, the definition above is a fairly strict enforcement of
original sequence numbering, such that all packets not following
the sequence reference (the previous packet) are declared reordered.

Also, the definition above does not account for lost packets
in it's brief specification of sequence number processing, while the
Reordered packet definition in RFC 4737 easily avoids the problem
and maintains orthogonality with the packet loss metric. In other words,
prior packet loss alone cannot cause an arriving packet to be declared
reordered. The RFC 4737 metric enforces a non-reversing order, and
only packets that arrive "late" are declared reordered.

Example:  Sequence numbers arrive in the following order:

               1   2   3   4   7   5   6   8
Designation
by Def above: -   -   -   -   R   R   -   R

Designation
by RFC 4737:  -   -   -   -   -   R   R   -

Example:  Sequence numbers arrive in the following order (with #6 Lost):

               1   2   3   4   7   5   8
Designation
by Def above: -   -   -   -   R   R   R

Designation
by RFC 4737:  -   -   -   -   -   R   -

I suggest, for replacement text (since the current text is
not easily fixable for consistency with RFC 4737):

4.5.   Reordering

The definition of a reordered packet may be found in section 3 of RFC 4737.

Reordering is expressed as the ratio "Type-P-Reordered-Ratio-Stream"
as defined in section 4.1 of RFC 4737.

Al