Subject: [ippm] draft-ietf-ippm-duplicate

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 17 Apr 2007 09:15:19 +0200

IPPM group,

As promised in Prague:  I've written up my notes on a duplication metrics
in an ID and submitted it to the secretariat.  As soon as it comes out,
please comment.

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

# Lawyer: "Now sir, I'm sure you are an intelligent and honest man--"
# Witness: "Thank you. If I weren't under oath, I'd return the compliment."

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

---

From: Al Morton <[email-masked]>
Date: Tue, 17 Apr 2007 09:27:51 -0400

At 03:15 AM 4/17/2007, Henk Uijterwaal wrote:

As promised in Prague:
I've written up my notes on a duplication metrics

in an ID and submitted it to the secretariat.  As soon as it comes
out,

please comment.

Henk

Also as promised in Prague, here are the latest definitions

of Duplicate and Replicated packet outcomes and parameters

from the draft revision of Y.1540.

MPi = Measurement Point i    NSE=Network
Section Ensemble

Al

(not sure if the subscripts will be presented properly in some mail

readers, but it's worth a try...)

5.5.8.3  duplicate IP packet outcome: A duplicate packet
transfer outcome is a

subset of  successful packet outcomes, and occurs when a single IP
packet

reference event at a permissible ingress MP0 results in two or
more

corresponding reference event(s) on at least one permissible egress
MPi, and

the binary information fields of all the output packets are identical to
the

original packet. The egress reference event at MPi for a
duplicate packet

occurs subsequently to at least one other corresponding egress
reference event

for the original packet (usually also at MPi).

Note that in point-to-point communication, there is only one permissible
egress

MPi where the destination host is directly attached to the
NSE. In point-to-

multipoint communication, there may be many permissible egress
MPi for the

various destinations.

5.5.8.4  replicated IP packet outcome: A replicated packet
transfer outcome

occurs when a single IP packet reference event at a permissible ingress
MP0

results in two or more corresponding reference event(s) on at least one

permissible egress MPi, and the binary information fields of
all the output

packets are identical to the original packet.  The egress reference
event at

MPi for a replicated packet is the first for the original
packet and occurs

prior to at least one other egress reference event for a duplicate packet

(usually also at MPi).

6.8        IP packet duplicate
ratio (IPDR): IP packet duplicate ratio is the

ratio of total duplicate IP packet outcomes to the total of successful IP

packet transfer outcomes minus the duplicate IP packet outcomes in a
population

of interest.

6.9        replicated IP packet
ratio (RIPR): The replicated IP packet ratio is

the ratio of total replicated IP packet outcomes to the total of
successful IP

packet transfer outcomes minus the duplicate IP packet outcomes in a
population

of interest.

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 18 Apr 2007 10:17:28 +0200

Al,

> from the draft revision of Y.1540. 

Thanks.

> *5.5.8.3  duplicate IP packet outcome*: A duplicate packet transfer outcome
> is a subset of  successful packet outcomes, and occurs when a single IP
> packet reference event at a permissible ingress MP_0 results in two or more 
> corresponding reference event(s) on at least one permissible egress MP_i, and
>  the binary information fields of all the output packets are identical to the
>  original packet.

This looks fine (and the same to what I defined).

  > *5.5.8.4  replicated IP packet outcome*: A replicated packet transfer outcome
 >  occurs when a single IP packet reference event at a permissible ingress MP_0
 > permissible egress MP_i , and the binary information fields of all the output
 >  packets are identical to the original packet.

This looks fine too, but as far as I can see, it is exactly the same
as for a duplicate IP packet outcome.

And then, for DIPPO:

 > The egress reference event at MP_i for a duplicate packet
> occurs subsequently to at least one other corresponding egress reference
> event for the original packet (usually also at MP_i ).

I can understand this too, it seems to say that the DIPPO occurs after
the first copy arrived.  That makes sense.  But then for RIPPO:

> The egress reference event at MP_i for a replicated packet is the first for
> the original packet and occurs prior to at least one other egress reference
> event for a duplicate packet (usually also at MP_i ).

This seems to say that the RIPPO occurs before the reference event.  But
how can one tell?  A packet is sent and received, how can the receiver
tell that a second copy will arrive until that copy actually arrives?
But then what is the difference w.r.t. DIPPO: in both cases 1 packet
is sent and 2 copies arrive.  (And the first copy is presumably used
by the recipient, anything else doesn't make sense).

Or is there another subtle difference between DIPPO and RIPPO that I've
missed?

Henk

---

From: Al Morton <[email-masked]>
Date: Wed, 18 Apr 2007 09:31:11 -0400

>as for a duplicate IP packet outcome.

Yes, the "set-up" conditions are the same for both.  In fact,
you can't have a replicated packet without subsequently observing
a duplicate.

>This seems to say that the RIPPO occurs before the reference event.

It occurs before a DIPPO on egress, and can only be determined after a
DIPPO has occurred.  Note that "least one other egress reference event for
a duplicate packet" or DIPPO is a necessary condition in the definition.

>But how can one tell?  A packet is sent and received, how can the receiver

The RIPPO can only be determined after a DIPPO.  There has to be some
memory in the receiver to determine a DIPPO, and the packet that the
DIPPO corresponds to would be designated RIPPO.

>by the recipient, anything else doesn't make sense).

The first of the copies is designated as RIPPO.

Maybe it would help to define a Non-Replicated IP Packet Outcome,
but I thought that wasn't necessary.  All successful egress packet
outcomes are non-RIPPO initially. If there is a DIPPO, then there must
be a corresponding RIPPO to designate.

Multiple DIPPOs could come from one RIPPO,
or the same number of RIPPOs, or some other combination.
So distinguishing and counting the RIPPOs helps to determine
whether 50 duplicate packets came from one packet or
from 50 RIPPOs.

Another way to distinguish these cases would be to count the
first DIPPO, e.g., DIPPO_1, separate from subsequent DIPPOs that
correspond to the same packet, DIPPO_2, DIPPO_3, ... DIPPO_n

>Or is there another subtle difference between DIPPO and RIPPO that I've

Now that I've explained it further, maybe you can suggest a way
to modify the definition of RIPPO so that it is clear?
I'm open to suggestions.

Al

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 18 Apr 2007 17:18:26 +0200

> At 04:17 AM 4/18/2007, Henk Uijterwaal wrote:

[...]

> The first of the copies is designated as RIPPO.

Aha, now I understand: a packet is sent and arrives multiple
times.  In your definition, the first copy is called the RIPPO
and all others the DIPPOs.  And it won't be a RIPPO, but something
else, until there is a DIPPO.   In other words, you have a stream

  RIPPO, DIPPO_1, DIPPO_2, ..., DIPPO_n

In my definition, all copies are treated equally so essentially
I have a stream

  copy_1, copy_2, ..., copy_(n+1)

which can be mapped 1-1 to your definition.  The two definitions
then are the same.  In my draft, only define the equivalent of
the DIPPO ratio but I can easily add the equivalent of a RIPPO
rate (it is the number of packets in the stream for which more
than 1 copy is received).

> whether 50 duplicate packets came from one packet or

Correct, didn't think about this, and it does seem useful.

> to modify the definition of RIPPO so that it is clear?

Look at my draft when it gets through the queue ;-)

Henk