Subject: Re: [ippm] Question 3 - draft-ietf-ippm-reordering-07.txt

From: "Nischal M. Piratla" <[email-masked]>
Date: Mon, 18 Oct 2004 12:34:21 -0600

Al Morton wrote:

>
> This draft is in "Last Call", intended for WG members who have been
> actively involved in the development to take one last look
> before the draft moves on to the next stage of the process.
> Since you appear to be reading the draft for the first time,
> it might be more appropriate to ask questions off-list with me,
> and let the Last Call continue.  We can go back on the list
> if necessary.
>
> thanks for your questions and understanding,
> Al

Al,
I assumed that if there are some discrepancies, the ippm members who 
have not authored the draft can comment too. I did not know that when 
the draft is in "Last Call", it is intended only for WG members who have 
been actively involved in the development to take one last look before 
the draft moves on to the next stage of the process. I apologize for my 
ignorance.

However, I am still concerned for the following reasons:
1) The amount of buffering required to discard duplicate packets in ippm 
metrics:
 I did not see any discussion on this forum on orthogonality w.r.t 
duplication for ippm metrics, except our mention earlier as to ippm 
metrics not being orthogonal to packet duplication..

  "The requirement to ignore duplicate packets also mandates storage.
   Here, tracking the sequence numbers of missing packets may minimize
   storage size. Missing packets may eventually be declared lost, or
   reordered if they arrive. "

This statement says that we could track the missing packets. If such a 
mechanism is not in-built in the metric then how can we come up with 
computation complexities of the metrics?

Henk once sent me a feedback that reads as follows:

1. If I understand the algorithm correctly, then it needs an array
   in_buffer[N] with N the number of packets in a stream. This is not
   very practical, when I make a VoIP phonecall, then I never know how
   long it is going to last in advance and thus how I should dimension
   this array.

2. Can you include the same examples as in the other reordering metrics
   so one can compare the algorithms?

Henk

Same problem as 'point 1' will now exist for ippm metrics. Even if we 
are tracking lost packets, we could have a multiple bursts of losses, we 
will need a large buffer size and on top of it, the upper bound could be 
O(N). We will never know how long it is going to be in advance.

2) In the last meeting that I viewed (thanks to the broadcast 
facilities), it was clearly mentioned that the Reorder Density draft has 
a different definition for reordering than ippm metrics.
But I see that N-reordering has a different definition for reordering 
than all other ippm metrics.
The concept of subset cannot be accepted. Here, the set has only two 
types of elements, i.e., for Type-P-Reordered = TRUE and  
Type-P-Reordered = FALSE. So, a subset of Type-P-Reordered belonging to 
out of order packets, i.e., only a subset of  Type-P-Reordered = TRUE is 
TRUE  and remaining Type-P-Reordered = TRUE is FALSE does not make 
sense. Also, the definition of out-of-order packets being modified in 
n-reordering does not meet the fundamental requirement that a reorder 
metric has to capture reordering. I believe that we MUST meet this 
requirement first and then we can think of other MUST and SHOULD 
requirements. There could be useful applications in TCP Reno but then it 
is a kind of measurement that is useful, however can we really call it a 
metric for packet reordering?

Once Stanislav quoted:

Subject: Re: [ippm] New metric for packet reordering.
Date: 18 Feb 2003 01:07:27 -0500
From: stanislav shalunov <[email-masked]>
To: Nischal M Piratla <[email-masked]>
CC: [email-masked]
References: <[email-masked]>

Nischal,

It seems that:
* When `late' packets are encountered, your metric behaves like
  N-reordering;
* When `early' packets are encountered, your metric reports same
  degree of reordering as N-reordering, but larger number of packets
  are reported as reordered;
* When there are any missing packets, it reports high degrees of
  reordering for a whole bunch of packets.
This last is a show-stopper as far as I am concerned-- 

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

The n-reordering metric fails to the capture of the amount of 
reordering. Looking at the second point,  on the contrary, n-reordering 
does not report reordered packets as reordered according to the 
Type-P-Reordered definition. Though, I do not consider this problem as a 
show-stopper but I was hoping that we can all follow these useful 
comments. They were all excellent suggestions at least for us to take 
Reorder Density metrics to take to the next levels.

