Subject: [ippm] comments on -ippm-duplicate-01.txt

From: Al Morton <[email-masked]>
Date: Mon, 30 Jul 2007 18:33:59 -0400

I promised Henk to send my comments at the IPPM session
to the list.  I mentioned the naming issue at the mic,
but there are several others. Here they are, with a bit more detail.

Al

In general, I like the draft, it's very direct and easy to understand.

>2.1.  Metric Name
>
>    Type-P-One-way-Packet-Duplication
>
>...
>
>2.4.  Definition
>
>    The value of a Type-P-One-way-Packet-Duplication is a positive
>    integer number indicating the number of (uncorrupted and identical)
>    copies received by dst in the interval [T, T+T0] for a packet sent by
>    src at time T.

The definition should require identical information fields,
but not necessarily identical IP headers. There are legitimate
reasons that the headers could be different, e.g., because the
packet took a different path the TTL and checksum would be different.
This is the way the Y.1540 definitions work.

This means that the Active test system MUST NOT send packets with
identical information fields, or they will all be declared duplicates.
This consideration should be mentioned in discussion.

>    If a packet is sent, but it is lost or does not arrive in the
>    interval [T, T+T0], then the metric is undefined.
>
>2.5.  Discussion
>
>    This metric counts the number of packets arriving for each packet
>    sent.  The time-out value T0 SHOULD be set to a value when the
>    application could potentially still use the packet and not discard it
>    automatically.

Also, this definition essentially describes an arrival counter,
and therefore
                 Type-P-One-way-Packet-Duplication = 1

means *no duplication* (?).

It would seem to be more accurate to re-name this singleton to
be more consistent with the definition, and withhold calling anything
"duplicate" until we define the statistics in section 4.

I suggest:
Type-P-One-way-Packet-Arrival-Count

and in Section 3

>3.1.  Metric Name
>
>    Type-P-One-way-Packet-Duplication-Poisson-Stream

Type-P-One-way-Packet-Arrival-Count-Poisson/Periodic-Stream

(Periodic streams are allowed, too)

<back to Section 2.5>

>2.5.  Discussion
>...
>    If a packet is fragmented and one of the fragments arrives more than
>    once, then the packet is counted as duplicated.

How does this work?  If I get a both fragments of a packet (70%+30%= 100%),
and then a duplicate of the larger of the fragments, is the arrival
count 1.7? No, that would be non-integer, but is it really 2?
How can I tell that the missing fragment would have been identical?

I didn't expect this, because we have always specified that all fragments
of a packet must arrive for the packet to be counted as successfully
transferred (not-lost), otherwise the packet is considered lost.

I suggest that we fix this by requiring all fragments to be reassembled
before incrementing the arrival counter.  This should be part of
the definition, and we can talk about it in the discussion if you want.

2.4.  Definition

    The value of a Type-P-One-way-Packet-Duplication is a positive
    integer number indicating the number of copies received by dst
    with uncorrupted and identical information fields in the interval
    [T, T+T0] for a packet sent by src at time T. If the packet is
    fragmented and if, for whatever reason, re-assembly does not occur,
    then the packet will be deemed lost.

In
>4.  Some statistics definitions for One-way Duplication
>
>4.1.  Type-P-one-way-packet-duplication-average
>
>    This statistics gives an estimate of the fraction of additional
>    packets that arrived in a stream.

Why is this an estimate?  I think it is exact for the stream we are
measuring.  I suggest:

    This statistic gives the fraction of additional packets that
    arrived in a stream.

And similar for 4.2.  Type-P-one-way-packet-duplication-rate

    This statistic gives the fraction of packets that were
    duplicated (one or more times) in a stream.

Names of parameters in 4.1 and 4.2:

I think the following are more straightforward names:

4.1.  Type-P-one-way-packet-duplication-fraction

4.2.  Type-P-one-way-duplicated-packet-rate

or, if we want even more consistency with Y.1540,

4.2.  Type-P-one-way-replicated-packet-rate

Finally, I like the examples, they illustrate why we have these
two parameters very well.

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