RE: hard questions: request routing

[Eric Dean <eric@crystalballinc.com>]

...and what would that metric characterize?  In other words, what other
attributes is the metric assigned to: client DNS proxies, client IP
addresses, summarized addresses?
 
On Thu, 29 Mar 2001, Dmitri Krioukov wrote:

> 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
> >
> >
> >
> >
> 
> 

Eric Dean
President, Crystal Ball Inc.
W 703-322-8000
F 703-322-8010 
M 703-597-6921