Subject: mbone dvmrp/pim

From: Jeremy Porter <[email-masked]>
Date: Wed, 17 Sep 1997 22:22:10 -0500

Currently I have a dvmrp (mrouted) tunnel setup over an 64k/128k ISDN link,
there seems to be some sort of issue causing the link to become congested
periodicly, when I'm not even listening to any multicast addresses.
Based on tcpdump data, it doesn't look like a huge amount of mbone
traffic is being flooded and pruned, but this is the only think I can
think of that could be causing it.  It is partciuarlly difficult
to tell, as the second 64k channels is added dynamicly when the bandwidth
is needed.  If I'm understanding dvmrp/flood and prune, it would seem
that there should be a small limit on the number of flooded messages.
However, I seem to be getting a few address that seem to keep flooding
despite the fact that neither of the two machines are activly listening
(194.214.173.11 seems to be particuarlly bad right now to 224.2.173.221.55610),
It seems wasteful to eat almost 64k just on routing overhead.  I'm hoping
that there is a bug or misconfiguration causing this.

If this is normal for mrouted, will running PIM be "better", or use
less bandwidth?

---
Jeremy Porter, Freeside Communications, Inc.      [email-masked]
PO BOX 80315 Austin, Tx 78708  |  1-800-968-8750  |  512-458-9810
http://www.fc.net

---

From: Petri Helenius <[email-masked]>
Date: Thu, 18 Sep 1997 08:34:01 +0300 (EEST)

> that there is a bug or misconfiguration causing this.
Mrouted does not retransmit prunes. If the upstream loses one, you'll
get flooded for minutes or hours, depending on the state lifetime.
 > If this is normal for mrouted, will running PIM be "better", or use
Sparse mode PIM is the protocol of choice for low-bandwidth stub
links. (and other places too)

Pete

---

From: John Meylor <[email-masked]>
Date: Thu, 18 Sep 1997 08:01:00 -0700

> If this is normal for mrouted, will running PIM be "better", or use

Normal for flood and prune in general.  PIM sparse-mode would
require that traffic for a particular session be explicitly
requested.  Traffic for other sessions would not flow unless
also requested. This in combination with properly configured
access list for "interesting" traffic provides a very
efficient use of the dialer and your ISDN bandwidth.

see:

ftp://ftpeng.cisco.com/ipmulticast.html

for specific isdn config info for ciscos.

Note however that a single session can exceed the total
available ISDN bandwidth. If you can't get the bandwidth
reduced at the source (eg source providing a low-bw 
2nd session for low-bw paths), then your ISDN will still
be congested regardless of routing protocol.

- John Meylor

---

From: [email-masked] (Lukas Wunner)
Date: Thu, 18 Sep 1997 17:39:12 +0200 (MET DST)

Howdy,

> periodicly, when I'm not even listening to any multicast addresses.

