Re: [kNT] Multicasting [was -- akamai]

[Dickson Loh <dickson@xxxxxxxxxxxx>]

Hi Scott,

I suspect Nick was referring to the content in the servers being 
"multicasted" to the other servers in the CDN, rather than having each one 
of them using ftp, WebDAV, etc. to get the content.

This will save on the bandwidth so long as
- only differential updates are being multicasted, else
- the number of servers to be multicasted to will need to exceed the number 
of times the content needs to be distributed.

Of course, this is assuming optimal bandwidth and available multicast 
capability. In reality, having a tool to monitor the internet traffic 
conditions between the various servers will help make the distribution of 
the content more efficient.


Dickson.




At 10:12 AM 11/9/2001 +0000, you wrote:
> "urn:schemas-microsoft-com:office:office" xmlns:w = 
> "urn:schemas-microsoft-com:office:word" xmlns:st1 = 
> "urn:schemas-microsoft-com:office:smarttags">
>
> Well, it *is* getting a little bit technical...   Daniel, maybe there's 
> scope for a 'techie' list?
>
> But... isn't the problem with multicast two-fold?  First one is technical 
> -- all intervening routers need to be multicast enabled, and if the 
> operator doesn't control the end-to-end network then that might be [is] 
> difficult to co-ordinate.  Second is financial -- if the operator is paid 
> by connectivity required [megabits/second per month], or gigabytes 
> transferred, what is their incentive to reduce the amount of 
> traffic.  After all, we're hearing there is a glut of fibre and so sending 
> 1000 identical streams of 300 k each is a good way of being paid to fill 
> it... isn't it?
>
> Well, no it's not.
>
> a] because it is so manifestly inefficient and unreliable that content 
> owners are looking for something better to ensure reliable service they 
> can charge for
>
> b] operators themselves have to pay for, or lay, their own dark fibre to 
> be filled with these identical streams so that reduces their margins
>
> I believe that some of the more imaginative operators are implementing 
> multicast and mcast peering but I suspect it will be a long while before 
> it gets really close to the 'last mile' router.
>
> But I don't understand Nick's comment about "making content multicastable" 
> -- surely the actual content is irrelevant as long as it is a stream [like 
> a TV channel] rather than VoD?
>
> Does any content owner/broadcaster have a live multicast operation in use 
> 24*7?  I would be very interested in making contact.
>
> Scott