Subject: [ippm] Question 2 - draft-ietf-ippm-reordering-07.txt

From: Nischal Piratla <[email-masked]>
Date: Sun, 17 Oct 2004 20:41:45 -0600

>From the draft-ietf-ippm-reordering-07.txt document, here is a piece of text

" 4.2.1 Metric Name:

   Type-P-packet-Reordering-Extent-Stream

   4.2.2 Parameter Notation:

   Given a stream of packets sent from a source to a destination, let K
   be the total number of packets in that stream.

   Assign each packet a sequence number, a consecutive integer from 1
   to K in the order of packet transmission (at the source).

   Let L be the total number of packets received out of the K packets
   sent. Recall that identical copies (duplicates) have been removed,
   so L<=K.

   Let s[1], s[2], ..., s[L], represent the original sequence numbers
   associated with the packets in order of arrival.

   Consider a reordered packet (as identified in section 3) with
   arrival index i and source sequence number s[i]. There exists a set
   of indexes j (1<=j<i) such that s[j] > s[i]. "

The metric needs to make sure that there are no duplicates and also there is no in-built mechanism to avoid duplicates.
Correct me if I am wrong, but does that mean this metric requires buffering of all the packets til the end of the stream?

I look forward to your comments.

- Nischal Piratla

******************************************************
Research Assistant
Computer Networking Research Laboratory (CNRL)
Department of Electrical and Computer Eng.
Colorado State University,
Fort Collins, CO 80523
Voice: +1 970-491-7974
Fax:   +1 970-491-2249
CNRL: http://www.engr.colostate.edu/ece/Research/cnrl
Home: http://lamar.colostate.edu/~nischal
******************************************************

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

---

From: Al Morton <[email-masked]>
Date: Mon, 18 Oct 2004 00:13:50 -0400

At 10:41 PM 10/17/2004, Nischal Piratla wrote:
>The metric needs to make sure that there are no duplicates and also there 
>is no in-built mechanism to avoid duplicates.
>Correct me if I am wrong, but does that mean this metric requires 
>buffering of all the packets til the end of the stream?

The draft discusses this question, since it came up many
times before:

 From section 3.6
    ...
    If duplicate packets (multiple non-corrupt copies) arrive at the
    destination, they MUST be noted and only the first to arrive is
    considered for further analysis (copies would be declared reordered
    according to the definition above). This requirement has the same
    storage implications as earlier IPPM metrics, and follows the
    precedent of RFC 2679. We provide a suggestion to minimize storage
    size needed in the section on Measurement and Implementation Issues.

 From section 6. Measurement and Implementation Issues

    ...
    The requirement to ignore duplicate packets also mandates storage.
    Here, tracking the sequence numbers of missing packets may minimize
    storage size. Missing packets may eventually be declared lost, or
    reordered if they arrive. The missing packet list and the largest
    sequence number received thus far (NextExp - 1) are sufficient
    information to determine if a packet is a duplicate (assuming a
    manageable storage size for packets that are missing due to loss).
    ...

Al