Re: Proposed charter, please comment

[Marshall Eubanks <tme@21rst-century.com>]

"Maciocco, Christian" wrote:
> 
> Comments below.
> Hilarie
> 
> > -----Original Message-----
> > From: Hilarie Orman [mailto:HORMAN@novell.com]
> > Sent: Friday, January 26, 2001 11:07 AM
> > To: markday@cisco.com; condry@intel.com; jmartin@netapp.com;
> > cdn@ops.ietf.org; premium@pavilion.co.uk
> > Subject: RE: Proposed charter, please comment
> >
> >
> > I'll step on the edge of the multicast rathole.  Suppose there are
> > a small set of requirements for utilization of multicast transport
> > (registration, join/leave, send/receive) and a small set of
> > requirements for the multicast (reliable, scalable to m/n
> > senders/receivers, mean throughput, mean latency).  Then
> > the documents could merely reference these in a few
> > places ("surrogate MUST attempt to join multicast
> > group if advertised in content description"; "CDN
> > MUST contain at least one router capable of
> > supporting the multicast protocol in the peering
> > agreement").
> >
> > I assume that the primary benefit of multicast is
> > reduced bandwith requirements, and the benefit is
> > proportional to the amount of data.  One might set
> > a limit - if the expected amount of data exceeds
> > M megabytes/month to more than k sites, then
> > we'd expect a multicast distribution scheme to
> > be employed?
> >
> 
> CDI will deal with inter-domain communication, and as we know the
> state of inter-domain multicast support, should we impose this
> in the requirements?
> 
> > IF the discussion could be kept a high level, without
> > imposing any specifics of particular multicast solutions
> > on the architecture, would that be an acceptable
> > approach?
> >
> > Hilarie
> ><snip>
-- 
Hello;

Here are two suggestions for multicasting - one to benefit the CDNs, one
to improve streaming.

One thing you can to with multicast is set up intra process communications
without registering group members (explicitly - the routers do it for you).
So, it might be useful to set up a multicast many to many communications 
group between CDN "nodes" - communicating capabilities or status, say.

Given the (current) state of multicast enablement of the commodity
Internet, this could be done by using tunnels between the nodes, or even
a VPN. As this internode communication would be low bit rate, then 
this would just take a link between a given node and any other, in the
following fashion :

For a new node A

1.) If the node is on the multicast enabled Internet, join the
comminication group, G.
2.) Else, find the next "nearest" node, B
3.) Do a handshake and, if agreeable, set up a tunnel to A. Join group G
and stop.
4.) Else, find the next nearest node. Go to step 3

Another thing that comes to mind is to use CDN nodes to facilitate
multicast streaming.
Suppose that a ISP, X, is multicast enabled, but there is no MULTICAST
connection between 
X and the desired source, S. Then S could tunnel to a CDN node that IS
attached to X, or
to a multicast enabled network attached to X. The protocol should
include a means
to advertise the willingness to accept or extend such a tunnel 

At IETF 49, Tony -Ballardie - ballardie@dial.pipex.com, presented a
draft proposal to do this, except
not specifically for CDN's. This ability
dynamically creating tunnels for multicast connectivity would
SUBSTANTIALLY increase
the ability to extend multicasting, as edge ISP's would not necessarily
have to
multicast peering to accept multicasts. We here at MCT have set up
tunnels to do this,
but with manual configuration. 


                                   Regards
                                   Marshall Eubanks

 
   Multicast Technologies, Inc.
   10301 Democracy Lane, Suite 201
   Fairfax, Virginia 22030
   Phone : 703-293-9624          Fax     : 703-293-9609     
   e-mail : tme@on-the-i.com     http://www.on-the-i.com