Dear all,

On 7/5/2004 8:52 PM, Henk Uijterwaal (RIPE NCC) wrote:
 > Michal, Bartosz,
 >
 > The IPPM group wants to finalize the IPPM reordering draft(s) in the near
 > future. As you implemented the metrics, we were wondering if you had any
 > comments on the text of the drafts.  What is clear, what is unclear, what
 > should be added to the text, which metric is best suited for which
 > purpose, etc.  The more comments, the better :-)
 >

Definitely there are some thoughts and comments - I will try to summarise them below 
(probably some of them were already discussed within TF-NGN mailing list, but at least 
I'll try to bring them together.

  We have performed the measurements for 2 different reordering metrics: 
draft-ietf-ippm-reordering-05.txt (IPPM)  and draft-jayasumana-reorder-density-02.txt (RD) 
  each of them measuring reordering differently.

The one most important comment is the approach to the measurement:

1. The draft should suggest not only definition of metrics, but also the way how it is 
measured (there is also a comment about this from editors in the draft).

a) sending (with a maximum link speed) a burst of longest packets followed by a burst of 
shortest packets (both longest and shortest packets had to fit into single 1500 bytes 
frame). Such a measurement gave the reordering extent of 10 and more, for many links where 
reordering might have occured. However this is the worst case, and rather unrealistic, 
since we din't see that pattern in any of analysed application. We consider this kind of 
measurement useful for testing i.e. single network device (such as ethernet switch, 
router) or a complete network.
There may be also variations of this scenario (especially with packet patterns, one may 
use only short packets or long packets only). General idea is to send with the maxiumum 
possible speed./
This kind of test answers the question - "what is the worst reordering I can get from my 
network?"

b) re-sending captured packet stream emulating given application - we think that this is 
best way to see how given application copes with the network, and how impaired network 
influences such application. We can use IPPM metrics to see the necessary buffer size for 
such application. So the question here is "what is the de-reordering buffer length I need 
in my application for this network"

We think that the networks should in general be checked against reordering (method "a"), 
but for given application one shall use method "b" for measuring influence of impaired 
network.

2. The important issue is with the packet loss
You can look at
http://ngn.man.poznan.pl/en/research/reordering/results-html/out.401-CZ-RD.html
and
http://ngn.man.poznan.pl/en/research/reordering/results-html/out.401-CZ-IPPM.html

We have received only 3 packets of the stream:

ID=401 SEQ=684 SRC=193.1.200.241:3001 DST=195.113.147.23:5000
                   Tx=1086343531.959051 Rx=1086343531.557416 SIZE=20

ID=401 SEQ=685 SRC=193.1.200.241:3001 DST=195.113.147.23:5000
                    Tx=1086343531.959241 Rx=1086343531.557444 SIZE=20

ID=401 SEQ=686 SRC=193.1.200.241:3001 DST=195.113.147.23:5000
                    Tx=1086343531.959431 Rx=1086343531.557492 SIZE=20


There is no reordering, but there is packet loss. If one wants to cope with reordering, he 
has to implement buffers. If application gets packet with the SEQ number higher that the 
last one by more than 1 it considers this packet as "early packet" and will store it in 
the buffer untill some time period, when it will notice packet loss. In this scope IPPM 
metric is right and wrong ;-). Right because there is no reordering but packet loss, wrong 
because it says that the buffer size is 0. In fact the receiving application, willing to 
cope with possible reordering (it got the higher SEQ packet than the lower one!) will use 
de-reorder buffers up to a certain time limit. So the buffers are there.

We find here the Reorder Density (defined in draft-jayasumana-reorder-density-02.txt) 
metric very useful as a metric of usage of the buffer. The buffer is always used when 
received packet is not the expected one (received packet is stored in buffer).
Algorytm doesn't differentiate between the lost packets and the late packets.
So this algorithm can be used as an extention for IPPM reordering metrics for scenarios 
with packet loss.

We think that the only accurate metric should be focusing on given application traffic 
pattern and shall also consider packet loss (perhaps combination of IPPM and jayasumana 
drafts)

All the best,

Michal



-- 
______________________________________________________________________
Michal Przybylski        Network Research and Development
michalp@man.poznan.pl    Poznan Supercomputing and Networking Center
+48 61 858 20 27         www.man.poznan.pl
______________________________________________________________________



_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm