Subject: Pruning question

From: Toerless Eckert <[email-masked]>
Date: Tue, 20 Feb 1996 10:04:51 +0100 (MET)

Hi

Sorry, if my question is explained in some RFC. In that case, please send
me just the number of that rfc.

I am wondering how well pruning in an mrouted (>=3.8) environment is expected
to work. The setup i am interested in and where i do not see pruning
(even though people tell me i should see it) is like this:

		 my-local-net
		      ^
		      |
		  My-dvmrp-router
		      |
		      | dvmrp tunnel threshhold 24
		      |
		  Next-dvmrp-router
		   !           |..|
  dvmrp tunnel     !           |..|
  thresshold 32    V           V  V
                 to-mbone      to-local-networks

Effect: In my local net a sender starts sending to a multicast group with
no members. It uses a threshhold of 31. As long as the next-dvmrp-router
does not have the tunnel to-mbone, my-dvmrp-router gets back a prune from
the next-dvmrp-router. If the next-dvmrp-router does have this tunnel
to-mbone, it does not send back this prune, even though it of course will
not pass any traffic from my sender through the tunnel to-mbone, because
the threshold will cut it out.

Is this how dvmrp/mrouted is expected to work ? 
Is this a bug or a feature ? If this is a feature it's really bad.
		  
-- 
Toerless Eckert
Universitaet Erlangen Nuernberg
Lehrstuhl fuer Betriebsysteme 
Martensstrasse 1
D-91058 Erlangen, Germany
Tel.: +49 9131 85 7278
FAX: +49 9131 85 8732
[email-masked]
/C=De/A=D400/P=Uni-Erlangen/OU=Informatik/S=Eckert/G=Toerless/

---

From: Ajit Thyagarajan <[email-masked]>
Date: Tue, 20 Feb 1996 11:50:27 +0000

>Is this a bug or a feature ? If this is a feature it's really bad.

Toerless,

I think you are mixing lack of group membership with scope-control
using ttls.  Pruning will occur at a router for some (source,group)
only if there are no group members in any of its downstream links.
So, if some of your datagrams have a lower ttl, which cause it to get
tossed out at some intermediate router on the spanning tree, it does
not mean that the spanning tree should be pruned at that point.  There
could be other datagrams from the same source to the same group with a
larger ttl which would then not get through, but actually should.

In your case, you should use an "administratively scoped" group
(239.x.x.x) and set up the appropriate scoping rules on your tunnel
to-mbone so that pruning can then occur for that group.

Ajit

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 20 Feb 1996 13:03:19 +0100 (MET)

Thanks for the quick response, Ajit.

> to-mbone so that pruning can then occur for that group.

Well, yes and no. For once, what you say is what i thought initially,
but i both have been told otherwise by people and i was hoping that it
would be otherwise. So far, we do not have administrative scoping, and thus
it wouldn't have been so bad an idea to realise administrative scoping
through ttl livetime. Sure, there could be packets with a higher ttl
from the same source, this would only mean that those packets don't
get through until the prune sent back times out.

So, if there's a chance to get it in, i'd vote for mixing of
group membership with scope control. Which would mean implementationwise
that a mrouter that detects that packets from a souce will not be sent
out any interface, either due to pruned interfaces or to thresholded
interfaces will send back a prune. What would be so extremely bad
about it ? I think it would very much help the situation in those areas
of the mbone who try hard to get pruning done. So far we've got the problem
(e.g.: in germany) that even though we've got pruning deployed everywhere,
that all our traffic within germany unnecessary fills up the links going
to the mbone entry point...

best regards
	Toerless

---

From: Ajit Thyagarajan <[email-masked]>
Date: Tue, 20 Feb 1996 12:52:54 +0000

>from the same source, this would only mean that those packets don't
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>get through until the prune sent back times out.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 

This certainly goes against the model of delivering packets even with
the "best effort" to receivers.  What you have essentially created
then is a black hole at that point.  I don't think you realize what
the repurcussions of what you propose are!  With the current
prune-sent-back-time as 5 mins, downstream receivers are then not
going to receive any datagrams for that entire period which is
terrible!  All applications would suffer because of that one packet
which caused the prune.

>to the mbone entry point...

The next thing you might say/propose is that all traffic generated by
a single source should necessarily have a constant ttl.  A number of
applications these days use expanding ring searches (using ttls) to
locate resources and this mechanism you propose would throw it
completely in disarray!!!

Once again, what you really need is administrative scoping at your
mbone-entry points.  If you restrict the group addresses as mentioned
before, you will be keeping all your "local" traffic within Germany
and not filling up your out-going links.

Ajit

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 20 Feb 1996 14:14:47 +0100 (MET)

> completely in disarray!!!

Gee, i didn't expect the spanish inquisition.

But i think i get the point. It's hard to think about a timeout mechanism
which will reasonably well prune only if ttl limited traffic would come through.
Either you prune quickly and thus never learn that there's traffic with 
a higher ttl, or you prune slowly and it won't have much of an improvement
factor anyway. Dense mode just sucks *sigh*.

Thanks again for enlightening me.

---

From: Ajit Thyagarajan <[email-masked]>
Date: Tue, 20 Feb 1996 14:14:40 +0000

Toerless Eckert wrote:
>But i think i get the point. It's hard to think about a timeout
>mechanism which will reasonably well prune only if ttl limited traffic
>would come through.  Either you prune quickly and thus never learn
>that there's traffic with a higher ttl, or you prune slowly and it
>won't have much of an improvement factor anyway. Dense mode just sucks
>*sigh*.

Thats true.  The ttl-based scoping mechanisms were originally
introduced to overcome the "broadcast" (actually truncated-broadcast)
behaviour of the non-pruning implementations of DVMRP.  I don't think
it was intended to be anything more than a temporary work-around,
i.e. until better scope-control mechanisms were in place.  I don't
know, does dense-mode PIM also support threshold-based scoping?

>Gee, i didn't expect the spanish inquisition.

:) it must be the effect of the movie I saw last night -
   Yo, la peor de todas (I, worst of all).

Ajit

---

From: Petri Helenius <[email-masked]>
Date: Sun, 28 Apr 1996 09:23:53 +0300 (EET DST)

> and not filling up your out-going links.

I'm suffling around my older messages and came across the above. I'd like
to report that we've successfully deployed scoped addressing in Finland
and pruning is functional bidirectionally over the PIM<-->DVMRP
interoperability point. The boundaries are implemented in the DVMRP
side where two tunnels leave Finland, one for Russia, one for Sweden.
All this has been verified to work also in the live network.

The next big thing is to have people to change over to sdr in order
to be able to automatically assign scoped addresses to sessions. It
seems to be working reasonably well.

Pete