Subject: [ippm] Packet Reordering Metric question

From: Ulisses <[email-masked]>
Date: Mon, 20 Jun 2005 11:54:02 +0200

Hello all

I have read http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-09.txt

reading the examples of packet reordering, I'm curious about real-world
examples of packet reordering when fifo queues are in use and no packet
classification is in use.

I have seen that some versions of Juniper do reordering, at least
with some versions of the firmware/JunOS when using multiple processors.

Currently I'm doing tests and I see reordering (and no loss) in the firsts 
packets in trains of packets. I would like to diagnose the symptom.

comments/suggestions/references?

Thanks in advance

	Ulisses

                Debian GNU/Linux: a dream come true
-----------------------------------------------------------------------------
"Computers are useless. They can only give answers."            Pablo Picasso

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

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

---

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 20 Jun 2005 17:55:47 +0200

Hi,

>I have read 
>http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-09.txt
>

I'm not quite sure what you want to do.   You have a sample (train of
packets) with reordering with some packets out of order w.r.t. the
original sequence.  The metric(s) described in the draft try to quantify
the extend of the reordering.

It is hard to intuitively quantify the extend of the reordering, but you
can imagine that a sequence of 100 packets (1,2,3...100) that arrives as
(2,1,3,4,5... 100) is considered less reordered than when it arrives as
(100,99,98, .... 1).

So, what you can do, is send trains of packets under various conditions,
look at the arrival sequence, apply the metrics and compare their
scores.  The less reordering, the closer the result will be to 0
(or whatever the metric gives for an arrival sequence identical
to the sending sequence).

You can also try to relate reordering scores to other performance
effects that you might see across your router.  If you do, then
I'd be very interested to hear about them.

If you want to know what causes the reordering, you will have to
look at the router hardware.  The draft does not say anything about
this.

Henk

------------------------------------------------------------------------------
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: Henk Uijterwaal <[email-masked]>
Date: Mon, 20 Jun 2005 19:00:08 +0200

IPPM Group,

The IPPM group will meet in Paris in August.  So far we have these
agenda topics:

  1. Reordering draft
  2. Bandwidth draft
  3. New work items
      - TWAMP
      - Traceroutes
      - Composition of metrics
      - Multimetrics
  4. Implementation document.

If you want to say something about these topics, please tell us how
much time you need.  If you have any other topics for the agenda, just
let us know.

Henk will be completely offline between July 7 and 24.  If you want a
reply during that time, please make sure that both Matt and I are on
the receipient list.

Matt & Henk.

---

From: Ulisses <[email-masked]>
Date: Tue, 21 Jun 2005 12:10:16 +0200

Hi Michal

On Mon, Jun 20, 2005 at 04:04:26PM +0200, Michal Przybylski wrote:
> We have done something in this area,
> 
> Please have a look at:
> 
> http://ngn.man.poznan.pl/en/research/reordering/
> 
> and
> 
> http://www.terena.nl/conferences/tnc2005/core/getfile.php?file_id=495

Thanks a lot for the links

Taking into account that

- route changes/flapping is not usual behaviour
- QoS is not widely used because I believe over-provisioning is preferred

I suposse that link-aggregation and router implementation is the cause
of most reordering.

isn't it?

regards

	Ulisses

> All the best,
> Michal
> Ulisses napisa??(a):
> -- 
> ______________________________________________________________________
> Michal Przybylski         Network Research and Development
> [email-masked]     Poznan Supercomputing and Networking Center
> +48 61 858 20 27          http://www.man.poznan.pl
> ______________________________________________________________________

--

---

From: Michal Przybylski <[email-masked]>
Date: Tue, 21 Jun 2005 12:45:50 +0200

Ulisses,

> I suposse that link-aggregation and router implementation is the cause

In our case yes - if you are from Spain, then you shall experience much 
reordering from GEANT, caused by the M160 routers. However, GEANT is 
also using Premium IP (EF) class to prioritize traffic and LBE (less 
than best effort) traffic for e.g. disk backup traffic. Look for results 
of LBE testing from Titziana Ferrari, and you will find some interesting 
considersations of the influence on packet reordering by different QoS 
schemes and weights applied.

