Subject: Re: fragmented PIM-SM Join/Prune

From: [email-masked] (Billy Ng)
Date: Thu, 26 Aug 1999 00:16:53 -0400

> From [email-masked] Wed Aug 25 23:45:50 1999
> 
> > I see one possible problem with big PIM join/prune packets across a single
> > group.
> > 
> > Basically the problem is that if there is a large number of sources
> > for one group and the join/prune message cannot fit in one packet,
> > the packet needs to be splitted.  The problem came with the second
> > refresh of these fragmented packets because the first packet will
> > graft any (s,g)s that are not yet received with this first fragment
> > having a (*,g) entry.  The spec should spell out the steps to avoid
> > this problem.
> 
> Can you describe in more details the problem, and give an example,
> because the above scenario is a little bit unclear to me.
> 
> Pavlin
> 

Pavlin, sorry for the confusion.  Let me try again with an example:

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.

--Billy

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Wed, 25 Aug 1999 21:43:22 -0700

> This causes traffic to duplicate a burst downstream every join/prune interval.

A quick question before I try some more speculative arguments ;)

What would happen if the downstream refreshes first only some of the
prunes, and in the last packet refresh the (*,G)Join + the remaining
prunes. Sending a J/P packet with prunes only does not remove the
existing (*,G) (or does it?). Does it violate the spec in any way,
or does it create any problems (sorry, it has been a while I've read
the spec in details ;)

Pavlin

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Wed, 25 Aug 1999 22:01:38 -0700

> > This causes traffic to duplicate a burst downstream every join/prune interval.

Ooops, please ignore the quick suggestion below. The last
packet/fragment will be still considered as one entity, and the
(*,G) there will remove all prunes that were not included there.
A little bit on the same subject in a separate email.

Pavlin

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Wed, 25 Aug 1999 22:41:23 -0700

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

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.

Pavlin