Subject: Re: malloc service model (was: MDHCP review)

From: "Cheng-Yin Lee" <[email-masked]>
Date: Tue, 01 Dec 1998 17:36:20 -0500

Jason,
Or alternatively, you could take a look at Simple Multicast. It doesn't have
the address allocation  problems you listed below.
OTOH, i'll be interested to hear about its other shortcomings :-) (wrt MALLOC
in particular)

thanks,
cyl
p.s if you're interested, the latest Simple Multicast draft-01 should be
accessible on the IDMR Mailing List archive.

Dave Thaler wrote:

> Just to add to what Mark said...
>
> > As an application developer, I need to allocate (potentially) a lot of
> > multicast addresses with the lowest possible latency in doing so.  I
> > don't want to 'hoard' X addresses and use X/10 of them for 50% of the
> > time as that's not utilising the available address space.  I need to be
> > able to request and receive addresses in the *least possible time* and
> > use them for anything varying from a few seconds to (potentially) hours.
> >  But, the key factor is latency in allocation.
>
> Right, this is typical.
>
> > Reading Mark Handley's AAP proposal.  It states that I may have to wait
> > for anything up to ANNOUNCE-WAIT (at best) before I get the address.
> > How do the current offerings from MALLOC allow me to request and receive
> > an address in under ANNOUNCE-WAIT? i.e. request-receive c.f.
> > claim-collide?
>
> My opinion is that servers should always try to keep a small pool of
> addresses reserved for allocation (the AITU message that Mark mentioned).
> Anyone requesting a small number of addresses can then get them
> immediately, with no advance notice.
>
> If you ask for a large number of addresses (more than the small pool
> size), then you have to wait.  If you ask for a really large number,
> you may not get them at all unless you ask for them enough
> in advance of when you need them.
>
> (You may be able to get a hotel room at the last minute, but
> if you're trying to reserve a block of 1000, you'll
> definitely be out of luck.)
>
> > BTW, the application is a large scale virtual environment using
> > multicast addresses for 'groups' of inhabitants to use for
> > audio/text/video etc.?  Addresses are handed out as groups form (a
> > highly dynamic activity).
>
> This sounds like a typical DIS-like scenario.  You can either
> a) allocate groups one-at-a-time on demand, or
> b) pre-allocate a large block, and use some application-layer
>    mapping function to decide which one of the large block to use.
>
> The former is more efficient in terms of space utilization.
> The latter is useful if groups are associated with things in
> the virtual environment (e.g. rooms).
>
> -Dave

--
[email-masked]