Subject: Multiple session directories, and multicast address allocation

From: [email-masked] (Ross Finlayson)
Date: Mon, 24 Apr 1995 19:13:06 -0700

A couple of people have asked me how multicast address allocation would work
in a world in which there is no longer just a single, flat session
directory, but instead several different session directories, possibly
(although not necessarily) linked together by subdirectory advertisements as
I outlined in my message last week.  In particular, if there is no longer a
*single* directory that's used for all multicast session announcements, and
if it is not practical to listen in on all possible directories (e.g.,
because you don't know them all), then how can the creator of a new session
*guarantee* that his new multicast address is not already in use by some
other session?

The short answer is that he can't.  In fact, even the *current* (single
directory) scheme can't guarantee that a new group address will not already
be in use elsewhere.  For instance, there might have been a temporary
network partition.  Or the group address might already be used by some
existing application for which SDP isn't used at all.  So, the ability to
monitor previous advertisements in a session directory can reduce the
possibility of multicast address collision, but cannot eliminate it.

Some other things to note:
- Unless there is also a collision in *port numbers*, the only potential
  problem caused by a collision of group addresses would be the delivery of
  extra packets on certain links.
- In IPv6 (with its increased address space), collisions of randomly-chosen
  multicast addresses should be extremely unlikely.
- A collision of both the multicast address and the port number could be
  thought of as being an *accidental* denial of service attack.
  In practice (& especially in the future), applications will need to be
  prepared for the possibility of denial of service attacks of this type.
  (And, regrettably, we can expect there to be more *deliberate* attacks
  than accidental ones.)  In particular, if a multicast session uses
  encryption, then any packets from another, colliding session, are unlikely
  to cause any problem (beyond, perhaps, a security alert).

	Ross.

ps. On a somewhat different subject:  At some point a UDP port for
"session directory" should probably be registered in "Assigned Numbers".
BTW, I notice that 9876 - the port that "sd" is currently using - is not
registered currently.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Apr 1995 08:57:38 +0200

>   extra packets on certain links.

However, this 'small' problem may well render an ISDN link or, worse, a 
transatlantic link inoperational. The worst part is that the user is 
unlikely to notice since the port number protects her.

Given the absence of a feasible alternate address allocation mechanism, 
I would be VERY reluctant to abandon whatever means we do have. It 
should be noted that only session creators would need 

Also, if presentation by applications rather than saving bandwidth for 
announcements (rather small anyway) is the issue, having a category 
field rather than separate multicast addresses would seem to be a 
better idea. This also avoids the problem of having to repeat 
announcements in different groups ('crossposting').

Henning

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 25 Apr 95 10:56:44 +0100

>network partition.  o
right, but if the partition partitions the directory the same way as
it partitions groups, then there is a homomorphism of users and
meta-coinference information....i.e. no conflict

 >  extra packets on certain links.

err, yes, but this is sort of a bad thing...

 >  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

there is a conference session name space which should be hierarchical.
but the directory tools should have a flat address space for
coordinating it....we will have other hierarhical tools for managing
traffic (ttl/threshold, administrative scoping, even hierarchical
multicast addresses or multicast IGP/EGP split....)

in fact, a Path Vector reverse path multicast, based on RMP and BGP
combiend would make a jolly good inter-domain multivcast routing
scheme., but thats for another list...

 jon

---

From: "Jon P. Knight" <[email-masked]>
Date: Tue, 25 Apr 1995 12:09:21 +0100 (BST)

On Tue, 25 Apr 1995, Jon Crowcroft wrote:
>  Ross Finlayson wrote:

Ah but what if it doesn't partition the directory in the same way as it
partitioned the groups?  That's the sort of thing that was happening last
night when the MBONE was going loopy due to the Cisco unicast route flood
into the MBONE routing tables.  For example, I was trying to participate
in an RMP debugging session with Paul Harrington at St Andrews and Todd 
Montgomery at West Virginia University.  I could sometimes see both of
them and Paul could see me but not Todd while Todd could see me and not
Paul.  If either Paul or Todd started an annoucement in sd in this case I
could see it.  Just think what would happen to me if both of them started
sd announcements on the same <group address,port> pair but with different
media selected.  I could launch both and they'd collide horribly.  And it
gets worse because this particular MBONE failure mode appears to be
dynamic in that who could see and hear who changed over time.  Nasty.

Jon

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon Knight, Research Student in High Performance Networking and Distributed
Systems in the Department of _Computer_Studies_ at Loughborough University.
* It's not how big your share is, its how much you share that's important *

---

From: Mark Handley <[email-masked]>
Date: Tue, 25 Apr 95 13:09:05 +0100

>possibility of multicast address collision, but cannot eliminate it.

The question here is one of scalability of address allocation.
Currently, sd's allocation algorithm (informed partitioned random
multicast address allocation (IPRA)) scales pretty well, but it does
so mostly because it's informed, not because of the random part. The
partitioning is not useful unless the algorithm is informed.

One of the big holes with the current implementation is people who
start up sd and immediately announce a session - then they're using
partitioned random address allocation on a (relatively) small
partition, and the chances of a clash are comparatively high.  If an
sd is kept running, or can be updated on startup from someone else's
cache, then IPRA works pretty well.

As for temporary partitions - partitions are common, but long lived
ones are rare.  sd's timeouts are fairly long (a few hours), so it's
rare that sessions timeout.  Even so it's possible that sd caches can
keep track of sessions that recently timed out and then don't allocate
those addresses.  

The chances of a clash due to network partitioning are proportional to
the number of conferences announced during a partition (ie
proportional to the rate of announcement, and the length of
partitions).  That's where the random part of IPRA comes in.

The chances of a clash due to partitioning the announcement space
using sub-directories and not alllocating addresses to each
sub-directory are propertional to the number of announced sessions in
subdirectories.  The address space currently used for sd (16 bits) is
not large enough for the random part of IPRA to bail you out here.
Yes, there's more address space available, but do we really want to
use it this way?

Also, if we don't partition the announcement space, sd can discover
any clashes when a network partition goes away.  Then it's possible to
design automatic recovery mechanisms to change the announcement before
the session starts (assuming it's announced in advance).

I do not believe we should adopt an approach which will compromise the
scaling of sd's address allocation.  If we believe that a single
announcement address (or an announcement address per administratively
scoped region) received at all receivers will not scale sufficiently,
then we should be looking at approached based on networks of servers
which are contacted to do address allocation (ie, make the allocation
*mechanism* hierarchical).  Van has suggested this is the way to go in
the long term.  However, in the medium term, I believe the current
mechanism (modified for fast update on tool startup and for
administrative scoping) will scale better than the Mbone itself will
cope with the conferences involved.

The user interface side of things can be improved by a hierarchical
category field, without changing the distribution mechanism.
This is also useful for SDP announcements by email, WWW, etc.  

Mark

---

From: [email-masked] (Deborah Estrin)
Date: Tue, 25 Apr 1995 09:28:40 -0700

In-Reply-To: Your message of "Mon, 24 Apr 95 19:13:06 PDT." <[email-masked]>
   From: Jon Crowcroft <[email-masked]>

    jon

And it is a fairly accurate description of PIM when the underlying
unicast protocol is BGP :}

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 25 Apr 95 17:45:04 +0100

>unicast protocol is BGP :}

so how do you pass path vector metrics through a non PIM/BGP net, when
connecting multiple DVMRP clouds together?

 jon