RE: hard questions: request routing

["Dmitri Krioukov" <dima@krioukov.net>]

I still think that the easiest way to
attack p.2 is a very straightforward hard
choice -- everyone agrees on the single
metric whose primary purpose is proper
inter-CDN request routing with loop
avoidance -- an analogue of "the
control plane" for inter-CDN routing
if you wish. This metric may not even
have any other semantics. Or it may
have one (like delay) if any consensus
is possible to achieve. All other
(optional or not) metrics are in
"the data plane" then.
--
dima.

> -----Original Message-----
> From: owner-cdn@ops.ietf.org [mailto:owner-cdn@ops.ietf.org]On Behalf Of
> Cain, Brad
> Sent: Thursday, March 29, 2001 2:50 PM
> To: 'cdn@ops.ietf.org'
> Cc: Cain, Brad
> Subject: hard questions: request routing
>
>
>
> During the IETF, there were several conversations related to
> request routing protocol design.  I've put
> together the following list of items that were discussed.  [note that
> #1 is not request routing specific]
>
> 1. - encoding format for protocols.  should the encoding be: byte-based,
> ascii, or xml?  there seems to be a variety of opinions on this one.
> however, it would be nice to have all protocols out of CDI use the
> same encoding format.  here are some advantages/disadvantages of each
> approach
>
> byte: advantages: quick to parse. well known for infrastructure protocols.
>                   compact encoding. easy for embedded systems.  argument
> that
>                   CDI is "infrastructure" protocols and should be compact
> and
> 	            fast to parse.
>       disadvantages: inconvenient for ascii items (e.g. URIs).
> inconvenient
> 	               for debugging.  argument that CDI is
> "application-layer"
>                      and should be at least ascii parsable.  may be
> difficult
>                      to extend syntax for certain circumstances.
>
> ascii: advantages: reasonable to parse. well known for web based protocols
> (http).
>                    reasonable for embedded systems. seems ok for
> infrastructure
>                    protocols. easy to debug and troubleshoot. easy to
> extend.
>                    convenient for ascii items (e.g. URIs).
>        disadvantages: not as fast as byte for parsing, extra bandwidth
> overhead
>                       compared to byte.
>
> xml: advantages: extensible standard for information exchange.
> may make use
> of
>                  inherent xml features later.  relativly easy to debug and
>                  troubleshoot.  easy to extend.  convenient for
> ascii items.
>    disadvantages: not as easy to parse as ascii or byte.  requires xml
> parser
>                   in device (not as easy for embedded systems).  protocols
> built
>                   will have dependency on xml.  argument that CDI
> protocols
> are
>                   "infrastructure" protocols and should be ascii or byte.
>
> note: this is a large topic -- if anyone wants to comment extensively on
> this
> topic I would encourage creating a new thread
>
>
>
> 2. - loop freedom.  request routing systems must ensure that
> request routing
> decision processes to not cause loops.  the difficult part about this
> problem
> is that many people have expressed interest in having multiple metrics
> exchanged.  if multiple metrics are used as a basis of a decision
> then loop
> freedom can only be accomplished if one or more of the following
> conditions
> are met:
> 	1 everyone agrees on the metrics and the order of evaluation
> 	2 there is a centralized place for routing policy conflicts (e.g.
> route
> 	  arbiter)
> 	3 everyone agrees on global metrics, but has peer-to-peer specific
> 	  metrics
> 	4 there are methods in the request routing itself that allow
> 	  loop prevention (e.g. dns "soft state")
> 	5 topology is constrained to two levels (e.g. star topology)
>
> given the extent of this problem, two practical solutions were discussed.
> the
> first was putting "soft state" into dns (e.g. AS path into CNAMEs).  this
> cute
> hack works nicely but may not sit well in the ietf.  the other was to
> constrain
> the topology to two levels (e.g. no third party peering).  the arguments
> here
> go something like this:
> 	1 two levels is enough for now
> 	2 content providers probably wouldnt want their content to be
> 	  controlled/delivered by two entities removed
> 	3 request routing is an overlay so there is no techical reason that
> a
>         provider cant interconnect any other (unlike ip routing)
> what ever decision is made, we should still put in place *advertisement*
> loop prevention
>
>
>
> 3. - request routing information.  request routing systems exchange
> different types of information.  in the drafts so far, we have focused on
> two major "types" of information: the first is keyed on an IP prefix
> (area advertisements), the second is keyed on a URI (content
> advertisements).
> according to discussions, this is the extend of "major" types needed
> right now (though of course we need multiple metrics per major type).
>
>
>
> 4. - dns vs. layer-7/in-line.  one of the difficulties of request routing
> interconnection is that there are two drastically different methods of
> implementing it.  the first (and most common) is through dns.  the second
> is through a layer-7 router (note: this is different from server load
> balancing -- e.g. layer-7 routers at the edge).  the discussion focused
> on how to design a protocol which would accomodate both and how they
> would interwork (beyond the protocol level).  the comments were:
> 	- in either case the *information* itself is (mostly) common
> 	- if we solve dns first we can retrofit for in-line/layer-7
> 	- some of the problems are outside the scope of protocols
> in general it was felt that solving the dns case first was the
> right way to go.
>
>
>
> 5. - content types.  when performing inter provider request routing,
> it is undesirable to route a request to a network which cannot serve
> the content type.  in a dns request routing system, the content type
> is not visible to the system UNLESS it is encoded in the dns name.
> a discussion took place regarding the ability to standardize the
> methods of content type encoding in dns names.  although many thought
> it convenient, it was in general deemed hard.  a way to accomplish
> the same result is to:
> 	- exchange content type abilities of networks in interprovider
> 	  protocols
> 	- exchange a content types (e.g. mime type) per domain in
> 	  content advertisements.  this would originate from the
> 	  authoritative cdn.
> having protocols carry the "mapping" was (in general) thought
> to be the best compromise.  [note: some did still express an
> interest in standardizing so the exchange of this information
> is unnecessary]
>
>
>
>
>
> -brad
>
>
>
>