Subject: [ippm] comment on http://tools.ietf.org/html/draft-ietf-ippm-duplicate-02

From: "STEPHAN Emile RD-CORE-LAN" <[email-masked]>
Date: Wed, 17 Oct 2007 15:26:03 +0200

Hi Henk,
 
I have several comments. 

Scope:
 
The doc makes a lot of comparison with application behaviors. So, does it make sense to highlight that the doc does not cover the measure of retransmission of packets at the transport level or upper?
 
Definition of packet arrival count:
 
The example (with the TTL) should not be in the definition section.
            Fields of the header which do not change with the path must/may be part of the identification of a packet. 

Methodoly:
 
The methodology (section 2.6) of the draft refers to section 2.6 of RFC2680 which speaks about sync of clocks: 
Is the sync of clocks really needed for detecting packet duplication? 
Can the timeout correspond to the inter arrival time between the first packet received and the first duplicated packet received? 
Or is it mandatory to compute the diff of the owd?

Relation with ITU/T Y.1540:
 
Are Type-P-one-way-packet-duplication-fraction and IP packet duplicate ratio (IPDR) equal?
Are Type-P-one-way-replicated-packet-rate and replicated IP packet ratio (RIPR) equal?
 
Is there also an equivalent to the singletons definition? 

Editorial:
 
Add " count" to section 2 title.
I found a duplication of ',' in §2 of section 3.4 :-)
 
regards
Emile   

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

---

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 18 Oct 2007 09:42:45 +0200

Hi Emile,

Thanks for the comments.

> The doc makes a lot of comparison with application behaviors. So, does 
> it make sense to highlight that the doc does not cover the measure of 
> retransmission of packets at the transport level or upper?

I'm not quite sure if I understand this.  The document describes a way
to quantify duplication that occured between two points.  It doesn't
say anything about retransmission.

> The example (with the TTL) should not be in the definition section.

Moved this to the discussion.

>             Fields of the header which do not change with the path 
> must/may be part of the identification of a packet.

I'd say MAY.  What matters is the contents.

> Methodoly:
> The methodology (section 2.6) of the draft refers to section 2.6 of 
> RFC2680 which speaks about sync of clocks:
> 

No, actually this is one of the things that suprised me as well in
RFC2680.  Does anybody remember why this is in 2680?

> Can the timeout correspond to the inter arrival time between the first 
> packet received and the first duplicated packet received?

No, the idea is that one sets the timeout in advance.

> Are Type-P-one-way-replicated-packet-rate and replicated IP packet ratio 

Yes, the text says so.

> Is there also an equivalent to the singletons definition?

