Re: [ippm] The next steps for the reordering drafts.

["Nischal M. Piratla" <[e-mail]>]

>  We would like to hear arguments, pro and con, if the working group 
> feels that either the RD or the RBD metric (or both, of course) from 
> draft-jayasumana-reorder-density should become a working group item.

> The Reorder Buffer Density (RBD) metric retains the foundation of a 
> general buffer occupancy calculation. This was the original form of 
> reordering density in earlier versions of this draft, including the 
> fact that it records buffer occupancy with loss alone (no reordering 
> needed to grow the buffer, and the normalization for lost packets 
> doesn't reduce the occupation to zero). See section 7, example b. for 
> a scenario with loss, no reordering.

To recall, example b from section 7:

"Consider a sequence of 6 packets (1, 2, 4, 5, 6, 7) with DT = BT = 3." 

In this sequence, a measurement needs to buffer packets until the loss 
threshold is reached or sequence has ended. Only at this point the 
packet can be treated as lost. So, the occupancy of buffer is 
intentional to emulate buffering at the receiver and make it useful to 
the application. For reference, please read the message:
http://www1.ietf.org/mail-archive/web/ippm/current/msg00316.html

> draft-ippm-reordering-09 deals with buffer size more effectively, in 
> that it only produces values when reordered packets arrive,
> in the dimension of bytes.  See the Section on Byte Offset. This 
> behavior doesn't seem to fit a reordering metric. 

As you mentioned, we use the term RBD from -02 draft onwards  as it is more descriptive. However, the basic concept appeared in our original paper and draft (Nov. LCN 2002, and Feb. 2003 RD draft). We observe the change in definition of the ByteOffset metric in ippm draft02 (Mar. 2003) and subsequent drafts, which try to account for the buffer size requirement as in RBD. Prior ippm drafts defined ByteOffset metric that 
included inorder packets in buffer requirements. Previous definition of ByteOffset metric (see the >>>>comment section):

*****************
4.3.2 Metric Name: Type-P-packet-Byte-Offset-Poisson/Periodic-Stream

   Metric Parameters: We use the same parameters defined above.

   Definition: Byte stream offset is the sum of the payload sizes of
   all intervening packets between the reordered packet and the
   discontinuity (including the packet at the discontinuity).

   For reordered packet i
   ByteOffset(i) = Sum[in-order packets to start of the reordering
   event]
                 = Sum[PayloadSize(packet at i-1),
                        PayloadSize(packet at i-2), ...
                        PayloadSize(packet at i-n)]

   Alternatively, if all payload sizes are equal:
   ByteOffset(i) = n * PayloadSize  where n is the reordering extent.
   >>>>Comment: Previous comments on the accuracy of extent n apply
   here as well.

4.3.3 Discussion

   The Offset metrics can predict whether reordered packets will be
   useful in a general receiver buffer system with finite limits.  The
   limit may be the number of bytes or packets the buffer can store, or

Morton, et al.      Standards Track exp. Sept 2003              Page 9
Packet Reordering Metric for IPPM                             Mar 2003 

   the time of storage prior to a cyclic play-out instant (as with de-
   jitter buffers).
**********************************

Moreover, there is an issue with the definition of ByteOffset metric itself. For example, consider the sequence (1, 6, 7, 8, 9, 10, 11, 12, 2). Before the arrival of packet with sequence number 2, the buffer size requirement is zero and then it suddenly changes to 7. Thus, there is no use to the application of such a measurement. Obviously, one has to  keep track of these early arrivals to assign 7 as buffer requirement for the last arrival. It means that we do not call this tracking buffer as reorder buffer-occupancy, but still perform the same operation, as in RBD. Moreover, this size could go as big as 'N' due to the absence of threshold. Unless there is a better method stated, this increases the computation complexity of ByteOffset further.

In turn, RBD has more usefulness associated with it, and also emulates dereordering without exceptions. At one point of time, ippm was very concerned about buffer requirements. For example: 

> *********************************************************************
> List-Archive: <http://mailhost.advanced.org/archives/ippm/>
> Date: Mon, 17 Feb 2003 11:57:03 +0100 (CET)
>
> Nischal,
>
>> We have come up with a new metric to measure packet reordering. We have
>> posted a ID and here is the link:
>>
>> http://www.ietf.org/internet-drafts/draft-jayasumana-reorder-density-00.txt 
>>
>>
>> This draft may interest you all. Please feel free to send any
>> comments/suggestions.
>
>
> 1. If I understand the algorithm correctly, then it needs an array
>   in_buffer[N] with N the number of packets in a stream. This is not
>   very practical, when I make a VoIP phonecall, then I never know how
>   long it is going to last in advance and thus how I should dimension
>   this array.
>
> 2. Can you include the same examples as in the other reordering etrics
>   so one can compare the algorithms?
>
> Henk

*********************************************************************************

Threshold value encounters such huge buffer requirements. However, 
we do not seem to be discussing about these requirements anymore! 
Unless, we have missed something, these requirements are very vital for 
real-time measurements.

- Nischal
****************************************************
Research Assistant
Computer Networking Research Laboratory (CNRL)
C203,Dept. of Electrical & Computer Eng.
Colorado State University,
Fort Collins, CO 80523
Voice: 970-491-7067/7974
Fax:   [phone]
http://www.cnrl.colostate.edu
http://lamar.colostate.edu/~nischal
****************************************************



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