Re: Distribution CPG Protocol

["Phil Rzewski" <philr@inktomi.com>]

Ok... now for a message on "fine-grained surrogate control". With regards 
to my previous post on "policy-based best-effort"...

At 03:31 PM 1/10/01 +0100, Oscar Ardaiz wrote:
>it will prevent fine-grained per surrogate selection (who is
>interested in it? ISPs. They will be able to offer their caches as
>surrogates to content providers). It is not realistic for a CP to find
>out every possible surrogate that will satisfy content provider service
>requirements by browsing ISPs web sites. A dynamic deployment protocol
>that rendezvous CP service requirements with surrogates capabilities is
>needed.

I may have been unclear in my "best-effort" post. I have always supported 
the "prefix-based" method, which I think could provide reasonably good 
fine-grained per-surrogate selection. This is to say:

At 02:20 PM 1/11/01 +0100, Martin May wrote:
>what I meant is that network lists are a good starting point
>(as Oliver proposed:
>REGION : <NAME> {
>        <IP>,<PREFIXLEN>;
>        <IP>,<PREFIXLEN>;
>        ....
>}!
>)

I definitely support this. I think it even provides a solution for the ISP 
example that Oscar spoke about. Let's take an example of an ISP with 
multiple services: They provide wholesale backbone connectivity (and have 
some surrogates in their backbone POPs) but also provide their own dialup 
service (with proxy caches right in front of the modem banks). They may 
attach a metric of "1" to all the prefixes associated with their dialup 
customers, and tell their peers that this is the supreme metric, since 
you're never gonna find a surrogate that's better able to serve those 
dialup customers than the proxy they point to. Meanwhile, they might attach 
a metric of "10" to the prefixes of their wholesale backbone customers, 
since some of those customers may be dual-homed and buy their connectivity 
elsewhere, so that ISP's surrogates may be as good as their other ISP's 
surrogates. If the CP receiving the prefixes gets this same prefix 
advertised from multiple places, that CP may need to use some other policy 
to decide to which one he should route requests coming from that prefix range.

(Note that, the Content Provider [CP] could just as easily be a CDN buying 
from another CDN. Oliver had said in response to my previous post that I 
was only thinking of CPs that need act as CDNs, and I didn't mean to send 
that impression. I just have a trouble calling everything a CDN, because 
it's not always obvious who is buying from whom. At least if I use the 
example of a CP, it's obvious that they're at the top of the chain.)

Martin goes on to say:

>But who will serve the clients that are not in one of the networks?
>but this is more a request routing problem and not a distribution
>problem.

Indeed, it's a Request-Routing problem, but I still think it's one worth 
thinking about.

This is akin to the concept of a "default route" in the routing/BGP 
universe. If I buy my connectivity from one provider, all I need is a 
default route: I send it all to one place. However, perhaps I am in a 
European country and I have one line to the USA from which I get a default 
route, and another line from a European provider from which I get a 
more-specific list of European routes. The typical policies on a router 
will follow the "more specific" European routes before it follows the 
general default route, which is what the customer would likely want in that 
case.

The same concept could carry over into the CDN universe. The CDNs that 
claim to be "global" will advertise a claim that they have global reach. 
For a CP that buys from just one CDN, this is fine. That CP might then 
decide to peer with a handful of smaller, regional CDNs. He'd then get sets 
of "more specific" prefixes from each of those. Then again, if that CP 
decided to buy from multiple "global" CDNs, he'd either need to create some 
policy of his own (send alternating requests to each CDN and race 'em) or 
ask those CDNs to send a "full feed" (hoping those CDNs have catalogued 
specific lists of which prefixes they are "closest" to, attach metrics, etc.)

Some healthy skepticism:

At 01:24 PM 1/11/01 +0000, Alex French wrote:
>So this is a list of IP blocks that the CDN is willing to serve (eg for 
>global CDNs it would be "*") rather than any type of advertisement of 
>proximity to blocks.
>
>Playing devil's advocate, I'm wondering two things:
>1) How useful this data is in a negotiation scenario: CDN A might offer to 
>serve any client worldwide, but it only has surrogates in the Far East.
>2) How likely this is to change rapidly; if it's a relatively static 
>parameter, could it just be done offline?
>
>Basically, is there a lot to be gained from negotiating this online rather 
>than offline?

Well, if CDN A advertises itself as "global" but only has surrogates in a 
small region, the performance should be horrid and they should be out of 
business very quickly. I do stand by the part of my original "best-effort" 
post where I indicated that the onus is on the buyer to test whether their 
providers do what they say.

As for whether it will change rapidly, I think it will change often enough 
that we can make an argument to carry this data in-band. I once again use 
my earlier example of the wholesale backbone ISP: If a customer switches 
providers, remove their prefix from the advertisements. (Or it could be 
done if that customer's line temporarily goes down, which would make an 
even better argument for near-real-time.)

And finally...

At 09:13 AM 1/11/01 -0500, Eric Dean wrote:

>Again, IP addressing and geotargeting are falliciously related.  Since
>CIDR, most networks are highly aggregated.

There's no law that says that the prefixes advertised through CDNP 
protocols need to be the exact same prefixes advertised by the routers 
speaking BGP. I see it as an advantage that someone COULD use the same 
prefixes (especially for the purposes of getting this up and running), but 
they don't have to. If people see real performance improvements from these 
protocols, it will give every motivation to selectively de-aggregate, 
attach meaningful metrics, etc.

--
Phil Rzewski - Senior Architect - Inktomi Corporation
650-653-2487 (office) - 650-303-3790 (cell) - 650-653-1848 (fax)