Subject: [magma] PIM : detecting duplicate packet

From: "tajay" <[email-masked]>
Date: Sun, 10 Dec 2006 10:57:02 +0530

Hi,
Most of the opimization algorithms in PIM depends on detecting duplicate packets. 
e.g
(1) sending register stop once RP starts receiving duplicate packets
(2) DR @ source sends prunes (S,G) from RPTree whenever it receives duplicate 
packets from source.

Is there any specific way to identify duplicate packets? And how feasible it
is to detect duplicate packets at very high rate traffic?

Ajay

--
Open WebMail Project (http://openwebmail.org)

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

---

From: "tajay" <[email-masked]>
Date: Sun, 10 Dec 2006 23:11:40 +0530

Hi,
I am confused about behaviour on lan interfaec. 
On the lan interface we can have multiple neighbors on the same
interface that time incoming interface remains same but still 
packet can come from different neighbors.

I am just giving one simple network topology as example.

       R1               R2
       |                |
       |                |
       |----------------|
            |
            |
            |
           R3
            |
            |
          Receiver

R3 has 
RPF_interface(S)= R1 and
RPF_interface(RP) = R2 
After switching to SPTree R3 may receive 2 packets..??

or following topology

          RP
           |
           |
           |
          Rs------Sender
           |
           |
           |
          Rr
           |
           |
          Receiver
In above topology at Rr, RPF_interface(S) and RPF_interface(RP)
are same.

Ajay

---------- Original Message -----------
From: [email-masked]
To: tajay <[email-masked]>
Cc: [email-masked]
Sent: Sun, 10 Dec 2006 17:49:11 +0100
Subject: Re: [magma] PIM : detecting duplicate packet

> Quoting tajay <[email-masked]>:
> 
> > Hi,
> Hello,
> You dont really need to detect that a packet is duplicated.
> It is  sufficient to detect if  a native multicast packet from a 
> given  source S has been received by the incoming interface of the 
> source tree for S
> (and this interface is different from the incoming interface of the 
> shared tree for the same group)
> 
> cheers
> Jean-Jacques
>

---

From: John Zwiebel <[email-masked]>
Date: Mon, 11 Dec 2006 10:13:58 -0800

> is to detect duplicate packets at very high rate traffic?

To correct a slight misunderstanding, it isn't "duplicate" packets  
that are
being detected, but the arrival of packets on an alternate network  
path.  It is
'assumed' that this will ensure there is no loss of data when  
switching from
the RP-tree to the shortest-path, or from pim registration to the  
shortest-path.

And you have #2 wrong, it isn't the DR at the source, but it is the  
last-hop router,
which may or may not be the DR, that joins to the spt.

To be honest, it has never been clearly shown that the complications  
of such
a data-path switch are really useful.  In fact, some applications  
have been
shown to croak (or at least not handle well) reception of duplicate  
packets.

You might consider:
   -- On the last hop router, as soon as receipt of a mpacket down  
the shared-path
	creates (S,G) state, immediately sending (S,G,R) prunes while at the  
same
	time sending (S,G) joins for the SPT.  You will lose some mpackets, but
	your application probably hasn't had the chance to figure out that  
there
	really is data available.

   -- On the RP, as soon as a PIM-register is received sending a  
register-stop at the
	same time you send an (S,G) join.  Again, you will lose some  
mpackets, but
	it hasn't been shown that applications would recognize this loss.

These two suggestions do not comply with the PIM RFC.  Its your  
choice whether or not
you think its important enough.

z

---

From: John Zwiebel <[email-masked]>
Date: Mon, 11 Dec 2006 10:19:58 -0800

These topologies are not the same.

In the first the RFC expects you to create (S,G) state but continues to
receive mpackets down the RPT until there is an assert from R1 which
signals that data is indeed arriving on the SPT.  To get the assert,  
there
are indeed duplicate packets on the LAN.

In the second case, since the RPF to the RP and the RPF to the source  
are
the same router (Rs), there isn't anyway for Rr to know if the SPT is  
completely
set up (assuming more routers between Rs and the source), so Rr marks  
the
SPT as up as soon as it creates (S,G) state.