Yes, it is my experience that a 64kbps line gets fairly congested merely with
the flooding+pruning of DVMRP or dense-mode PIM. According to Axel Clauberg,
sparse-mode PIM will help a lot in that respect, but it seems there is no
(stable) implementation of sparse-mode PIM available for Unix boxes w/
mrouted as of yet (please correct me if I'm wrong).

	Lukas.

-- 
lukas wunner         unix, internetworking and security engineer
[email-masked]      LW26-RIPE      http://www.wunner.de/~lukas/
"Shee, you guys are so unhip it's a wonder your bums don't fall off."

---

From: "Heiko W. Rupp" <[email-masked]>
Date: Thu, 18 Sep 1997 18:04:57 +0200

> mrouted as of yet (please correct me if I'm wrong).

There should be one in a gated release. Dunno which one though.

-- 
NTG Netzwerk und Telematic GmbH   /          Heiko W.Rupp
Geschaeftsbereich Xlink         \/           phone: +49 721 9652 0
Vincenz-Priessnitz-Str. 3       /\ link      fax:   +49 721 9652 210
D-76131 Karlsruhe, Germany     /_______      email: [email-masked]
[ NTG Netzwerk und Telematic GmbH, Sitz Chemnitz                          ]
[ Kreisgericht Chemnitz/Stadt HRB 4217, Geschaeftsfuehrer: Michael Rotert ]

---

From: [email-masked]
Date: Thu, 18 Sep 1997 09:29:56 -0700 (PDT)

> There should be one in a gated release. Dunno which one though.

I understand that one of my co-workers has a version which is being
submitted to the gated consortia.   For more detail, contact
Rusty at  [email-masked]

-- 
--bill

---

From: Bill Fenner <[email-masked]>
Date: Thu, 18 Sep 1997 09:50:12 PDT

Jeremy,

  I'd suggest giving mrouted 3.9-beta2 a try.  With its prune
retransmission and longer prune timers, it reduces the bandwidth used
by a DVMRP tunnel to a pretty negligible amount.  I accidentally left
my DVMRP tunnel up for the last 3 days and I didn't notice the impact
on my ISDN link (looks like ~2kbps).

  Bill

---

From: [email-masked]
Date: Thu, 18 Sep 1997 10:04:25 -0700 (PDT)

> submitted to the gated consortia.   For more detail, contact

i have been working on pim-sm for gated version 5.  as far as stability,
it's still alpha we've done some tests in labs but have no real-net 
experience, yet.  the gated software will not interoperate with mrouted,
however, Dave Thaler is working on the dvmrp code in the same version
of gated, dvmrp/pim boarder router should be working soon after.  also,
we may see signs of pim-dm by the beggining of next year...

- rusty

---

From: Stephen Casner <[email-masked]>
Date: Thu, 18 Sep 1997 12:04:28 -0700 ()

> If this is normal for mrouted, will running PIM be "better", or use

While PIM sparse mode avoids the broadcast and prune, PIM dense mode
is can be significantly worse than DVMRP.  I am not an expert on
either protocol but I believe the following to be accurate: Because
PIM keeps less state, it must wait for a timeout before responding to
the broadcast.  This is on the order of seconds.  DVMRP should respond
on the order of milliseconds for a local network.
							-- Steve

---

From: Manoj Leelanivas <[email-masked]>
Date: Thu, 18 Sep 1997 12:57:26 -0700 (PDT)

=>    
=>    > If this is normal for mrouted, will running PIM be "better", or use
=>    > less bandwidth?
=>    
=>    While PIM sparse mode avoids the broadcast and prune, PIM dense mode
=>    is can be significantly worse than DVMRP.  I am not an expert on
=>    either protocol but I believe the following to be accurate: Because
=>    PIM keeps less state, it must wait for a timeout before responding to
=>    the broadcast. 

I am not sure what you mean here, Steve. If traffic reaches stub LANs,
prunes are sent right away and propagated upstream. The only downside
I can see is that this flood and prune occurs every 3 minutes or so,
while DVMRP could have avoided sending to some nbrs which did not posion
reverse in the first place.

If prunes are lost, (in p2p links where there is a higher chance of
this happening), implementation can retramsmit rate-limited prunes if
unwanted data is still received. For instance, cisco does this.

So I dont see how PIM dense is significantly worse than DVMRP.

-MAnoj

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 18 Sep 1997 13:03:02 -0700 (PDT)

>> is can be significantly worse than DVMRP.  I am not an expert on

    There is a draft that is about to be submitted that does PIM-DM Prune
    Refreshes which fix the periodic flood and prune problem. Plus, PIM-DM
    doesn't have the lost Prune problem.

>> on the order of milliseconds for a local network.

    What do you mean by responding to a broadcast? PIM-DM by default will
    flood-and-prune every 3 minutes. In up to date implementations of DVMRP
    that time is 2 hours. PIM-DM needs to react to topology changes so it
    cannot increase the flood-and-prune timer. Therefore, we are addressing
    the problem with Prune Refresh messages.

Dino

---

From: Stephen Casner <[email-masked]>
Date: Thu, 18 Sep 1997 13:52:53 -0700 ()

> prunes are sent right away and propagated upstream.

Sorry, I should have explained more carefully.  John Zwiebel explained
the PIM-DM operation to me thusly:

    It should have cut off fairly quickly but that depends on the
    number of downstream routers there are.  Each downstream neighbor
    has to first make sure it has no igmp memberships and then that it
    has no pim neighbors, then it can send the prune upstream.  When
    the upstream router gets this prune, it has to wait for a few
    seconds to determine that any other neighbors on that lan won't
    send a JOIN override for the prune.  If there are a large number
    of downstream routers/hops, this delay can add up.

In our network where we have 3 levels of PIM-DM, I observed a delay of
more than 7 seconds (to the top of my xterm scroll buffer) when there
was a stream being sent over the MBone at 1.5Mb/s a few weeks ago.

For a single stub router at the end of an ISDN line, then yes the
delay is less.

I assume that the loss of prune messages occurs fairly seldom, except
those caused by bugs which have since been fixed.  With that
assumption, then in a DVMRP network when the prune times out at the
top node, data begins flowing until it reaches the leaves, and then
prune message flow back up.  The re-prune should complete within one
round-trip time from the top node to the leaves because DVMRP does
require the wait at each level, which I understand to be 3 seconds for
PIM-DM.  In a network at one location, the RTT should be on the order
of milliseconds.
							-- Steve

---

From: Manoj Leelanivas <[email-masked]>
Date: Thu, 18 Sep 1997 14:25:49 -0700 (PDT)

=>    
=>    > I am not sure what you mean here, Steve. If traffic reaches stub LANs,
=>    > prunes are sent right away and propagated upstream.
=>    
=>    Sorry, I should have explained more carefully.  John Zwiebel explained
=>    the PIM-DM operation to me thusly:
=>    
=>        It should have cut off fairly quickly but that depends on the
=>        number of downstream routers there are.  Each downstream neighbor
=>        has to first make sure it has no igmp memberships and then that it
=>        has no pim neighbors, then it can send the prune upstream.  When
=>        the upstream router gets this prune, it has to wait for a few
=>        seconds to determine that any other neighbors on that lan won't
=>        send a JOIN override for the prune.  If there are a large number
=>        of downstream routers/hops, this delay can add up.
=>    
=>    In our network where we have 3 levels of PIM-DM, I observed a delay of
=>    more than 7 seconds (to the top of my xterm scroll buffer) when there
=>    was a stream being sent over the MBone at 1.5Mb/s a few weeks
ago.

Understand. We do not send prune refreshes now. You have this problem
now when you have multiple levels (LANS).

=>    
=>    For a single stub router at the end of an ISDN line, then yes the
=>    delay is less.
=>    
=>    I assume that the loss of prune messages occurs fairly seldom, except
=>    those caused by bugs which have since been fixed.

This may not be always true. If the link is congested, there is high
chance of losing a prune. I dont remember who it was (I think it was
Petri Helinus) who found the problem immediately when we stopped
retransmitting prunes because of a bug.

-Manoj

---

From: Dave Thaler <[email-masked]>
Date: Thu, 18 Sep 1997 18:04:35 -0400 (EDT)

This is not true for PIM-DM.  To quote from the spec (version -05):

> When the prune message is sent, the expected upstream
> router  will schedule a deletion request of the LAN from its outgoing
> interfaces for the (S,G) entry from the  prune  list.  The  suggested
> delay time before deletion should be greater than 3 seconds.

This means that it takes at least 3 seconds per hop for the prune to
propagate upstream in PIM-DM.  Since DVMRP keeps state per neighbor,
pruning happens several orders of magnitude more quickly, as Steve 
pointed out.

-Dave