To expand on this in response to comments in the meeting:
1. Design for Deployment
Anyone who wants to change the Internet infrastructure needs to consider the problem of deployment as their single biggest concern. The Internet now has a billion users. Changing the Internet, even in a small way takes a huge amount of time and effort.
Anyone who wants to rely on one of the big platform providers to deploy an infrastructure needs to talk to some of the IETF participants who work for those companies talk about their own difficulties getting their own company to adopt their own proposals. Such decisions are made by product managers, not engineers.
In particular some people need to stop thinking that anyone other then themselves has a duty to evangelize for their work product. You build a product for the Internet you have, not the Internet you might want. Getting an RFC through the IETF is the beginning of the process, not the end.
I would like to see a deployment statement included in all RFCs and architecture statements that require infrastructure changes. This should state why the authors think that the parties who are required to make changes have an incentive to do so.
2. There has to be a path from A to B
A lot of IETF protocols suffer from the problem that they work well in the state where they are ubiquitously deployed but there is no practical path from where we are to where we want to be.
Often there are people who consider preserving the architectural purity of the design to be more important than developing a path from A to B. For several years I have been telling people that we have to embrace NAT if there is going to be the slightest chance of deploying IPv6. In the plenary we are going to have a demonstration of why that is essential, the IPv6 only Internet worketh not without at least two NAT conversions being built into the stacks.
3. There has to be an economic incentive to travel the path from A to B.
Ten years later the multicast world is still failing to make an economic case for deployment. I cannot obtain multicast on my home network and my provider has no plans to support it. And even if it did I have no reason to expect that my local network would support it.
That is one reason I prefer the application level cache approach, there are no infrastructure preconditions. It can be deployed in the current Internet infrastructure.
But note that as PAF points out, once you have an infrastructure of caching application layer distribution points you can use multicast to distribute from the upstream feed.
One approach here would be for the multicast group to attempt to tell the cache infrastructure group that they are required to make multicast a precondition for deployment. Unless the cache group is able to refuse this will inevitably kill the killer application.
Now consider what happens if the cache distribution points are designed so that they will function on the Internet as is but allow use of multicast as an optimization. Suddenly the ISPs have an incentive to deploy multicast - it has a dollar return and its dollars that the ISPs care about saving, not packets.
I make a much longer version of this argument in my book, The dotCrime Manifesto. The principal problem in securing the Internet is not design of the cryptography. Crypto is important and useful of course but crypto alone is not enough. There has to be a business model for deployment and a business model for use.
We now have a conference series on the economics of computer crime. Considering the economics of deployment is a critical part of deploying the solution. Ross Anderson has some resources on this topic.
-----Original Message-----
From: ietf-bounces@xxxxxxxx on behalf of Hallam-Baker, Phillip
Sent: Sat 08/03/2008 9:18 PM
To: Jeroen Massar; Patrik Fältström
Cc: IETF discussion list
Subject: RE: Was it foreseen that the Internet might handle 242 Gbpsof trafficfor Oprah's Book Club webinars?
The problem with multicast in this application is that it only works if all the clients are accepting the same data stream and viewing it live.
That's not how people tend to view Web video, there might be 50% of the crowd watching it as Oprah speaks but the rest are likely to be time shifted from a few secs to hours or even days.
An application layer architecture with in built caching would be more efficient. Similar to the peer to peer schemes in use today but with the caches installed by the local ISPs who are complaining about their bandwidth getting swamped.
> -----Original Message-----
> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On
> Behalf Of Jeroen Massar
> Sent: Saturday, March 08, 2008 5:43 PM
> To: Patrik Fältström
> Cc: IETF discussion list
> Subject: Re: Was it foreseen that the Internet might handle
> 242 Gbps of trafficfor Oprah's Book Club webinars?
>
> Patrik Fältström wrote:
> [..]
> > P.S. And if multicast is in use, or unicast or some
> othercast, that is
> > from my point of view part of the "innovation" the ISPs have to do
> > (and will do) to ensure that the production cost is as low
> as possible
> > so that their margin is maximized.
>
> I actually see a bit of a problem here as multicast would
> lower the usage of links, as such, they can't charge as much
> as with link that is saturated with unicasted packets. Thus
> to lower the use in the internal network one would use
> multicast, but the client would then still have to get
> unicast so that for every listener they are actually paying...
>
> Greets,
> Jeroen
>
>
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf