Subject: [ippm] Reorder Density Java Applet - ref: metric to measure packet reordering.

From: Nischal M Piratla <[email-masked]>
Date: Tue, 15 Apr 2003 14:40:17 -0600

Hi all,
Here is a link that will take you to a Java Applet for the display of 
Reorder Density metric for any given sequence of numbers.

http://www.engr.colostate.edu/ece/Research/cnrl/Reorder_Density.html

You should be able to enter any sequence of numbers with spaces or commas between the numbers. We have used ptplot in building this applet. We are currently working on the next version of the draft. Please feel free to send your comments on the draft and applet too!
Thanks,
Nischal Piratla
***********************************************
Research Assistant
Computer Networking Research Laboratory
Department of Electrical and Computer Eng.
Colorado State University,
Fort Collins, CO 80523
Voice: +1 970-491-7974
Fax:   +1 970-491-2249
http://www.engr.colostate.edu/ece/Research/cnrl
***********************************************

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

---

From: "Stefan Savage" <[email-masked]>
Date: Fri, 18 Apr 2003 14:35:50 -0700

BTW, I noticed the recently discussion about reordering metrics and I
thought some of you might be interested in some experience John Bellardo and
I had recently trying to measure reordering:

Bellardo & Savage, Measuring Packet Reordering, Internet Measurement
Workshop, November 2002.
http://www-cse.ucsd.edu/~savage/papers/IMW02.pdf

Most of the paper is about how to build a tool using various TCP/IP hacks to
extract measurements from existing systems and isn't relevant to this
discussion.  However, we also reported on some early experiences examining
the distribution of the reordering process as a function of time.  Whats
interesting here is how sensitive reordering is to small time differences
(even the serialization delay relating to differences in packet size).
Given this, to sum up reordering with a single scalar metric (such as
reordering density) seems like it only makes sense if the frequency dynamics
of the test stream and the construction of the metric are specialized to the
behavior of a particular application (e.g. TCP).  It seems very hard to
define a general metric that doesn't devolve to reporting the entire
time-varying distribution.

- Stefan

P.S.  If all of this is widely understood I apologize, I haven't been
following the discussions here.

---

From: Al Morton <[email-masked]>
Date: Fri, 18 Apr 2003 17:57:00 -0400

>I had recently trying to measure reordering:

At the last three meetings, I've made a call to add relevant
references on reordering measurements to the draft.
Thanks!
>...
>behavior of a particular application (e.g. TCP).

We recognize this in the current draft, but need to add more...
It is a property shared with other metrics, e.g., IPDV.

>- Stefan
>
>P.S.  If all of this is widely understood I apologize

not at all, there's more to understand here.
Al

---

From: stanislav shalunov <[email-masked]>
Date: 20 Apr 2003 03:49:17 -0400

Stefan,

Thanks a lot for the pointer.  I think we understand how important
timing is.  Is it, consequently, hopeless -- in your opinion -- to try
to report reordering even for streams where each send time is
specified with precision that far exceeds the serialization delay?  I
understand that trying to reproduce reordering using a different
sender might well prove quite hard.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

Letters in this message are closer than they appear.
_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: "Stefan Savage" <[email-masked]>
Date: Sun, 20 Apr 2003 20:34:10 -0700

I'm not completely sure I parse the question, but let me say this:

I think its tough to measure reordering without talking about the underlying
process you're trying to capture.  To the best of my knowledge, the process
that seems to dominate persistent reordering behavior arises from forwarding
parallelism (either striped L2 or within the switch fabric itself).  Such
reordering is drive by temporary imbalances in parallel queues -- as a
result it only manifests within a flow over relatively short intervals (no
one notices reordering between flows).  If this is the case then
observations of reordering are _highly_ dependent on the spacing between
probes (to wit, back-to-back small packets see more much more re-ordering
than large packets spaced 30ms apart).   The end result is that Web
transfers will see much less reordering than flooded pings over the same
path simply because differences in serialization delay smooth out the
"noise" in the link load balancing algorithm.  So what number makes sense to
report?  Well it depends on what the application _does_.  Its not possible,
to the best of my knowledge, to take one such measurement and successfully
extrapolate to a different time scale.

Moreover, there are a number of other processes that produce re-ordering on
slightly longer time scales.  Diffserv scheduling is one (you can go out of
spec within a flow leading to a reordering process that is driven by a
combination of load and the token bucket parameters for traffic class under
test) and another is transient routing loops (these can cause very large
reordering events).

Given all this, I think reordering is a tough metric to measure in
isolation.  I think the two most reasonable approaches are to measure it
across a range of time scales (i.e. produce the entire distribution) or
specialize it to the time-scale of the most compelling applications (i.e.
what is the probability of a reordering even spanning the xmit time of four
SMSS-sized frames, thereby causing a false fast-retransmit in TCP).

- Stefan

-----Original Message-----
From: stanislav shalunov [mailto:[email-masked]] 
Sent: Sunday, April 20, 2003 12:49 AM
To: Stefan Savage
Cc: [email-masked]
Subject: Re: [ippm] Reordering

Stefan,

---

From: "John Evans" <[email-masked]>
Date: Tue, 22 Apr 2003 09:19:18 +0100

> slightly longer time scales.  Diffserv scheduling is one

>From RFC2597: "A DS node does not reorder IP packets of the same microflow
if they belong to the same AF class".  Changing the AF class (rather than
drop precedence) within a uflow would be indicative of a poor Diffserv
design or implementation.

cheers

John

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Stefan Savage
> Sent: 21 April 2003 04:34
> To: 'stanislav shalunov'
> Cc: [email-masked]
> Subject: RE: [ippm] Reordering
>
>