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

From: Dave Thaler <[email-masked]>
Date: Fri, 27 Nov 1998 13:56:24 -0500 (EST)

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

---

From: Mark Handley <[email-masked]>
Date: Fri, 27 Nov 1998 10:57:11 -0500

>an address in under ANNOUNCE-WAIT? i.e. request-receive c.f.

You need a local server that implements AITU.  You're also best to
predict when you're going to need addresses and request a pool of then
in advance.  When you can't predict, a server implementing AITU will
normally give you some addresses immediately.  However, if you
surprise the server with a sudden demand for a large number of
addresses, then you'll just have to wait.  

For your application and most other similar applications I've heard
described, pre-allocating a relavtively small cache of addresses is
going to be your best solution.

Cheers,
	Mark

---

From: Jason Morphett <[email-masked]>
Date: Fri, 27 Nov 1998 09:55:48 -0000

Hi Ross,

Agreed, the draft does show an 'abstract service interface', but it
doesn't illustrate examples of use mapped down to service types.  I know
that wouldn't be the remit of the draft, but I agree with Mikhail that
it would be useful to identify (by service type) where MALLOC can be
used. 

The reason for my '2 penneth worth' here is as follows...

Thanks in advance,

Jason

    > -----Original Message-----
    > From:	Ross Finlayson [mailto:[email-masked]]
    > Sent:	26 November 1998 21:41
    > To:	Mikhail Smirnov
    > Cc:	[email-masked]; [email-masked]
    > Subject:	Re: malloc service model (was: MDHCP review)
    > 
    > At 01:23 PM 11/26/98 +0100, Mikhail Smirnov wrote:
    > 
    > >Do we have any document fixing malloc's current 
    > understanding of what
    > >"the needs of the folks that deal in multicast services" 
    > are? I mean how
    > the group
    > >understands what are the requirements, usage scenarios, 
    > limitations, etc.,
    > >basically what is the malloc service model?
    > 
    > Yes, the MALLOC "abstract API" document - 
    > "draft-ietf-malloc-api-04.txt" -
    > describes the "abstract service interface" for MALLOC.  
    > This may be what
    > you're looking for.
    > 
    > I and the rest of the MALLOC working group would be 
    > interested in any
    > specific suggestions you may have as to how this document 
    > might be improved
    > to better meet the needs of multicast applications.
    > 
    > 	Ross.
    > 
    >