Subject: Multicast address allocation - initial comments

From: Ross Finlayson <[email-masked]>
Date: Sat, 29 Nov 1997 22:50:30

Mark et al,

I've just read the document "The Internet Multicast Address Allocation
Architecture" (http://north.east.isi.edu/malloc/malloc-arch.ps).

Overall I think this is good stuff, and definitely in the right direction
(although the title's a bit presumptious - at this stage it should really
be "*An* Internet..." :-).  It will definitely be valuable for the
prospective WG to define an intermediate protocol ("AAP") that provides a
single, well-defined layer sandwiched between (i) applications that wish to
allocate multicast addresses, and (ii) any courser-level allocation that
may be done higher up in the network (e.g., for inter-domain multicast
routing).  I see this as being one of the two primary goals of the WG.

One point where I suspect I may disagree with the authors concerns the
lowest-level protocol - the one that applications would use to communicate
with AAP.  I view such a protocol - "MDHCP" or otherwise - as being purely
optional.  Nothing should preclude implementations from using some other
mechanism to interact with the AAP layer.  For example, some implementors
may wish to include an AAP module (what you call a "MAAS server") as part
of the OS - perhaps just as a shared runtime library.  In this case,
applications would interact with the AAP layer using procedure calls only -
not IP.

[In multikit, for example, I'll likely have an AAP implementation built in.
 Then the user will be able to inspect the current set of address claims
inside a directory window - just like regular session announcements!]

I believe the second primary goal of the WG should be to develop an *API*
for applications to use for allocating/deallocating multicast addresses.  I
realize that the IETF doesn't usually produce APIs, but there are
exceptions - e.g., the socket API for IPv6.  Multicast address allocation
is another situation where it would be valuable for us to produce an API -
for the C language at least.  This would allow application writers to not
have to worry about the particular platforms on which their applications
will run, while giving the implementors of these platforms flexibility in
how they interact with AAP.

With these two goals - AAP and an allocation/deallocation API - being
primary goals of the WG, secondary goals would include:
3/ 'Back end' protocols that AAP would use for courser-level allocation.
Right now you're talking about just one of these - MASC - although it's
conceivable that down the road there might be more (e.g., if some
completely new inter-domain multicast routing protocol were to come along
in addition to BGMP).
4/ One or more protocols - sitting between the applications and AAP - that
could *possibly* be used to implement the API.  For example, MDHCP.

In any case, the development of a standard multicast-based intermediate
allocation protocol - "AAP" - will be a valuable contribution.  I haven't
yet seen the details of an AAP proposal, so my next comments are somewhat
"shooting in the dark":

- Because multicast address allocation is something that will be done by
potentially untrusted applications, it's important that the AAP layer be
able to handle an (intentional or unintentional) denial of service attack,
in which an application sits in a loop, allocating one address after
another (but not reclaiming them).  (Come to think of it, it's not just
applications that might be 'byzantine'; other AAP modules might be as
well.)  AAP needs to be able to deal with this.

- An AAP module should (perhaps optionally) be able to 'pre-claim' a small
set of addresses in advance of any request from an application, so that an
application's address allocation request can - in the common case - be
satisfied immediately.  (It's conceivable that some future applications may
wish to be able to allocate multicast addresses very rapidly, and, if so,
we should try to accommodate this with "best effort".)

- In the past, Mark has noted the desirability of having AAP be similar to
SAP, especially wrt. the definition of security fields in the packet
definition.  I think this is a laudable goal.  In fact, I feel we should be
even *more* ambitious in defining common formats for a general "multicast
data architecture".  I may have more to say on this subject later on...

	Ross.

---

From: Mark Handley <[email-masked]>
Date: Mon, 01 Dec 1997 10:28:55 -0500

>applications would interact with the AAP layer using procedure calls only -

Yes, I agree with you here.  I would think that an application like
sdr might conceivably speak AAP directly.  However we also must bear
in mind that many applications (or even hosts) will want to start up
and grab an address immediately.  These apps need a well defined
mechanim to request an address, and that is what this lowest-level
protocol is intended to provide.

