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

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

> -----Original Message-----
> From: Oliver Spatscheck [mailto:spatsch@research.att.com]
> Sent: Friday, January 26, 2001 8:40 AM
> To: Dmitri Krioukov
> Cc: Cain, Brad; cdn@ops.ietf.org
> Subject: comments on draft-ietf-cain-request-routing-req-00.txt
> 
> 
> 
> Dima,
> 
> 	I think your comment is well taken. The problem is that each
> requirement seems to have somebody who really thinks it is needed. I
> think part of the process we have to go through by the next IETF is to
> go look at all the arguments to decided which one are really
> required. Please remember there is a reason they call IETF drafts
> drafts ... .

Agreed. My comments were just a refinement attempt. I'd like to
emphasize that any protocol feature is stillborn if it's not
an absolute requirement. If a protocol is full of such features,
it's stillborn itself. It was very hard to make a part of reality
even the simplest protocol designs.

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

> By the way it is easy to say there should be only one metric without
> naming it.

Yes, it is :)

It's also easy to name it if we take into consideration that
the final goal is fastest response.

> Asking five people what the one metric should be
> I got six answers.

We need rough consensus, don't we. If we had needed running
consensus, we would've had very rough code. Remember ISO!

>  > 2) Support of various types of RRSs
>  > 
>  >    Interconnected RRSs perform the function
>  >    of one global RRS. The function of *any*
>  >    RRS is to intelligently map the {client
>  >    IP address (prefix), URI} duplex to an ID
>  >    (which boils down to an IP address) of some
>  >    surrogate from the set of surrogates capable
>  >    of processing request for that URI.
>  >    "Intelligently" means that the minimal
>  >    metric (which is a function of all three --
>  >    client, URI and surrogate) is searched for.
>  > 
>  >    So, what the RRS peering protocol MUST
>  >    do is to advertise URIs (possibly with some
>  >    "default" metrics), plus to be capable of
>  >    mapping {client, URI} requests to
>  >    corresponding {surrogate, metric}
>  >    responses. CPGs are responsible for
>  >    translating RR information obtained via
>  >    internal proprietary RR methods into this
>  >    standard information exchanged via the RRS
>  >    peering protocol (RPR, DPR, APR, if three;
>  >    CPR if one!).

I meant RPP, DPP, APP and CPP, of course.

>  >    Examples of how the overall system would
>  >    operate even in the complex cases (like
>  >    peered RRSs of different types) are
>  >    straightforward.

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

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?

> Please clarify for me why your protocol would not fulfill the
> requirements stated in the draft. Maybe we should change
> the requirements which are violated. We haven't proposed any protocol
> as of yet and a simple protocol for a complex set of requirements
> is always a good solution.

See both above and below :)

>  >    In its current form, the corresponding
>  >    part of the draft:
>  >    - significantly complicated the protocol
>  >      design
> 
> Why?

Because internals of peering RRS (namely, the RRS type)
is exposed in the protocol.

>  >    - essentially violates the "black box"
>  >      approach to the individual RRSs
> 
> Why?

Because internals of peering RRS (namely, the RRS type)
is exposed in the protocol.

>  >    - does not allow for peering between RRSs
>  >      of different types
> 
> Why?

Because internals of peering RRS (namely, the RRS type)
is exposed in the protocol.

>  >    - does not support L3 (IP routing) based RRSs
>  >      (they are not popular but existent)
>  > 
> 
> Didn't you just argue we already support to much?

When RPP is RRS-type independent, all (existing and
non-existing) types of RRSs become automatically
supported.

> Oliver
--
dima.