[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Executive summary of: RE: hard questions: request routing
- To: Oliver Spatscheck <spatsch@research.att.com>
- Subject: Re: Executive summary of: RE: hard questions: request routing
- From: Martin May <Martin.May@activia.net>
- Date: Wed, 04 Apr 2001 20:44:26 +0200
- CC: cdn@ops.ietf.org
- Delivery-date: Wed, 04 Apr 2001 11:43:41 -0700
- Envelope-to: cdn-data@psg.com
- Organization: ActiVia
Oliver,
thanks for the summary. however, I don't really want to start voting
for a mechanism at this point.
I agree that the simplest solution is to restrict the number of redirections, but
this can not be our long term solution. We should make sure that
we do not exclude transient/intermediate CDNs.
I like Brad's 5th solution and I'd like to hear more feedback
on the mailing list. Brad's and Abbie's solution indeed could be merged
if I understood them correctly.
- Martin
Oliver Spatscheck wrote:
> Enclosed the executive summary of the discussion about loop avoidance in
> request routing. I think I finally understood Abbie's solution after talking
> to him and we think it is time that the group agrees which method we should use
> to move on. The candidates which crystallized so far:
>
> 1. Restrict the topology.
>
> This solution statically restricts the depth of request routing to one (or
> maybe two). This avoids loops due to its static limitation, however, it is
> the most restrictive one. On the other hand the protcol overhead is zero.
>
> 2. Recursive request routing
>
> The request is handled by the first CDN contacted by a client. The CDN
> will ask other CDN's recursively to resolve to an A record. This recursive
> request includes a request path which can be used to prevent loops. This
> avoids the DNS hack issue, however, it requires a new protocol (or DNS
> extension) to carry the path information.
>
> 3. Abbie's proposal
>
> A matrix is distributed to all participants representing the relationships
> between individual CDNs for a particular set of content. This matrix is
> used to encode the path info as set of CNAMEs in a structured way. So this
> solution is similar to Brad's suggestion, except it adds structure to the
> CNAME encoding (see Abbie's email for more data).
>
> 4. Abbie's proposal as I understood it first..... .
>
> A cycle free graph is generated based on the matrix every time a CDN starts
> or stops serving a particular set of content. This cycle free graph is
> distributed to all CDN's involved atomically. Request routing is now a
> traversal of this cycle free graph. This is basically a variant of a link
> state protocol, but the atomic requirement makes it rather expensive.
>
> I think we discarded already the path vector with common metric
> approach. So at this point we have to decide which way we want
> to go. PLEASE VOTE NOW!
>
> Oliver