[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Simple Multicast - building a case for a BOF or WG



As I said before, (and Hugh just
pointed out) you can provide for multiple senders with unidirectional
trees in two ways (encapsulate to the Root, or make multiple trees).

You can also do anything with bidirectional trees that you can
with unidirectional trees.
You can enforce single sender, or a limited set of senders.
So I think we are, at this point in time, are putting too much emphasis
on this particular issue. It's too early to make a decision on this
at this time. But given Dave's postings, I think someone should answer
some of the questions he's raised.

Bidirectional forwarding isn't intrinsically more difficult than
unidirectional forwarding; bridges have been doing it for years.

If there are n senders, and you support that with n unidirectional
trees, there is n times as much state. n times as many trees to
keep in your forwarding table. n times as many keep-alives, or whatever
else is being done to maintain a tree, as if you support it with
a single bidirectional tree. Also, it is more complex for the receivers,
since they have to know all the potential senders they'd like to
receive from so they can join all those trees.

If there are multiple senders, and you support that with encapsulation to
the Root, then the Root is a hotspot, and it costs more for the network
because of the cost to deliver the packet from the sender to the Root.

A lot of people believe that multicast applications we haven't even
dreamed of will take root if we provide a nice scalable general mechanism,
so looking at applications that are currently deployed might be shortsighted.

But I still think it's valuable to consider possible applications.
Various possible multisender aplications: multiparty games, chat lines,
data collection and sharing (i.e., the data collectors want to hear from
each other not all send to a single collection point, because
for that unicast would be a better solution),
Hello protocols so a group of things can keep track of which
of them are alive, routing control traffic distribution for border
routers to communicate with each other across an area, conferencing.
Recently bidirectional PIM was introduced, indicating I'd assume both that
it's not that hard to implement and that there is some customer demand.

I'd hope this mailing list would be a good place to calmly discuss technical
pros and cons, and I think we should be carefully considering
engineering tradeoffs before we start making decisions.

One potential cost of bidirectional trees (using an 8-byte group ID
so that address allocation is per Root, which is I think the spirit
of this mailing list)
might be whether routers have to consider
8 bytes or 12 bytes when forwarding data packets. Of course, considering
12 bytes isn't that much harder than 8 bytes (other than worrying
about current implementations, which is an important but
orthogonal issue), but it's still
interesting to consider which models require which.
The feature of having receivers
choose their own set of senders they want to receive
from, and want routers to filter for them, (e.g., IGMPv3)
in an 8-byte group ID world
would require 12 byte forwarding
whether you're using bidirectional trees or unidirectional (where the
Root encapsulates and forwards from selected sources),
since you'd have to look at the 8-byte group ID (Root, multicast ID), and 
source. Of course if you instead build a separate tree per sender then
you'd only need 8 bytes, but you'd have more trees, which involves
some method of having receivers know all the groups they need to join
in addition to requiring more state in the network (for n trees).
If you are willing to live with groups in which either any member
is allowed to send or only the Root is allowed to send, then you can use
8 byte forwarding with bidirectional
trees, since routers could accept packets based on incoming
port and 8 byte ID in the single sender case, and ignore the source
address in the "all-senders allowed" case. To really do access control
you might want to have cryptographic protection, in which case the filter
would be based on an authentication field in the packet.

Another technical issue I'd suggest we discuss is backward compatibility.
Various possibilites are to do these models with restricted functionality
until routers and end systems upgrade (for instance, by doing single-sender
trees, but with hooks to allow for bidirectional in the future, or by
enforcing for a time that the multicast address be unique), have
gateway devices that can connect "old-style" and "new-style" trees, etc.

I tend to like to make lists. The lists I'd suggest making are "potential
applications for multisender multicast", "costs of bidirectional trees",
"pros and cons of various data packet encodings for SM", "methods
of migrating"

Radia