[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>, <cdn@ops.ietf.org>
- Subject: RE: Executive summary of: RE: hard questions: request routing
- From: "Mark Day" <markday@cisco.com>
- Date: Wed, 4 Apr 2001 09:42:03 -0400
- Delivery-date: Wed, 04 Apr 2001 06:42:19 -0700
- Envelope-to: cdn-data@psg.com
Oliver, many thanks for putting this together.
One minor quibble: It will indeed be very helpful for people to explain
their positions on the various proposals, but I'd like to avoid any sense
that we are "voting" on this. As usual, we are trying to reach rough
consensus on the best technical solution.
Thanks,
--Mark
Mark Stuart Day
Senior Scientist
Cisco Systems
+1 (781) 663-8310
markday@cisco.com
> -----Original Message-----
> From: owner-cdn@ops.ietf.org [mailto:owner-cdn@ops.ietf.org]On Behalf Of
> Oliver Spatscheck
> Sent: Tuesday, April 03, 2001 5:12 PM
> To: cdn@ops.ietf.org
> Subject: Executive summary of: RE: hard questions: request routing
>
>
>
> 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
>