Subject: [alto] Comments on draft-weaver-alto-edge-caches-00

From: Wes Felter <[email-masked]>
Date: Fri, 6 Mar 2009 22:22:45 -0600

Localization was getting a little over-hyped so I like this document.  
Here are some suggestions:

I didn't see any mention of traditional ISP-operated HTTP caches (not  
CDNs), their discovery protocols (WPAD), and their legal status. These  
may have fallen in popularity in recent years as the cost of transit  
has dropped, but clearly some ISPs still use them (as you can see by  
searching for "caching youtube").

This draft may want to reference BEP 22 (http://bittorrent.org/beps/bep_0022.html 
) as a strawman cache discovery protocol.

AFAIK, many P2P caches available today are expensive inline DPI-based  
devices due to the lack of a discovery protocol, so I think this draft  
understates the cost savings possible due to a good cache discovery  
protocol.

I think if ISPs really want to save bandwidth they will have to cache  
as much as possible, not just "registered" legal content. IANAL but  
the DMCA appears to allow this. Traditional HTTP caches cache  
everything (certainly there is plenty of pirated content flowing over  
HTTP), so I don't see why P2P would be different.

Wes Felter - [email-masked] - http://felter.org/wesley/

---

From: Nicholas Weaver <[email-masked]>
Date: Sat, 7 Mar 2009 22:15:21 -0800

On Mar 6, 2009, at 8:22 PM, Wes Felter wrote:

> Localization was getting a little over-hyped so I like this  
> document. Here are some suggestions:
>
> I didn't see any mention of traditional ISP-operated HTTP caches  
> (not CDNs), their discovery protocols (WPAD), and their legal  
> status. These may have fallen in popularity in recent years as the  
> cost of transit has dropped, but clearly some ISPs still use them  
> (as you can see by searching for "caching youtube").

Good point, although the biggest problem is the failure behavior:   
When Akamai fails its bad enough, when the cache in transit fails, its  
worse.

> ) as a strawman cache discovery protocol.

Thanks.

>
>
> AFAIK, many P2P caches available today are expensive inline DPI- 
> based devices due to the lack of a discovery protocol, so I think  
> this draft understates the cost savings possible due to a good cache  
> discovery protocol.

Which I don't get.  You don't need to be INLINE to do the necessary  
DPI, thats the great thing about P2P: you do an out-of-path IDS mirror  
to get the metadata and then pass it off to the cache which then does  
everything else.

> I think if ISPs really want to save bandwidth they will have to  
> cache as much as possible, not just "registered" legal content.  
> IANAL but the DMCA appears to allow this. Traditional HTTP caches  
> cache everything (certainly there is plenty of pirated content  
> flowing over HTTP), so I don't see why P2P would be different.

There is a difference between "may allow" and "worth fighting".   
Youtube is clearly allowed under the DMCA, but they go through a huge  
amount of effort to avoid hosting copyright violations, rather than  
just relying on the DMCA safe-harbor provisions which should be  
legally sufficient.

The few ISP operators I've talked to are very VERY nervous about  
caching pirated content, not just because of the lawsuits (even if you  
win, you lose because of the cost), but because they also need to be  
partners with the big hollywood content providers because of other  
corporate interests (what major ISP in the US is not either a telco  
that wants to be a cable co or a cable co that wants to be a telco?).

Thus "cache everything" i don't think is a viable option for the big  
ISPs.

But the key is "when legal shifts to P2P" (eg, like CNN's live video  
streaming), they must be able to cache it, because this is obviously  
coming down the pike, and spells bad news if it happens without caching.

Basically, of the ISPs I've talked to, the necessary requirements for  
a P2P edge cache are

a)  Out of path only.

b)  No DPI required at all.

c)  Protections so only legitimate content is cached.

A and B in particular require notification, and interact strongly with  
localization.

---

From: Wes Felter <[email-masked]>
Date: Sun, 8 Mar 2009 18:09:08 -0500

