hard questions: request routing

["Cain, Brad" <bcain@cereva.com>]

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