RE: hard questions: request routing

[DonE@activate.net]

At first I thought the single metric solution would work, but now I'm
convinced by all the discusion that it is hard.  I think the two level
solution is the right one for the reasons that Brad gives; I can't see
needing anything more.

Don

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