RE: comments on draft-ietf-cain-request-routing-req-00.txt

[Oliver Spatscheck <spatsch@research.att.com>]

Dmitri Krioukov writes:
 
 > 
 > >  > 1) Support of various types of metric
 > >  > 
 > >  >    Wouldn't it be easier to support just
 > >  >    one standard metric or, at least, to fix
 > >  >    supported metrics to some reasonable
 > >  >    minimal set of required ones? CPGs are
 > >  >    then responsible for mapping the internal
 > >  >    proprietary set of metrics to this
 > >  >    standard one (either metric or a set of
 > >  >    metrics) and vice versa.
 > >  > 
 > > 
 > > I think that is what we intend to propose. Maybe it didn't become
 > > clear in the draft. I think the consensus was to require a minimal
 > > set of metrics say one and to allow for custom metrics which
 > > are on a peer to peer basis. The rational was to be similar
 > > to BGP community strings (peer to peer custom metric) while
 > > preventing the shortfall of community strings that even for
 > > common metrics every set of peers has to reinvent the wheel
 > > (small set of required metrics).
 > 
 > The BGP community is not a metric, it's an attribute -- quite
 > different thing from the protocol design and operation standpoint.
 > It's also a separate document from the specification standpoint.

I am not quite sure what the difference between a peer to peer
attribute and a peer to peer metric is  since they are both
only interpreted by the peers. However, if you want to call them
attributes that works for me. Otherwise I think we agree
here:

- one (or as few as agreeable by consensus) required metric
- the option to exchange peer to peer attributes (I rather
  call them metrics since that is what they represent...)



 > 
 > I guess I need to explain what I mean under these examples.
 > 
 > Imagine there are two peering CDNs: CDN-A and CDN-B. CDN-A
 > uses a DNS based RRS; CDN-B uses a L7 based RRS. A client
 > enters CDN-A and asks for a.b.c/d. Since CDN-B RRS is L7

                            ^^^^^^ On the RRS lelvel the client
				   will ask for a.b.c not
				   a.b.c/d


 > based, {a.b.c/d, surrogate ID set} was advertised from CPG-B
 > to CPG-A via RPP. Since CDN-A RRS is DNS based only a.b.c is
 > known to be served by CPG-A (! - the gateway to CDN-B) to the
 > CDN-A RRS boxes. When the DNS request for a.b.c is received by CDN-A,
 > proximity calculations between the CDN-A a.b.c surrogates and
 > the client LDNS is triggered (assuming the simplest form
 > of DNS based RRS is used), plus CPG-A send request to CPG-B
 > to measure proximity between a.b.c (which is probably CPG-B
 > surrogates having "all" the a.b.c content) and the client
 > LDNS. 

Maybe I am missing something. Are you suggesting that CDN-A
has to contact CDN-B for each DNS resolution? This is not
very efficient especially for small objects.

 > Clearly, CDN-B cannot perform L7 based merriments at
 > this point. It can either perform some primitive proximity
 > measurements and report the corresponding result ({surrogate ID,
 > metric} pair) back to CPG-A or reply to CPG-A with the negative
 > result. In the latter case, the default metric between CDN-A
 > and CDN-B (most probably administratively configured) is used.
 > CPG-A injects then the obtained results into the CDN-A RRS
 > process and the routing decision is made.
 
Are you assuming the RRS of CDN-A determines a surrogate? This will not
work. If the openness of ISPs in the BGP routing arena is any indication you can
not assume that CDN-A will be given enough information to find the appropriate
surrogate in CDN-Bs domain (this would be the same as giving your competing
ISP your BGP policy and OSPF weights). The model I had in mind is rather that
CDN-A's RRS will defer finding the right surrogate to CDN-B's RRS. All 
CDN-A's RRS has to decide is to use CDN-B.

> 
 > The case when a client enters CDN-B is much simpler. Since
 > CDN-A uses a DNS based RRS, {a.b.c, surrogate ID set} was
 > advertised from CPG-A to CPG-B. When a.b.c/d HTTP request
 > is received by a CDN-B redirector (assuming HTTP redirection
 > is used), it may be up to CPG-B responsibility to come up with
 > the CDN-A {a.b.c/d, surrogate ID subset} and to communicate the
 > result with the redirector. The proximity calculations are
 > performed then and the routing decision is made.
 > 
 > The bottom line is that two RRSs of different type can
 > peer at least somehow. Could you please elaborate on how
 > it's possible when the RRS type is exposed in RPP?
 > 

The problem with this simple approach is that the entire content
of a.b.c has to be served by everybody CDN-A peers with.
Since CDN-A only makes a RRS decission based on DNS name.
So somewhere (between the RRP and CPP) the other CDNs have
to be made aware that ALL or NONE of the content of a.b.c
has to be carried in the surrogates. This becomes particularly
troublesome if a push model is used (push is the most common model
for on demand movies at this point). Since now everybody who
serves one movie in his domain a.b.c has to push it to all surrogates
of all CDNs he peers with. On the other hand if content is seperated
by domain name if a DNS based RSS is used (as stated in the requirements)
this overhead can be eliminated.

I agree that requireing to seperate content by domain name if
DNS based RSS are used is an ugly hack (which happens to be
used by nearly all CDNs...) but I think it will be the most
liekly candidate of beeing adopted in the short term.

Oliver