More on AAP later today...

Mark

---

From: Mark Handley <[email-masked]>
Date: Mon, 01 Dec 1997 10:50:19 -0500

>More on AAP later today...

I've put a link to a rough AAP draft from the MALLOC page:
http://north.east.isi.edu/malloc/

Nothing in this draft is final - consider it a brain dump!

The ASCII version is pretty poorly formatted - use the Postscript
version if you can.  If anyone has a reliable way to get good
formatted ASCII from latex I'd be interested :-)

Cheers,
	Mark

---

From: Ross Finlayson <[email-masked]>
Date: Mon, 01 Dec 1997 13:51:06

>protocol is intended to provide.

But let's not forget that the applications that wish to allocate multicast
addresses can be regular, "mom and pop" applications written by average
programmers - not just networking-savvy applications like "sdr" written by
gurus :-)  I hope you're not suggesting that every J Random Application
Developer who wishes to allocate a multicast address do so by writing his
own MDHCP client.

Because we're providing a mechanism that application developers will use,
we have to accept the fact that - in this one particular case - we're
venturing beyond the pure world of OS/router network interactions.  To
rephrase your statement above: Applications need a well defined *interface*
to request an address.  That's why I suggest that this WG define an API for
multicast address allocation/deallocation.  At the same time, it's
inappropriate for us to mandate how this API will be implemented,
especially in situations where this can be done so using intra-node
communication only.

If we accept that a node that performs address allocation using only its
own AAP implementation is completely interoperable (from a protocol point
of view), then we also have to accept that the use of MDHCP (or whatever)
is optional.

(As an aside, I think the point about applications wanting "to grab an
address immediately" is a red herring.  You already note that after an
address claim is made, there's a delay - at the AAP level - to ensure that
noone else has claimed it.  Thus, a client that uses MDHCP is going to
experience a delay at least as long as one that invokes the AAP level
directly.  In any case, as I noted in my last message, I think we should
investigate having the AAP level 'pre-claim' addresses, to reduce the
client latency in the common case.)

	Ross.

---

From: Dave Thaler <[email-masked]>
Date: Mon, 1 Dec 1997 17:25:44 -0500 (EST)

> >>optional.
[...]

Yes, and conversely, other people may have no need for AAP (for example,
if they only have one MAAS in their domain, which speaks MDHCP and MASC).

> inappropriate for us to mandate how this API will be implemented,

I agree with the above.

> I think we should

I believe the current AAP draft does allow this, since several people have 
asked for it.

-Dave

---

From: Liming Wei <[email-masked]>
Date: Mon, 1 Dec 1997 18:09:00 -0800 (PST)

> From: Mark Handley <[email-masked]>
> 

Mark and gang,

I skimmed through your architecture draft and found it more coherent
than an average brain dump :-). However, the following are some
comments from my perspective:

1) The address allocation efficiency seems to be suseptible to
   an avalance of address consumption at high usage levels
   of the multicast address space.

   A MASC node always needs to request more addresses from the higher
   layer of the hierarchy, _before_ its own pool is depleted.
   This means when the global address space is "near" depletion,
   whoever requested more aggresively would have an advantage
   over those conservative ones. This property may accelarate
   the consumption of the available address space, and may lead to
   premature adress starvation at a low address space usage point. I
   think the  architure needs to take this into consideration.

2) The concept of address lifetime is not clear. It is not clear what
   the actions are for those addresse still in use by an application,
   while their lifetimes are exceeded. Will those addresses be
   allocated to some other MAAS servers ?

   To avoid this problem, it may be beneficial for a MAAS server to
   hold on to addresses it has allocated. But the trouble is it can not
   know how long is sufficient unless the application explicitly
   "releases/returns" the address. 

3) With respect to the timeliness in getting an address, the wording
   makes you under suspecion for trying to declare a lower bound
   sufficient for all possible multicast applications.

   The ideal situation should be such that the delay a client gets
   an address is only affected by the implementation, speed of
   light etc, as opposed to a limitation imposed by the architecture.

-Liming