Also please speak to Miguel Angel Sotos or Esther Robles from RedIRIS, 
who can help you wrt the situation in Spanish network.

All the best,

Michal

---

From: Ulisses <[email-masked]>
Date: Tue, 21 Jun 2005 13:24:53 +0200

Hello (again) Henk

On Mon, Jun 20, 2005 at 05:55:47PM +0200, Henk Uijterwaal wrote:
> Hi,
> 
> >I have read 
> >http://www.ietf.org/internet-drafts/
> >

I already have implemented the metrics of draft-ietf-ippm-reordering-09.txt and
tested within the Geant network. I found some extrange reordering, the problem
is that I don't know if exists a way to infer where the reordering occurs other
than doing mesh meassurements (all to all) and compare them with a graph 
taken from traceroute and infer the routers where it is happening.

> I'd be very interested to hear about them.

Which related performance effects are you thinking about? I would greatly
appreciate any suggestion

> look at the router hardware.  

yes, that's _the_ problem.

Thanks in advance

	Ulisses

---

From: Al Morton <[email-masked]>
Date: Tue, 21 Jun 2005 08:57:26 -0400

>taken from traceroute and infer the routers where it is happening.

I assume this is steady-state reordering, as described in the draft.
Perhaps you can narrow-down your search by dividing the network into
sections, or has reordering appeared in all your measurements so far?

Also, we should probably exclude specific manufacturer/model names
from on-list discussions, IMO.

Al

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 21 Jun 2005 11:00:32 -0700

Hi -

> From: "Al Morton" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, June 21, 2005 5:57 AM
> Subject: Re: [ippm] Packet Reordering Metric question
...
> from on-list discussions, IMO.
...

As long as it's not advertising, why?  Without a vendor / model, claims
that some behaviour occurs in the wild are difficult to evaluate, and could
achieve a kind of folklore status, persisting long after the interesting
boxes have been unplugged.

Randy

---

From: Ulisses <[email-masked]>
Date: Tue, 21 Jun 2005 20:17:57 +0200

Hello Al

On Tue, Jun 21, 2005 at 08:57:26AM -0400, Al Morton wrote:
[...]
> I assume this is steady-state reordering, as described in the draft.

Yes, it happens under normal operation of the network.

> sections, or has reordering appeared in all your measurements so far?

looking again at the results, It happend to be the same reordering issue 
I found some time ago...

> from on-list discussions, IMO.

I understand that in general we must avoid it, and also that we don't 
do wrong if we mention them in well known issues.

Thanks for your comments

	Ulisses

---

From: Al Morton <[email-masked]>
Date: Tue, 21 Jun 2005 21:57:53 -0400

At 02:00 PM 06/21/2005, Randy Presuhn wrote:
>As long as it's not advertising, why?  Without a vendor / model,

Publicity comes in two categories, positive and negative.
This is the latter, and to be constructive even more details
are needed, such as the OS version, interface card types, etc.
We haven't even learned details about the packet stream used
in the measurements, but we already have a vendor to beat-up?

And I agree with you, that without all these details...
>claims

I said this is my opinion.  I typically expunge vendor names/models
from standards contributions, emphasizing the impairment observed and the
effect on the development instead.  I wouldn't want to drag someone's name
through the mud and find-out later that it wasn't their fault.
The retraction never seems to flow as far, or as fast.

Al

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 22 Jun 2005 15:17:54 +0200

Hi,

>appreciate any suggestion

Reordering usually means that the receiving device has to put the packets
back into order.  This requires it to run some sort of sort algorithm
(which takes time) and store the packets while waiting for the ones that
are late. If a packet is completely out of order, it will ask for a re-send.
All this will affect things like throughput, used capacity, etc.  It'd be
interesting to see if there is a relation between the result for reordering
and quantities like throughput.

Henk

---

From: Lei Liang <[email-masked]>
Date: Wed, 22 Jun 2005 15:01:02 +0100

> and quantities like throughput.
It will be quite dependant on various network situation. I.e., the
packet length, the throughput without reordering, transport protocols
used and the sort algorithm used will all have impact on the
relationship. That means the test to find out the relationship between
reordering and quantities might have to consider all of these factors.

cheers,
Lei