Subject: Is the rate-limit *queuing* useful?

From: "Bill Nowicki" <[email-masked]>
Date: Thu, 28 Mar 1996 10:47:38 -0800

The recent 3.x versions of mrouted have a feature that allows
rate limits, so multicast traffic does not interfere with
unicast traffic (sort of the opposite of RSVP).  This is
ubdoubtedly a useful feature. However, the current implementation
includes a two-dimensional array used as a queue for each
virtual interface. The IRIX 6.2 port happens to have a
multi-processor locking bug in this queue implementation.

I am wondering if it is worth fixing the locking bug, or
if we should just take this code out. Is it really better
to queue up packets and delay them even further when a
link gets over-utilized? Perhaps you might as well
just drop them, since delayed real-time packets are
not very useful anyway. And in the long term we want
priorities based on who made reservations, right?

Does anyone know the rationale behind this queue?
It looks like the idea was to try to get audio through
even when someone is sending too much video. Does it
work in practice? That is, does the audio still sound
reasonable when this queue kicks in?

By the way, the reason users seem to be using the rate
limit is to limit DVMRP routing loops. Are we the only
ones who see these loops? An FDDI to FDDI multicast
routing loop can melt down a entire campus real fast.

Thanks, Bill Nowicki
	Silicon Graphics

---

From: Bill Fenner <[email-masked]>
Date: Thu, 28 Mar 1996 11:59:12 PST

>reasonable when this queue kicks in?

I use "rate_limit 100" on my ISDN line to home, and audio still sounds
crisp and clear even with 128kbps of video.

  Bill

---

From: Steve Deering <[email-masked]>
Date: Thu, 28 Mar 1996 16:10:15 PST

> not very useful anyway.

Bill,

The queue allows some burstiness in the multicast traffic, while still
ensuring that the specified max rate is not exceeded over time (it's the
bucket in a token-bucket traffic limiter).  Such burstiness might occur,
for example, when some number of voice samples get bunched together in a
queue in a previous router.  Always throwing away the second of two
back-to-back multicast packets to stay within a configured bandwidth
limit would likely be much more harmful to perceived quality than the
bounded delays that the queueing can introduce.  I hope you were being
sarcastic when you said that "delayed real-time packets are not very useful
anyway".  If not, perhaps you do not understand how vat works.

> And in the long term we want priorities based on who made
> reservations, right?

As soon as possible, we want routers to do something more sophisticated
than FIFO queueing, in order to prevent any one source from monopolizing
a link.  As soon as the routers start doing something like RED, we will
gladly rip out the multicast rate limiter.  It'll take a lot longer before
the infrastructure (technical, administrative, fiscal, etc.) is in place
for doing end-to-end reservations over the heterogenous Internet, and
even if it were in place, it is unlikely that we will want to insist that
all multicast traffic be reservation based.

> reasonable when this queue kicks in?

The purpose of the queue is to allow burstiness in the rate-limited traffic.
The purpose of the priority dropping, when the queue overflows, is to
favor certain packets (e.g., audio) over others (e.g., video), when the
combined traffic exceeds the rate limit.  Yes, it does work.

> limit is to limit DVMRP routing loops.

That's the first time I've heard that.  It was certainly not the motivation
for adding the rate limiter, and I was not aware that people are encountering
DVMRP routing loops.  (There have been one or two reports of loops caused by
sticking a LAN bridge between a pair of previously separate subnets, and not
telling mrouted about the presence of the additional subnets, but that is
dealt with by proper mrouted configuration, not by rate limiting multicast
traffic.)  As far as I know, most mrouteds are running without any rate
limit, and do not suffer from DVMRP loops.  Perhaps there's something unique
about your topology or configuration that reveals a looping problem in DVMRP,
and if so, I am very interested in tracking it down and fixing it.  Bill
Fenner and I will be happy to work with you to try to diagnose your problem.

Steve