Subject: [ippm] Comment on threshold on buffer sizes

From: Nischal M Piratla <[email-masked]>
Date: Tue, 8 Mar 2005 11:45:56 -0700

Yesterday, we discussed about the threshold on buffer sizes briniging the 
spatial complexity of the same for RD and RBD to a constant. I guess, the time 
of the day didn't help many to get it right. I am answering the query about 
test equipment query.

Q: What do you mean the buffer requirement is constant when we at backbone 
have thousands of packets arriving in a second? We store these packets and 
compute reorder measures.

Ans: The spatial complexities of a metric corresponds to the resource 
requirement to perform the computation. If a test equipment is receiving 
thousands of packets in a second, then storing them to compute any measure 
(let it be reordering or loss) has no relation to the metric that will be 
used.

So, if we are to determine the reordering using RD or RBD we can use a buffer 
of a constant size (DT or BT respectively). But with ippm metrics (as 
explained in previous email on spatial complexities), the spatial complexity 
is O(N).

- 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/7794
Fax:   970-491-2249
http://www.cnrl.colostate.edu
http://lamar.colostate.edu/~nischal
****************************************************

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

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 09 Mar 2005 02:44:00 +0100

>(let it be reordering or loss) has no relation to the metric that will be

OK, I ageee.

>explained in previous email on spatial complexities), the spatial complexity

Now wait: if I want to apply a metric offline, I will have to store N packets
(or at least N sequence numbers) for ANY algorithm, requiring a buffer of
O(N).

Henk

>- Nischal

------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Look here junior, don't you be so happy.
And for Heaven's sake, don't you be so sad.                 (Tom Verlaine)

---

From: Al Morton <[email-masked]>
Date: Thu, 10 Mar 2005 11:27:41 -0500

At 01:45 PM 03/08/2005, Nischal M Piratla wrote:
>...

The ippm metrics require a comprehensive detection of duplicate packets.
There are ways to reduce the complexity described in the ippm
reordering draft. The final complexity depends on implementation.

RD and RDB would not detect duplicate packets if they arrive with
separation greater than DT or BT, the buffer sizes.  DT and BT also
set the threshold for declaring loss (in terms of packets). Clearly
the choices of DT and BT have a profound influence on the results,
and they must be set prior to the measurement.

Making DT and BT "large enough" is not always possible, as the application
of interest may require small thresholds for accurate assessment.
So, duplicates could be defined as reordered, depending on the distance
between the first packet and its duplicate.

I don't see a way to compare results measured with different values of
DT and BT (perhaps there is a way, but ?).  If not, then one of the
reasons to standardize these metrics (measurement comparison) is lost,
because:

* testers will choose different thresholds, each having their own
   good justification,

* the choice of DT and BT influence the definitions of several metrics
   simultaneously (none of packet reordering, loss, or duplication
   metrics would be comparable), and

* we should not standardize single DT and BT values (flexibility is
   required and we likely cannot agree on a single value, anyway).

So, the DT and BT thresholds may be a strength when considering
complexity, but they must be tuned a priori for the application/path
of interest and that's a serious weakness when measurement comparison
and efficiency are considered.

It seems as though RD and RBD are better suited for post-processing
stored measurements, where DT and BT can be changed at will.
A possible way forward might be to differentiate RD and RBD from
the "on-the-fly" ippm metrics on that basis, if there is agreement
that RD and RDB offer something worth standardizing.

Al

---

From: "Nischal M. Piratla" <[email-masked]>
Date: Mon, 21 Mar 2005 14:47:18 -0700

>> and they must be set prior to the measurement.
The duplicates that arrive beyond DT or BT are discarded packets. So, it 
is not true that RD and RBD would not detect duplicate packets that 
arrive beyond the separation of DT or BT.

>> between the first packet and its duplicate.
Assuming you are correct, i.e., an application of interest requires 
small threshold for accurate evaluation, how would a metric that does 
not use a threshold at all be able to meet its needs? Only RD and RBD 
will work here as other metrics do not have such a feature, and a late 
arrival that is treated as reordered by reorder-extent, n-reordering 
etc. will lead to more problems.

Further, in RD and RBD duplicates are *never* defined as reordered.

Voice: 970-491-7067/7974