> coming down the pike, and spells bad news if it happens without  

I see your point here. But this makes me wonder if P2P caching is just  
a way for ISPs to subsidize P2P CDN companies -- another form of cost  
shifting. (Will P2P CDNs bill content providers for total bits  
delivered, even if those bits were delivered from an ISP-owned cache?)  
I suspect economics of this sort is off-topic for IETF so I won't  
ramble on any more.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 9 Mar 2009 08:48:12 -0700

On Mar 8, 2009, at 4:09 PM, Wes Felter wrote:

>> But the key is "when legal shifts to P2P" (eg, like CNN's live  
>> video streaming), they must be able to cache it, because this is  
>> obviously coming down the pike, and spells bad news if it happens  
>> without caching.
>
> I see your point here. But this makes me wonder if P2P caching is  
> just a way for ISPs to subsidize P2P CDN companies -- another form  
> of cost shifting. (Will P2P CDNs bill content providers for total  
> bits delivered, even if those bits were delivered from an ISP-owned  
> cache?) I suspect economics of this sort is off-topic for IETF so I  
> won't ramble on any more.

Actually, I don't think its off topic, economics MATTER when building  
networks, especially P2P.  ISPs understand their economics well, but  
many of the P2P boosters don't understand this or refuse to  
acknowledge this.  Thus I'll argue that this is perfectly on-topic, as  
we want to do economically-relevant engineering.

As for caches themselves, if anything, I'd hope the ISP sees their  
interest is "don't bill".

Because:

Edge caches for P2P are cheap:  By dropping the reliability concerns  
(well, by shifting reliability concerns onto clients which have  
already addressed them), they cost almost nothing once the software is  
designed, and most of the software is already avaliable (since most is  
common with client code).

Thus the maximum benefit to the ISP occurs when they are maximally  
used.  Thus they don't need to build up the very extensive  
infrastructure that Akamai or another edge-located CDN does to  
tolerate failures.

If the edge caches aren't "free" to content providers, content  
providers simply won't use them, because they are shifting towards P2P  
because it is "free" to them as long as customers have "not quite  
unlimited" network connections.  EG, the norwegian public broadcaster  
has had a huge success in using BitTorrent in reducing their bandwidth  
bills.  Once a content provider takes the jump to full P2P, going back  
to a world where they have to pay MORE is not going to happen  
voluntarily.

Edge caches are partial-deployable:  If only ONE major ISP uses such  
edge caches, that ISP benefits and the content providers benefit, but  
other ISPs don't benefit or really suffer (assuming you have  
localization).  But partial-deployability is less effective in the  
case of charging for data from the cache, as you need to bootstrap up  
to at least a certain critical mass before you can bill.

Thus I think its one of those cases where IF the ISPs can resist  
charging for edge-cache data delivery, everybody involved in the  
content delivery process: the providers, the users, and the ISP, all  
win, with only the conventional CDNs losing.

---

From: "DePriest, Greg (NBC Universal)" <[email-masked]>
Date: Mon, 9 Mar 2009 13:49:09 -0400

In addition to legitimate concern with the economics of IETF proposals
and standards, I would encourage the group to also be concerned with how
those standards will be used.

"...when legal shifts to P2P" certainly acknowledges how most P2P is
used today and is likely to be used tomorrow (percentage wise) absent
constructive action by key stakeholders such as IETF. 

Due to a lack of such action, the concept of a "wild west" Internet has
driven a number of countries to begin to take steps to "tame the west."
New Zealand is the latest.

A better approach would be for IETF to consider the total breadth of the
"congestion" problem and consider comprehensive solutions addressing
engineering, economics, and law.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Nicholas Weaver
Sent: Monday, March 09, 2009 11:48 AM
To: Wes Felter
Cc: Nicholas Weaver; [email-masked]
Subject: Re: [alto] Comments on draft-weaver-alto-edge-caches-00

Because:

_______________________________________________
alto mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/alto