Advertisement Protocol -- more thoughts

[brad cain <bcain@mediaone.net>]

Here are some more thoughts on the advertisement protocol



CDN Peering scenarios
---------------------
1. CDNs to CDN peering via DNS direction
This is the scenario we have been talking about -- CDN redirects
DNS request to another CDN per a policy.  The policy is formed from
various metrics which must be exchanged.  For example: total CDN
load, proximity to users (e.g. source ip address ranges)
Common case: CDN peers with another CDN where both have DNS direction
systems

2. CDNs to ISP CDN peering via proxies or transparent proxies
This is the scenario where a CDN tells a set of proxies which URLs
it is serving and how to reach the surrogates with those URLs.  A
protocol is needed to exchange URLs/metric information for each.
Common case: CDN peers with ISP which has transparent proxies (that it
will use as a CDN)


The two scenarios above are different and therefore require a
different sets of information to be exchanged.  The following
are two descriptions of protocols for the two scenarios
above:



URL Exchange Protocol (proxy case)
----------------------------------
This protocol exchanges a list of urls and a set of metrics with
each set.  This protocol is used to communicate metrics to proxies or
transparent proxies.  An example would be a CDN advertising

"Content AS": 2
url: http://www.blah.com/images
nexthop: surrogate 1
metric: 10

to a transparent proxy. The transparent proxy can then make a local
decision as to where to retrieve a given object.   (note: a url
exchange protocol is also needed for logging and billing though
different types of information needs to be included)



Feedback/Metric Exchange Protocol (DNS direction case)
------------------------------------------------------
This protocol communicates metrics between CDNs and is mostly useful
for DNS request direction.  Each CDN exchanges a set of agreed upon
metrics.  Examples include:
        1. Overall load measure: ability of CDN to handle requests (very
           coarse grain metric).  this metric also allows a CDN to
start/
           stop requests being routed to it (e.g. on/off).
        2. Source IP addresses: CDN tells peers which layer-3 addresses
           it has "coverage" for--common case will be ISP CDN that
wishes
           to serve content for users in its own address space.
        3. Others: ....



Similarities
------------
In both protocols there is a need to exchange metrics.  However,
granularies
of information exchanged are different.  With DNS request peering,
overall CDN metrics (as well as metrics per domain) need to be
exchanged.
With proxy peering, URL granularity may be useful (although the large
amount of state required to be exchanged will be problematic).  Can we
have one protocol that exchanges all of these metric types:
        1. URL metrics:"distance" to url, next hop surrogate, etc
        2. Domain metrics: metric per DNS domain that a CDN is auth for
        3. Overall CDN metrics: overall state of CDN, IP prefixes for
        which a CDN covers

[[We could use BGP and have different "address type" fields for each?
(layer-3 analogy: one MBGP session can exchange: ipv4, ipv6 and ipv4
multicast routes)]]


Accounting
----------
Another use for the URL exchange protocol is for the accounting and
billing piece.  A URL exchange protocol could be used between "special
nodes" in the billing/accounting system to exchange information between
CDNs as to which URLs they are the authoritative redirection entity for.
This way the accounting information can automatically get rolled up
towards the authoritative domain.