It is also possible that due to time constraints or whatever reasons, 
some of us have not read the draft very carefully and now I took the 
liberty to do so.

Thanks & Regards,
Nischal Piratla

****************************************************
Research Assistant
Computer Networking Research Laboratory (CNRL)
C203,Dept. of Electrical & Computer Eng.
Colorado State University,
Fort Collins, CO 80523
Voice: 970-491-7067/7974
Fax:   970-491-2249
http://www.cnrl.colostate.edu
http://lamar.colostate.edu/~nischal
****************************************************

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

---

From: Al Morton <[email-masked]>
Date: Mon, 18 Oct 2004 23:01:31 -0400

At 02:34 PM 10/18/2004, Nischal M. Piratla wrote:
...
>I assumed that if there are some discrepancies, the ippm members who have 
>not authored the draft can comment too. I did not know that when the draft 
>is in "Last Call", it is intended only for WG members who have been 
>actively involved in the development to take one last look before the 
>draft moves on to the next stage of the process. I apologize for my ignorance.

I did not say "only" active members. I simply described the process
when it works well, and how it usually works in IPPM WG.
You were asking newbie questions that had already been discussed on the
list or at meetings, and I answered by quoting from the draft.
In my opinion, that sort of exchange should take place before Last Call,
so I offered to discuss the draft one-to-one with you
(and thanks for sharing my off-list message with everyone).

>1) The amount of buffering required to discard duplicate packets in ippm 

Usually, storing the sequence numbers of missing packets and the
the largest sequence number received will be most efficient.
If you expect catastrophic loss, then store the numbers of the
packets that do arrive, and avoid O(N) that way.  Or track both until
the storage of one or the other is exhausted.  We don't specify
implementations, this draft provides definitions.  In my day job,
I loose interest in reordering if the loss is really high.

>metrics not being orthogonal to packet duplication..

This came-up at almost every IPPM meeting for the last 2 years,
with the same conclusion.

>...
>2) In the last meeting that I viewed (thanks to the broadcast facilities), 
>it was clearly mentioned that the Reorder Density draft has a different 
>definition for reordering than ippm metrics.
>But I see that N-reordering has a different definition for reordering than 
>all other ippm metrics.

You seem to want to equate the designation n-reordering with
Type-P-Reordered, but we have stated that Type-P-Reordered
is *the* definition of reordered packets in the draft.
n-reordering is a special designation of a reordered packet's position
w.r.t. in-order packets, and n-reordering only assigns a value of n
for some Type-P-Reordered=TRUE packets. I think that if n-reordering
were named "n-something_else", this might be more clear, but here we are.

In summary, we've discussed both items at some length in IPPM,
and reached conclusions that most people seem to be comfortable with.
...

>It is also possible that due to time constraints or whatever reasons, some 
>of us have not read the draft very carefully and now I took the liberty to 
>do so.

OK.  I hope this clears-up any misunderstandings.
Good luck with your Reordering Density draft.
Al

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 20 Oct 2004 21:22:51 -0700

Hi -

> From: "Al Morton" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, October 18, 2004 8:01 PM
> Subject: Re: [ippm] Question 3 - draft-ietf-ippm-reordering-07.txt
...
...
...

a comment on this discussion...

If the questions keep coming up, and only WG participants
are currently able to get through the draft without questions,
it would suggest that recording the group's reasoning there
might be beneficial.  A standard isn't just a memo to be read
by the people who helped write it.

Randy

---

From: Al Morton <[email-masked]>
Date: Thu, 21 Oct 2004 09:41:29 -0400

>by the people who helped write it.

Agreed.  Discussion of duplicates has been documented in the minutes,
but not every time. We have added text to the draft based on
the discussions (and even put it a forward reference, yuk),
but there are limits on how much we can add because
this is really an implementation issue. Duplicate packets
are also dealt with in several of the existing IPPM RFCs,
and what we've done in the reordering metric is consistent with precedent.

Al