Subject: Re: Multiple session directories, and multicast address allocation

From: [email-masked] (Ross Finlayson)
Date: Tue, 25 Apr 1995 17:36:16 -0700

Henning S. writes:
> Given the absence of a feasible alternate address allocation mechanism, 
> I would be VERY reluctant to abandon whatever means we do have.

Just to make it clear - I was definitely not suggesting that a node that
cons's up (e.g., using "IPRA") a multicast address for a new session should
ignore any existing addresses that it knows about.  On the contrary.
My main point was that even the *existing* "sd" scheme does not prevent the
possibility of group address collision.  (We've already discussed how both
network partitioning and "sd"-startup can cause this.  Yet another example
is a session whose scope gets increased subsequent to its original creation.)

Jon C. writes:
> >- In IPv6 (with its increased address space), collisions of randomly-chosen
> >  multicast addresses should be extremely unlikely.
> 
> but if we start using multicast addresses hierarchically, we will use
> up the address space a lot faster.....and as the bandwidth goes up,
> and we get privacy tools, people wil luse sessions for long term work
> groups in larger and larger numbers
> 
> i think engieerign something for less global consistency is not such a
> good move unless we can think of good other reasons

Again, the potential for inconsistency has always been there; it's just that
multiple session directories increase the probability of encountering it.
If this forces us to remove our heads from the sand and pay closer attention
to how we might deal with this, then that's A Good Thing.  (Note also my
earlier comments about denial of service attacks.)
 
> there is a conference session name space which should be hierarchical.
> but the directory tools should have a flat address space for
> coordinating it....

In this discussion, it's important to keep in mind the distinction - that
you've noted - between (i) the mechanism that's used to announce/advertise
sessions, and (ii) the mechanism by which multicast addresses are allocated.
SDP is a protocol for (i): session announcement/advertising.  It's also
been pointed out that it can be convenient (for administrative and/or
scaling reasons) to use SDP over directory groups other than the one that's
currently built into "sd".  (To follow on from your scenario above, one can
imagine corporations conducting their internal business over the global
Internet (using encryption, of course); they are likely to want their own
session directory, in addition to the public one(s).) 

Regarding (ii) - multicast address allocation - a variety of schemes are
possible: static/dynamic, hierarchical etc.  Now, it turns out that one very
useful dynamic allocation algorithm ("IRPA") is built into the "sd"
application (the initial implementation of SDP).  This particular algorithm
works well because "sd" uses just a single directory group, and so can
easily keep track of every announcement.  (But it should be noted that even
in "sd", the use of this algorithm is optional; nothing prevents you from
typing in an arbitrary group address that you may have allocated by some
other means.)  People have also pointed out - correctly - that if SDP were
run over multiple directories, using this same algorithm (& the same address
range) on each, then the probability of address collisions is increased.
So this will probably need to get mentioned in the documentation somewhere
- e.g., we might mention the use of "IRPA" from a specified address
range, but recommend this only for the public 'root' directory.

Plus, as Mark H. pointed out, other address allocation mechanisms
(e.g., hierarchical, or maybe IRPA-like allocation of *chunks* of address
space) may emerge in the future.  So let's not get too hung up about 
multicast address allocation; it's really a separate issue.

	Ross.