Subject: Re: fragmented PIM-SM Join/Prune

From: Bill Fenner <[email-masked]>
Date: Thu, 26 Aug 1999 00:15:00 -0700

>The spec should spell out the steps to avoid this problem.

Section 3.2.1.3 says what to do -- use IP fragmentation.

  Bill

---

From: [email-masked] (Billy Ng)
Date: Thu, 26 Aug 1999 23:51:10 -0400

> From [email-masked] Thu Aug 26 01:42:17 1999
> 
> > Let's say my max ip packet size is 1500 bytes (don't want to do ip
> > fragmentation), and there are 1000 sources sending to the same group.
> > After (*,G) state is setup on the shared tree, all 1000 sources start
> > sending to the same G.  Now the last hop router joins SPT for all 1000
> > sources.  Let's assume the shared tree and SPT tree take different paths
> > from the last hop DR.  Now the last hop DR needs to prune all those
> > 1000 sources toward the shared tree.
> > 
> > As you can see, the join/prune packet to prune the share tree can not be
> > made up using a singe packet since it will exceed my max ip packet size
> > of 1500 bytes.  Therefore I need to split the join/prune into several
> > packets.  The first prune packets will contain a (*,G) and prunes for
> > (S,G)s.  However, I cannot fit all these (S,G) prunes in one packet, so
> > I send them in the next several packets.  This is fine for the first 
> > batch of prunes (approximately 3 packets in a row).  Now comes the next
> > join/prune interval.  Again, I start sending out the first packet with
> > (*,G) and all the (S,G)s I can fit in the first packet.  However, since
> > I cannot send everything at once, the upstream node receiving the first
> > packet still has all the (S,G)RPTs for all 1000 sources, and sending the
> > first packet with only some of the (S,G) prunes would only refresh those
> > some (S,G)RPTs but _grafts_ all the others (basically removing all the
> > other (S,G)RPTs states).  At this point, traffic can start to flow until
> > the next fragment of the prunes come in setting up the prune states again.
> > 
> > This causes traffic to duplicate a burst downstream every join/prune interval.
> 
> Actually, the receivers will not get any duplicates, because the
> router that initiate the Prunes (the DR in your example) will not
> accept those duplicates coming on the wrong iif (the iif toward the
> RP instead the iif toward the S). In fact, even the routers that are
> between the DR and the RP might not get any unwanted traffic through
> the RP, because all upstream routers have to be in this inconsistent
> state when not all Prunes were received (taking into account that
> the J/P messages hop-by-hop propagation up to the RP takes time,
> eventually much longer than the inconsistency time in a single
> router) In fact, further from the RP, lower the probability that all
> upstream routers are in inconsistent state.
> 

Yes, agree.  I was just not comfortable with lots of states being removed
and added unnecessarily.

> BTW, why not 64K IP packets + IP fragmentation (or this was just an
> example)? 64K packets will allow for much larger number of prunes in
> the same message, so in practice filling up the whole packet will be
> very rare, so we can just ignore the problem.
> 

I have seen some implementations handle fragmented join/prune without using
IP fragmentation and was wondering how this should be handled.

Thanks,

--Billy

> Pavlin