Re: [ippm] draft-jayasumana-reorder-density-03.txt

[Al Morton <[e-mail]>]

At 06:27 PM 07/22/2004, Anura Jayasumana wrote:

We have posted a revised version of our draft on metrics to measure packet reordering: http://www.ietf.org/internet-drafts/draft-jayasumana-reorder-density-03.txt" rel="nofollow">http://www.ietf.org/internet-drafts/draft-jayasumana-reorder-density-03.txt

Hi Anura,

Thanks for the pointer to your latest draft. 
This new version of Reordering Density continues to use
a unique definition for reordered or "late" packets, and
a definition of packet loss that deviates from RFC 2680,
if I understand it correctly.

Since your method requires that lost packets be identified
before reordering evaluation, let's look at your definition
of loss in section 5.  "...a packet is not considered lost until
it is late beyond DT, ..." where DT is the Displacement Threshold
in units of packets.  So, at least DT packets must arrive
following a lost packet to classify it correctly. But what if
I send 100 packets, and the last 50 never arrive?  RFC 2680 would
designate the last 50 packets as lost after a time-out, and
does not require successful arrivals after a loss to do so.
This definition has roots in the fact that all packets have a
useful lifetime in the context of their protocol or application.
(The sensitivity of the results to choice of DT is another
issue, but let's set that aside for now.)

Here's a new example to illustrate the difference between
the reordering definitions (with no loss or duplication):

   Arrived sequence:    1   2   3   7    5    6   4   8
   Receive_index:       1   2   3   4    5    6   7   8
   Displacement:        0   0   0  -3    0    0   3   0

In this example, your definitions designate packet 7 as early,
and packet 4 as late, and we're in agreement this far. But
ippm-reordering's non-reversing sequence criterion designates
packets 5 and 6 as reordered (they are clearly late, arriving behind 7).
Your metric appears to enforce the original sequence in this example
(elsewhere, it corrects the original sequence for lost packets).

The example also raises an issue for your definition of
Buffer Occupancy (B) in section 2.9.
   "An arrived packet with a sequence number greater than that of
   expected packet is considered to be stored in a hypothetical buffer
   long enough to recover from reordering. At any packet arrival, the
   buffer occupancy is equal to the number of such out-of-order packets
   in the buffer including the arrived packet (assuming one buffer for
   each packet)."

Using the same example arrival sequence:

   Arrived sequence:    1   2   3   7    5    6   4   8
   Receive_index:       1   2   3   4    5    6   7   8
   Buffer Occupancy:    0   0   0   1    1    1   0   0
but a real buffer would hold:
   Real Buffer:         0   0   0   1    2    3   0   0

I tried this example on your web site, and obtained the
"real buffer" result for RBD, so it appears that your algorithm
differs from your text definition.
The Displacement result above was also confirmed.

A few of us who read the -02 version of your draft, the
one that tracked buffer occupation for loss and reordering
combined, thought it might be useful as a general "derived
metric". (see ippm-list discussion a few weeks ago)
Perhaps we can discuss this further in San Diego.

regards,
Al

_______________________________________________
ippm mailing list
[e-mail] 
https://www1.ietf.org/mailman/listinfo/ippm