I don't have the ITU document handy but I don't remember a singleton
definition in there.  (Al, correct me if I'm wrong).

> Editorial:

Fixed.

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
------------------------------------------------------------------------------

Is one of the choices leaving the office open?
                                       Alan Greenspan on the next elections

---

From: Al Morton <[email-masked]>
Date: Thu, 18 Oct 2007 08:58:57 -0400

Replying to a couple of points:

At 03:42 AM 10/18/2007, Henk Uijterwaal wrote:
>...

You need to sync the timer (Th) for declaring a packet lost with
the sending time, in a course way at least.  Same is true
for ToD sync when starting and stopping samples: if a port opens
late the first packets will be ignored.
...

>...

You're right, but there are similar conventions, of course.
Y.1540 defines "outcomes" of packet transfer attempts, and
for this topic there are new sections defining duplicate and
replicated packet outcomes.

Al

---

From: "STEPHAN Emile RD-CORE-LAN" <[email-masked]>
Date: Thu, 18 Oct 2007 15:39:22 +0200

Hi Henk,

> RFC2680.  Does anybody remember why this is in 2680?

My understanding of the philosophy of RFCs 2679 & 80 is that a packet
arriving very very late is an excellent packet lost. Seriously, the
definition of the packet loss requires the time the packet is sent
because there is not any local (on the receiver) event available to
start the timeout timer.

Packet duplication differs. The reference of time for waiting a copy is
the arrival of a first image of the packet. So it does rely on any
remote time.

Regards
Emile

---

From: "Jeff W. Boote" <[email-masked]>
Date: Thu, 18 Oct 2007 09:48:51 -0600

> the arrival of a first image of the packet. So it does rely on any

A lost packet, should never be counted as a duplicate. These metrics should not 
be looked at in isolation - they are related.

jeff

---

From: Al Morton <[email-masked]>
Date: Thu, 18 Oct 2007 12:00:16 -0400

At 11:48 AM 10/18/2007, Jeff W. Boote wrote:
...Emile wrote:
>A lost packet, should never be counted as a duplicate. These metrics 
>should not be looked at in isolation - they are related.

We should be using one waiting time-out for all arrivals of
a packet launched at T, T+Th. That's how the ITU-T definition
works, and the RFC 2680 definition for loss:

>...
>    +  If the packet fails to arrive within a reasonable period of time,
>       the one-way packet-loss is taken to be one.  Note that the
>       threshold of "reasonable" here is a parameter of the methodology.
>
>       {Comment: The definition of reasonable is intentionally vague, and
>       is intended to indicate a value "Th" so large that any value in
>       the closed interval [Th-delta, Th+delta] is an equivalent
>       threshold for loss.  Here, delta encompasses all error in clock
>       synchronization along the measured path.  If there is a single
>       value after which the packet must be counted as lost, then we
>       reintroduce the need for a degree of clock synchronization similar
>       to that needed for one-way delay.  Therefore, if a measure of
>       packet loss parameterized by a specific non-huge "reasonable"
>       time-out value is needed, one can always measure one-way delay and
>       see what percentage of packets from a given stream exceed a given
>       time-out value.}

---

From: Henk Uijterwaal <[email-masked]>
Date: Fri, 19 Oct 2007 08:43:16 +0200

> works, and the RFC 2680 definition for loss:

I agree.

Henk

---

From: "STEPHAN Emile RD-CORE-LAN" <[email-masked]>
Date: Fri, 19 Oct 2007 09:51:56 +0200

Hi Henk,

Now we have a clear picture of the reason of need of sync. So at this step I think that we have to put that in the discussion section of the singleton metric definition.

Regards
Emile

> -----Message d'origine-----
> De : Henk Uijterwaal [mailto:[email-masked]]
> Envoyé : vendredi 19 octobre 2007 08:43
> À : Al Morton
> Cc : Jeff W. Boote; STEPHAN Emile RD-CORE-LAN; IETF IPPM WG
> Objet : Re: [ippm] need of sync of clocks in dup metric def
> 
> Al Morton wrote:

---

From: Henk Uijterwaal <[email-masked]>
Date: Fri, 19 Oct 2007 10:15:58 +0200

Hi Emile,

> the arrival of a first image of the packet. So it does rely on any

I assume you mean "does not rely" otherwise the question whether we need
sync'd clocks would be moot.

Under that assumption: loss is defined as send a packet at time T, wait
for it to arrive or not in some interval [T,T+delta].  I have defined
duplication in the same manner: send a time T, count the number of
copies that arrive in an interval [T, T+delta], with delta set to
be such that the packet actual has a chance to arrive, and such that
the receipient of a real application could still use the packet.
This makes the two definitions compatible.

Your idea would be: send packet at time T, wait for the first copy
to arrive, count the number of additional copies, in other words,
arrive in the interval [T+OWD, T+OWD+delta].  That could work too but
makes the definition somewhat incompatible with the loss definition.

Henk

---

From: Al Morton <[email-masked]>
Date: Fri, 19 Oct 2007 16:58:00 -0400

At 04:15 AM 10/19/2007, Henk Uijterwaal wrote:
>...Your idea would be: send packet at time T, wait for the first copy

I don't understand the value of a relative waiting time as described
above.  It might be worth thinking about characterizing the time
between arrival of the first packet and subsequent copies, but
it would clearly be a secondary sort of metric w.r.t. the duplication
itself.

Al

---

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 22 Oct 2007 09:02:44 +0200

> it would clearly be a secondary sort of metric w.r.t. the duplication

Neither do I, I just said that I can write a definition like this but
before I do so, I like to see some arguments why.

Henk