Subject: [ippm] I-D ACTION:draft-shalunov-reordering-definition-00.txt

From: [email-masked]
Date: Thu, 20 Dec 2001 11:10:07 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Definition of IP Packet Reordering Metric
	Author(s)	: S. Shalunov
	Filename	: draft-shalunov-reordering-definition-00.txt
	Pages		: 4
	Date		: 17-Dec-01
	
Various pieces of network testing equipment currently often report a
characteristic that is referred to as a 'degree (or percentage) of
packet reordering'.  The way this metric is computed is often
undocumented and it differs between vendors.  Having a useful numeric
measure of the degree of packet reordering is important for
applications such as TCP and VoIP on different ends of the spectrum.
However, the metric that makes sense for one application may have no
or little applicability to another.  This document introduces a
definition of reordering metric that is hoped to be applicable to a
number of different applications by parametrizing the metric.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shalunov-reordering-definition-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-shalunov-reordering-definition-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-shalunov-reordering-definition-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Fri, 21 Dec 2001 13:54:02 +0100 (CET)

Stas, others,

> number of different applications by parametrizing the metric.

A couple of questions

* How does this metric differ from the one presented by Dale in London?
  And if they are different, what are the pros and cons of this metric
  over Dale's.  And, yes, I realize that this might be a non-trivial
  question but if we define two metrics for the same phenomena, then
  we should have an idea which one should be use when.

* How does this metric deal with losses?
  If 4 out of 5 packets are received, with a packet in the middle lost,
  is this considered no reordering or equivalent to <1,2,4,5,3>?  The
  same goes for time-outs (a packet arrive _after_ the destination
  asking for a retransmit).

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                    Email: [email-masked]
RIPE Network Coordination Centre     WWW: http://www.ripe.net/home/henk
Singel 258                         Phone: +31.20.5354414
1016 AB Amsterdam                    Fax: +31.20.5354445
The Netherlands                   Mobile: +31.6.55861746
------------------------------------------------------------------------------

As long as you don't tell your friends how I played the hand,
then I won't tell my friends how you defended it.                 (Anonymous)

_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: stanislav shalunov <[email-masked]>
Date: 21 Dec 2001 08:39:08 -0500

> * How does this metric differ from the one presented by Dale in London?

This metric is parametrized.  Dale's not.  See section 6 of my draft,
which argues why parametrization is a good thing.  (Different
applications are different and this metric covers a large subset of
the application space.)

This metric is thought to be directly applicable to applications
(e.g., TCP with a fixed dupack threshold, or an interactive video
application with a buffer of some fixed number of packets).

> * How does this metric deal with losses?

Losses aren't counted as any sort of reordering.  So, an application
with a buffer for reordering repair of N buffers will have lost
loss+N-reordering packets.

>   asking for a retransmit).

I don't understand the retransmit question.  This metric maps from the
cartesian product of finite sequences of sequence numbers and
non-negative integers into real numbers.

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

This message is designed to be viewed at 600 mph.
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Fri, 21 Dec 2001 15:04:51 +0100 (CET)

> application with a buffer of some fixed number of packets).

If we continue with 2 metrics (or drafts), I think it should be stated
somewhere which one covers what (cross-reference plus a bit of text).

> loss+N-reordering packets.

In other words, <1,2,4,5> has no reordering?

> non-negative integers into real numbers.

Yes, that is exactly my problem.

Suppose I have an application that needs ALL the packets.

Case #1: It receives packet 4, 5 and 3, in that order, with minimal delay
between 5 and 3.  My application can now put them in order and wait for
packet 6.

Case #2: It receives packets 4 and 5, followed by nothing.  After a while,
my application will (presumably) time-out and ask for packet to be resend.
Now 3 arrives.

In both cases, the reordering metric sees this as <1,2,4,5,3> and gives
the same result.  However, the performance of the setup in case 1 will be
different from case 2.

We can accept this, but then we have to give a second number to express
the difference between the 2 cases, or we can modify the metric.

Henk

---

From: stanislav shalunov <[email-masked]>
Date: 21 Dec 2001 09:15:03 -0500

> In other words, <1,2,4,5> has no reordering?

That's correct, it has no N-reordering for any value of N.

> Case #1: It receives packet 4, 5 and 3, in that order, with minimal
> delay between 5 and 3.  My application can now put them in order and
> wait for packet 6.

If it has a reordering repair buffer of at least 1 packet...

> my application will (presumably) time-out and ask for packet to be resend.

If you were to measure the network with synthetic traffic (and not ask
for retransmits), this would show up as loss, not as reordering.  In
fact, the network reordered nothing in this case, but simply lost a
single packet.

However, you raise a valid point:  Not only the number of packets by
which a packet is delayed matters, but, for some applications, other
things matter as well.  I'm thinking about other metrics that would
cover that.

> In both cases, the reordering metric sees this as <1,2,4,5,3> and
> gives the same result.

No, packets are numbered *as they are sent*.  For the purposes of
N-reordering, in the second case, what I see is <1, 2, 4, 5, 6> (3 is
lost, no N-reordering for any value of N).

This message is designed to be viewed at 600 dpi.
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm