[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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
ippm at ietf.org https://www1.ietf.org/mailman/listinfo/ippm