Subject: [tram] Comments on draft-williams-peer-redirect-01

From: Ted Hardie <[email-masked]>
Date: Wed, 23 Jul 2014 14:53:33 -0400

During the meeting today, I asked for the document authors to consider
describing what sort of analysis is being performed to determined that a
particular set of alternates should be chosen.  I've tried to capture the
issue here with a little art.

The document contains this ascii art as a description of the problem space:

Boston
                                                             Peer C
                                         Chicago              [PC]
                                          Peer B               /
   TURN Relay A                  ----------[PB]-------------[TC]
   San Francisco      ----------/                       TURN Relay C
       [TA]----------/                                    New York
        |
       [PA]
      Peer A
    Los Angeles

The problem they elucidate is that Peer B looks for a TURN server and
gets Relay C as the closest
by the current methods (which might include DNS split view and/or
anycast).  If the Peer is Peer A,
they note, a better Relay  might be TA.  But this is far from obvious
in a real network, as it depends on knowing
the interconnects are and knowing how both forward path and return
path will be used (given hot
potato routing, it's unlikely that the forward and return path will be
the same).

I've linked a different example that shows some of the common
complexity (built off an openly
usable image from wikipedia.org, which I credit for the underlying image).

https://drive.google.com/file/d/0B-1skjUwD-8ESkplZW51U3o5Q1k/edit?usp=sharing

A flow between the two clients noted that goes through the Relay in
PoP 2  may very well
be suboptimal, but determining that the other relay (attached at Tier
2 ISP) is better is actually not
simple.  While I don't think we need to describe secret sauce, I
personally believe that you'd
need something equivalent to fresh data on the RTT between the
relevant relays and the networks in
which the two peers sit.  If you don't have fresh data, you run a real
risk of sending a peer to a relay
is functionally worse (or even offline).  If you don't have an
orchestration system collecting that
data and updating the relays with the data, you are likely to be much
better off using
simple anycast, since it will be at least as fresh as BGP and has a
built-in healing mechanism.

I think it would be valuable for the draft to describe what kinds of
data you'd need to have on hand
to use this approach, in other words, so that enterprises or small
ISPs which do not are not tempted to
build on it.  There's a foot-gun there in the form of stale data, and
I'd rather have instructions on
how to keep it from going off.

regards,

Ted

---

From: Brandon Williams <[email-masked]>
Date: Thu, 24 Jul 2014 09:14:13 -0400

Thanks Ted. That's a helpful clarification of what you're looking for 
and why. I will add some text to the next revision on this point. I may 
also add some text to describe additional use cases for the 
functionality in order to show that it has broader applicability than 
the problem-space currently described in the draft.

--Brandon

On 07/23/2014 02:53 PM, Ted Hardie wrote:
> particular set of alternates should be chosen.  I've tried to capture
> the issue here with a little art.
>
> The problem they elucidate is that Peer B looks for a TURN server and gets Relay C as the closest
> by the current methods (which might include DNS split view and/or anycast).  If the Peer is Peer A,
>
> they note, a better Relay  might be TA.  But this is far from obvious in a real network, as it depends on knowing
> the interconnects are and knowing how both forward path and return path will be used (given hot
> potato routing, it's unlikely that the forward and return path will be the same).
>
>
> I've linked a different example that shows some of the common complexity (built off an openly
> usable image fromwikipedia.org  <http://wikipedia.org>, which I credit for the underlying image).
>
>
> A flow between the two clients noted that goes through the Relay in PoP 2  may very well
> be suboptimal, but determining that the other relay (attached at Tier 2 ISP) is better is actually not
>
> simple.  While I don't think we need to describe secret sauce, I personally believe that you'd
> need something equivalent to fresh data on the RTT between the relevant relays and the networks in
> which the two peers sit.  If you don't have fresh data, you run a real risk of sending a peer to a relay
>
> is functionally worse (or even offline).  If you don't have an orchestration system collecting that
> data and updating the relays with the data, you are likely to be much better off using
> simple anycast, since it will be at least as fresh as BGP and has a built-in healing mechanism.
>
>
>
> I think it would be valuable for the draft to describe what kinds of data you'd need to have on hand
> to use this approach, in other words, so that enterprises or small ISPs which do not are not tempted to
>
> build on it.  There's a foot-gun there in the form of stale data, and I'd rather have instructions on

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.