Subject: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?

From: Jonathan Lennox <[email-masked]>
Date: Mon, 28 Jul 2014 22:10:33 +0000

Hi — due to the conflict with AVTEXT, I wasn’t in TRAM in Toronto, so I’m just watching the Meetecho recording now.

I had a comment on the technique in draft-williams-peer-redirect-01.

In particular, I’m concerned about what happens if both peers are using TURN relays that support this protocol.  It seems like two TURN networks could get into a non-converging series of redirections.

So you have an initial ICE exchange in which peer a initially gets a relayed address A on its TURN server, and peer b gets a relayed address B on its.  Both TURN servers are part of (different) networks of TURN servers that support peer redirection.

So when TURN server A gets the CreatePermission/ChannelBind request to connect to B, it redirects to A’.  Then B tries to connect to A’, and redirects to B’.  And A’ connects to B’, and redirects to A'’.  And so on…

Is this likely to be a real problem?  And if so, is there anything that could be done about it?

---

From: Justin Uberti <[email-masked]>
Date: Mon, 28 Jul 2014 17:56:19 -0700

I agree this is a real problem - while A' might be a better match for B, A
might be better for B', just due to internet routing oddities. So you could
end up switching ad nauseam.

Also:
2) Ted's point that "closer" doesn't always mean "better" - A often won't
have the information to know for sure that A' is better for B.
3) The general mechanism is unlikely to produce the desired results,
because the ALTERNATE-SERVER will typically arrive after gathering has
completed - and thus you need to do an ICE restart to actually use the new
TURN server. Since the timing of ALTERNATE-SERVER will be different for
both a and b, it will be difficult to get this properly synchronized.

If we could do a synchronized restart though, one could treat the
ALTERNATE-SERVER from the original TURN server as a suggestion, and then
during the restart, allocate candidates from both. Then, using the actual
RTTs that are observed amongst the permutations (A->B, A->B', A'->B,
A'->B'), the CONTROLLING side can determine the best path to use.

On Mon, Jul 28, 2014 at 3:10 PM, Jonathan Lennox <[email-masked]> wrote:

> Hi — due to the conflict with AVTEXT, I wasn’t in TRAM in Toronto, so I’m
> just watching the Meetecho recording now.
>
> In particular, I’m concerned about what happens if both peers are using
> TURN relays that support this protocol.  It seems like two TURN networks
> could get into a non-converging series of redirections.
>
> So you have an initial ICE exchange in which peer a initially gets a
> relayed address A on its TURN server, and peer b gets a relayed address B
> on its.  Both TURN servers are part of (different) networks of TURN servers
> that support peer redirection.
>
> So when TURN server A gets the CreatePermission/ChannelBind request to
> connect to B, it redirects to A’.  Then B tries to connect to A’, and
> redirects to B’.  And A’ connects to B’, and redirects to A'’.  And so on…
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: Simon Perreault <[email-masked]>
Date: Tue, 29 Jul 2014 08:43:17 -0400

Le 2014-07-28 20:56, Justin Uberti a écrit :
> I agree this is a real problem - while A' might be a better match for B,
> A might be better for B', just due to internet routing oddities. So you
> could end up switching ad nauseam.

Agreed.

> Also:
> 2) Ted's point that "closer" doesn't always mean "better" - A often
> won't have the information to know for sure that A' is better for B.

I don't think that the problem is that it won't work: we know from 
Akamai's example that it can work. What Ted asked, as I understand it, 
is for the next draft revision to describe the knowledge that is 
required in order to be able to perform the kind of server selection for 
which the draft defines signaling.

> completed - and thus you need to do an ICE restart to actually use the
> new TURN server. Since the timing of ALTERNATE-SERVER will be different
> for both a and b, it will be difficult to get this properly synchronized.
>
> during the restart, allocate candidates from both. Then, using the
> actual RTTs that are observed amongst the permutations (A->B, A->B',
> A'->B, A'->B'), the CONTROLLING side can determine the best path to use.

Would be nice if we had an ICE-RTT draft that we could point to... ;)

Simon

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 29 Jul 2014 16:16:07 +0000

On Jul 29, 2014, at 8:43 AM, Simon Perreault <[email-masked]> wrote:

> I don't think that the problem is that it won't work: we know from Akamai's example that it can work. What Ted asked, as I understand it, is for the next draft revision to describe the knowledge that is required in order to be able to perform the kind of server selection for which the draft defines signaling.

If both endpoints end up on the same network of TURN servers (e.g., Akamai’s), there are a lot of useful things that could be done — put both relays on the same server, or on the best ingress/egress from their dedicated network, or whatever.  And in a lot of cases I expect that’s what will happen, for instance when there’s a contractual relationship between a WebRTC service and a TURN provider.  So I’m not opposed to this idea, by any means.

When the endpoints are on different networks, though, you could get weird behavior, so we'd need to make sure we specify this so that pathological outcomes can’t come about (or at least would be unlikely to).

> Would be nice if we had an ICE-RTT draft that we could point to... ;)

