Subject: [ippm] Query about Reordering Byte Offset

From: "Nischal M. Piratla" <[email-masked]>
Date: Sun, 19 Jun 2005 22:45:05 -0600

Al,
I am running some simulations to come up with an unbiased outlook for 
all the metrics out there. Truly, I intend to observe what we can 
achieve with each metric, and not which one is better than the other.
I have a doubt w.r.t Reorder Byte Offset, can you please respond to this 
query.

During 62nd meeting, responding to my question and Mark's follow up 
remark, you said that the overestimate of buffer-size using Reorder 
Extent is possible, even in terms of packets.
Is this also applicable to Reorder Byte Offset (talking in terms of bytes)?
In other terms, can the Byte Offset metric fail (for certain cases) in 
prediction w.r.t whether reordered packets will be useful in general 
receiver buffer system with finite limits (sec. 4.4.4)?

In addition, I am also trying to store the missing packets in a very 
large buffer to remove duplicates for IPPM metrics. I was wondering 
whether you have any other suggestions/scripts that can help me to 
control this buffer size, especially with huge bursts of losses? 

Thanks in advance for your responses.
Regards,
Nischal

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

---

From: Al Morton <[email-masked]>
Date: Mon, 20 Jun 2005 23:47:44 -0400

At 12:45 AM 06/20/2005, Nischal M. Piratla wrote:
>Al,
>I am running some simulations to come up with an unbiased outlook for all 
>the metrics out there. Truly, I intend to observe what we can achieve with 
>each metric, and not which one is better than the other.

How will you avoid bias in the type of simulations you select and run?

>remark, you said that the overestimate of buffer-size using Reorder Extent 
>is possible, even in terms of packets.

The draft says that Reordering Extent is a metric
giving the distance (in units of arrival positions)
between a reordered packet and the associated sequence discontinuity.
There is also a comment that this simple distance may over-estimate the
storage needed to restore some arrival orders, but more complexity
may not be desirable.

>receiver buffer system with finite limits (sec. 4.4.4)?

When you read the draft, you'll find that Reordering Byte Offset
only sums packet payloads that are qualified by two criteria,
and the metric will be successful as far as those criteria
are a sufficient description of receiver buffer operation.

>In addition, I am also trying to store the missing packets in a very large 
>buffer to remove duplicates for IPPM metrics. I was wondering whether you 
>have any other suggestions/scripts that can help me to control this buffer 
>size, especially with huge bursts of losses?

One way is to restrict the size of each sample by collecting
measurement results every 5 minutes + waiting time.
Measurements on paths exhibiting some "huge bursts" would have
only a portion of samples affected, but keep in mind that your scenario
is a corner case. The first-order impairment seems to be connectivity.
There's not much value in talking about spots on the leaves
after someone has clear-cut the forest.

Al

---

From: "Nischal M. Piratla" <[email-masked]>
Date: Mon, 20 Jun 2005 23:24:48 -0600

Al,

> How will you avoid bias in the type of simulations you select and run?

Simulations analyze reordering based on load-splitting models with 
various probabilities and loss rates (burst losses) on multiple paths. 
So, I do not see anything going against ippm metrics or RD or RBD for 
that matter.

Thank you for the non real-time measurement approach of 5 minute + wait. 
It really helps. (Also, I am considering all the scenarios not just the 
corner ones)

Thank you,
Nischal

---

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

At 01:24 AM 06/21/2005, Nischal M. Piratla wrote:
>It really helps.

I suggested a way to organize the samples;
it has nothing to do with "non real-time" implementation.
The waiting time is the value "Th" in the Loss RFC.

Al