Subject: [ippm] WGLC for draft-ietf-ippm-duplicate-03

From: Matthew J Zekauskas <[email-masked]>
Date: Wed, 11 Jun 2008 09:37:30 -0400

IPPM group,

This message announces a WGLC for draft-ietf-ippm-duplicate-03.

The draft fills a hole in the IPPM metrics, has been discussed
in this group and appears to have support and be stable. I
would like to start a Working Group Last Call in order to move it forward.

Since Henk is the author, I'll be doing consensus calls and acting as 
document shepherd, assuming it moves forward.

Please raise any remaining issues by Thursday June 26, 2008 at 23:59 UTC.

Notes of support for forwarding this draft are also appreciated and help 
us out.  This draft is slated to be forwarded as a Proposed Standard.

A URL for the draft is:

<http://www.ietf.org/internet-drafts/draft-ietf-ippm-ippm-duplicate-03.txt>

and the tools team also has a great page here:

<http://tools.ietf.org/wg/ippm/draft-ietf-ippm-duplicate/>

--Matt
IPPM Co-Chair

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

---

From: Matthew J Zekauskas <[email-masked]>
Date: Wed, 11 Jun 2008 13:58:35 -0400

It has been pointed out that I fat-fingered the direct URL (duplicating 
text, of course!).

A correct direct URL is
<http://www.ietf.org/internet-drafts/draft-ietf-ippm-duplicate-03.txt>
(cut-n-pasted for extra insurance).

The tools-team URL below is correct though.

--Matt, glad that someone reads his messages

---

From: Al Morton <[email-masked]>
Date: Wed, 25 Jun 2008 22:09:55 -0400

>(cut-n-pasted for extra insurance).

Henk,

I have a few wording suggestions, but otherwise I think
this is ready to go.

Al

Section 1, last bullet:
>    o  Finally, a method to summarise the properties of these samples are
>       introduced.

The last aspect introduced is "statistics" (our framework is
singletons, samples, statistics) so I suggest:

    o  Finally, statistics that summarize the properties of these samples are
       introduced.

Section 1.2, 2nd para
>    In earlier work, the IPPM (IP Performance Metrics) group defined a
>    metric for packet loss [RFC2680].  This metric quantifies the case
>    where a packet that is sent, never arrives at its destination.  In
>    this memo, a metric for the opposite case is defined: a packet is
>    sent, but multiple copies arrive.

I have a couple of quibbles with this, the definition of a lost
packet and the fact that there are three possible outcomes in the
taxonomy of arrivals. I'll just write what I mean:

In earlier work, the IPPM (IP Performance Metrics) group defined a
metric for packet loss [RFC2680]. This metric distinguishes the outcome
where a transmitted packet does not arrive at its destination within a
reasonable time from the arrival outcome. In this memo,
a metric for yet a third outcome is defined: a single packet is sent
and multiple copies arrive.

Section 2.2 Metric_ Parameters
As I said on the LSP set memo, I think that more description
of the time parameters is helpful:
>    o  T, a time
>    o  T0, a time

I suggest:
    o  T, the wire time of a packet at the source
    o  T0, the maximum waiting time for a packet to arrive at the destination

Section 2.4 Definition
>    Two packets are considered identical when were sent by one and the
>    same host and contain identical information fields.  The recipient
>    thus could take either packet and use it in an application, the other
>    copy would not contain any additional information.
>
>    The IP headers do not necessarily have to be identical.

I suggest:
    Two packets are considered identical if and only if:
    + both were sent by one and the same host
    + both contain identical information fields
    + both contain valid, but not necessarily identical IP header fields

I saw some other minor editing opportunities, but I'm out of time
to type them up tonight.

---

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 26 Jun 2008 10:36:18 +0200

Hi Al, others,

>    + both contain valid, but not necessarily identical IP header fields

I think this is a good summary of what we're trying to say.

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
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: Henk Uijterwaal <[email-masked]>
Date: Fri, 27 Jun 2008 09:30:55 +0200

Hi Al, others,

> I think this is a good summary of what we're trying to say.

Thinking about this longer: it probably isn't.  Suppose we have a path:
source, intermediate devices, destination.  The source sends one packet,
an intermediate device duplicates it, destination gets two copies.  This
is duplication, but it fails the definition above.   So, I'd rephrase
it into:

   + both appear to have been sent by one and the same host, to one
     and the same destination

This covers the case above.  (Funny that definining something obvious
is so complicated).

Henk

--

---

From: Al Morton <[email-masked]>
Date: Fri, 27 Jun 2008 08:01:49 -0400

>This covers the case above.  (Funny that definining something obvious

So, are we really saying that the Source and Destination address fields
must be identical?  That's the specific info that seems to relevant.

Al