STUN (RFC 5389) already defines how you calculate the STUN RTO, based on the RTT.  I don’t think the protocols need anything further in order to get more precise RTT estimates, though perhaps some implementation recommendations on how to do it could be helpful.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 29 Jul 2014 16:24:26 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Simon Perreault
> Sent: Tuesday, July 29, 2014 6:13 PM
> To: Justin Uberti; Jonathan Lennox
> Cc: [email-masked]
> Subject: Re: [tram] Comment on draft-williams-peer-redirect-01: might it not
> converge?
> 
> > I agree this is a real problem - while A' might be a better match for
> > B, A might be better for B', just due to internet routing oddities. So
> > you could end up switching ad nauseam.
> 
> Agreed.
> 
> > Also:
> I don't think that the problem is that it won't work: we know from Akamai's
> example that it can work. What Ted asked, as I understand it, is for the next
> draft revision to describe the knowledge that is required in order to be able to
> perform the kind of server selection for which the draft defines signaling.
> 
> > new TURN server. Since the timing of ALTERNATE-SERVER will be
> > different for both a and b, it will be difficult to get this properly synchronized.
> >
> > ALTERNATE-SERVER from the original TURN server as a suggestion, and
> > then during the restart, allocate candidates from both. Then, using
> > the actual RTTs that are observed amongst the permutations (A->B,
> > A->B', A'->B, A'->B'), the CONTROLLING side can determine the best path to
> use.
> 

MPRTP already uses RTT and other path characteristics to load balance the media stream across different interfaces, it may help to look into the work they have already done.

-Tiru

---

From: Justin Uberti <[email-masked]>
Date: Tue, 29 Jul 2014 10:57:31 -0700

On Tue, Jul 29, 2014 at 9:16 AM, Jonathan Lennox <[email-masked]> wrote:

> Akamai's example that it can work. What Ted asked, as I understand it, is
> for the next draft revision to describe the knowledge that is required in
> order to be able to perform the kind of server selection for which the
> draft defines signaling.
>
> If both endpoints end up on the same network of TURN servers (e.g.,
> Akamai’s), there are a lot of useful things that could be done — put both
> relays on the same server, or on the best ingress/egress from their
> dedicated network, or whatever.  And in a lot of cases I expect that’s what
> will happen, for instance when there’s a contractual relationship between a
> WebRTC service and a TURN provider.  So I’m not opposed to this idea, by
> any means.
>
> When the endpoints are on different networks, though, you could get weird
> behavior, so we'd need to make sure we specify this so that pathological
> outcomes can’t come about (or at least would be unlikely to).
>
> STUN (RFC 5389) already defines how you calculate the STUN RTO, based on
> the RTT.  I don’t think the protocols need anything further in order to get
> more precise RTT estimates, though perhaps some implementation
> recommendations on how to do it could be helpful.

The one thing we need to do is update ICE to allow the CONTROLLING side to
make dynamic decisions about which pair to use, instead of being forced to
use PRIORITY (which is what 5245 says). I am going to try to write this up
before Hawaii.

---

From: Brandon Williams <[email-masked]>
Date: Tue, 29 Jul 2014 14:01:33 -0400

This is part of the point of the XOR-OTHER-ADDRESS attribute. The 
expectation is that the peer's reflexive address will go into this 
attribute if the permission/binding being requested is for a relayed 
address. The server will use this reflexive address to identify an 
alternate server, not the peer's relayed address. Since the same 
XOR-OTHER-ADDRESS is used by both server A and server A' when attempting 
to select an ALTERNATE-SERVER value, the likelihood of such an infinite 
regression should be minimal, regardless of whether the peer's relayed 
address changes.

That said, it doesn't make it impossible, which is why the spec also 
provides some guidance on use of the CHECK-ALTERNATE attribute when 
sending a permission/bind request to a server that was learned via this 
mechanism. I would be quite happy to attempt to incorporate additional 
guidance and/or stronger wording to help influence implementers. Any 
more specific suggestions?

Also, as Justin notes in a separate e-mail, proposals for changes to ICE 
will be forthcoming that should help in this regard. More on that as it 
develops.

--Brandon

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

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 30 Jul 2014 15:10:41 +0000

(Moving this discussion to MMusic.  I suggest further discussion drop the tram list, unless it cycles back around to a TURN-specific issue.)

On Jul 29, 2014, at 1:57 PM, Justin Uberti <[email-masked]> wrote:
> 
> The one thing we need to do is update ICE to allow the CONTROLLING side to make dynamic decisions about which pair to use, instead of being forced to use PRIORITY (which is what 5245 says). I am going to try to write this up before Hawaii. 

This is equivalent to using regular nomination, but saying that an endpoint can send media on any Confirmed candidate pair, not just the Selected one, right?

5245 says that an ICE endpoint MUST be prepared to receive media on any candidate, but only sends on the Selected candidate pair.  I don’t know if this means, in practice, that ICE-bis could change to the behavior I’ve described above and still be backward compatible, or if there’d need to be some sort of ice-option negotiation to indicate that this early media (oh, dread phrase) is acceptable.