Subject: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-00.txt

From: Brandon Williams <[email-masked]>
Date: Fri, 04 Apr 2014 12:59:35 -0400

Hi all,

I have just submitted the following draft that describes a peer-specific 
redirection mechanism for TURN. Comments would be appreciated.

Cheers,
--Brandon

-------- Original Message --------
Subject: New Version Notification for draft-williams-peer-redirect-00.txt
Date: Fri, 4 Apr 2014 12:57:19 -0400
From: [email-masked] <[email-masked]>
To: Williams, Brandon <[email-masked]>, Tirumaleswar Reddy 
<[email-masked]>, Tirumaleswar Reddy <[email-masked]>, Williams, 
Brandon <[email-masked]>

A new version of I-D, draft-williams-peer-redirect-00.txt
has been successfully submitted by Brandon Williams and posted to the
IETF repository.

Name:		draft-williams-peer-redirect
Revision:	00
Title:		Peer-specific Redirection for Traversal Using Relays around NAT 
(TURN)
Document date:	2014-04-04
Group:		Individual Submission
Pages:		11
URL: 
http://www.ietf.org/internet-drafts/draft-williams-peer-redirect-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-williams-peer-redirect/
Htmlized:       http://tools.ietf.org/html/draft-williams-peer-redirect-00

Abstract:
    This specification describes a peer-specific redirection method that
    allows the TURN server to redirect a client for the purpose of
    improving communication with a specific peer without negatively
    affecting communication with other peers.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Simon Perreault <[email-masked]>
Date: Fri, 04 Apr 2014 13:35:22 -0400

> redirection mechanism for TURN. Comments would be appreciated.

Interesting!

I found the problem statement very clear. As I was reading it I imagined 
a simple solution. When I got to the solution description I was a bit 
surprised by its complexity.

- Why is CHECK-ALTERNATE needed? (I think I can guess why, but this 
needs to be spelled out in any case.)

- Why is XOR-OTHER-ADDRESS needed? Without it, each of your peer's 
candidates would be redirected or not independently. For example, a 
peer's server-reflexive candidate could be located very far from a 
peer's relayed candidate and end up going through a different TURN 
server. Why do they need to go through the same server? What's wrong 
with being redirected to different servers for different candidates?

Non-technical comments to be sent unicast shortly...

Simon

---

From: Brandon Williams <[email-masked]>
Date: Fri, 04 Apr 2014 15:31:18 -0400

Thanks for the comments Simon.

re: CHECK-ALTERNATE
CHECK-ALTERNATE serves two purposes: backward compatibility and client 
flexibility. The client flexibility goal is spelled out in the 
introduction, though I can see that the relationship between that 
statement and the definition of the attribute isn't clearly stated. i 
see now that the backward compatibility (prevent transmission of the 
ALTERNATE-SERVER attribute to a client that doesn't support this use) 
isn't stated anywhere. I'll be sure to clarify those points in the next 
revision.

re: XOR-OTHER-ADDRESS
In a case where both clients to use TURN servers, you want them to 
converge as quickly as possible on the pair that will provide the best 
performance. Typically, the system will attempt to get them to use the 
same relay server. If each one picks the TURN server that is best based 
on its peer's relay address but the relay server was a bad pick in the 
first place, then you'll frequently end up with a bad alternate and 
never converge on a good pair. I think it requires a more complicated 
example than the one in the introduction to really spell this out.

Consider this case (T == TURN relay; P == peer):

           T1 <-- P1            T2            P2 --> T3

If T1, T2, and T3 are all part of the same system and P2 asks T3 for an 
alternate server to get to T1, the system will most likely send it to T1 
in order to avoid unnecessary relay hops. Likewise, if P1 asks T1 for an 
alternate to T3, it will get T3. They would get a more optimal 
end-to-end connection, but not the best end-to-end connection, since in 
this case, you want them to converge on T2.

I think you could probably get to the same decision using the combined 
set of responses for both the server-reflexive candidate and the relayed 
candidate, but I think that the addition of this attribute can help the 
system to get you there faster.

Do you have thoughts on this rationale? If it seems reasonable, then 
I'll add some detail about it to the next revision.

--Brandon

On 04/04/2014 01:35 PM, Simon Perreault wrote:
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

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

---

From: Simon Perreault <[email-masked]>
Date: Mon, 07 Apr 2014 09:55:24 -0400

Le 2014-04-04 15:31, Brandon Williams a écrit :
> statement and the definition of the attribute isn't clearly stated.

Assuming you're referring to this part:

   The client application indicates the nature of the desired
   response, which allows the client to treat the alternate server
   selection as either a requirement or a suggestion.  This flexibility
   gives the client the option to choose the best way for the
   Interactive Connectivity Establishment (ICE) protocol [RFC5245] to
   respond (e.g. discarding the existing relay candidate for
   communication with this peer versus evaluating the two candidate
   servers using ICE connectivity checks and selecting the best one).

Why does the client need this flexibility? What kind of external
stimulus would cause the client to behave one way or the other?

> i see now that the backward compatibility (prevent transmission of the

Right, the ALTERNATE-SERVER mechanism as defined in RFC 5389 is
optional. The problem is that there is no way for the server to know
whether the client implements it or not. I see the need for capability
signalling.

> I'll add some detail about it to the next revision.

Well, in this particular example:

- I understand why having both TURN sessions terminate on the same
server is optimal.

- I don't see how T2 is better than T1 or T3, assuming that T1 (resp.
T3) is "close" to P1 (resp. P3). As long as triangle routing is avoided,
it doesn't really matter that the TURN server be halfway between the
two. As long as it is close to the best path between P1 and P2, it's
optimal. Is that understanding correct?

So my thinking is that since all TURN servers are under the same
administrative entity, we can expect that each server knows about the
others' IP addresses, and can redirect intelligently on a
CreatePermission or ChannelBind request containing one of the TURN
servers' IP address in the XOR-PEER-ADDRESS attribute. That is, it would
redirect the client to the peer's TURN server so that both TURN sessions
are terminated on the same server. So I don't see a need for
XOR-OTHER-ADDRESS in this case either.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Brandon Williams <[email-masked]>
Date: Mon, 07 Apr 2014 10:48:43 -0400

> stimulus would cause the client to behave one way or the other?

I see two different primary criteria: session establishment time vs 
simplicity.

If you want to optimize for faster session establishment, then you would 
want to receive a "hint" that tells you where you will get better 
service. This allows you to continue using the existing-but-suboptimal 
allocation/binding while you are setting up the new allocation/binding. 
This potentially has greater associated internal complexity, since 
you've got to maintain multiple active associated sessions for the peer 
pairing and figure out when it's OK to switch over.

If you want to optimize for internal simplicity, then you probably just 
want to get an error response and deal with the associated offer 
updates, etc. There's only one activity to manage for the peer pairing 
at any particular point in time. You risk taking a bit longer for 
session establishment, but that might be a reasonable trade-off.

The choice also has something to do with the application provider's 
relationship to the relay provider, I think. A higher trust relationship 
on the performance side could lead the application provider to desire 
the simplicity of just switching over to another allocation/binding as 
quickly as possible. A lower trust relationship (I know you think this 
relay is better, but I want to check that myself) could lead the 
application provider to want to run tests and make an internal decision 
about which one to use.

 > XOR-OTHER-ADDRESS in this case either.

You're right that as long as the relay server for at least one of the 
peers is very close to the peer itself, then that relay server will end 
up being the best candidate (or at least a very good one). However, if 
both of the current relay servers would end up resulting in triangle 
routing, it's important to be able to figure that out, which requires 
that you know both relay addresses and both peer addresses.

--Brandon

---

From: Brandon Williams <[email-masked]>
Date: Mon, 07 Apr 2014 11:24:33 -0400

I suppose an alternative to allowing the client to signal the expected 
response type would be to always make it an error response. The client 
would send one request with the CHECK-ALTERNATE attribute and if the 
client still wishes to go ahead with this relay until the other relay is 
available, it could do so by sending a second request without the 
attribute. That would require an extra RTT in the use case where the 
client is trying to get the session set up faster, so it didn't seem 
ideal to me.

--Brandon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 8 Apr 2014 05:14:59 +0000

The other use case for supporting both modes is that, endpoint supports Trickle ICE

1) Let's say remote peer also supports Trickle ICE. In this case error response will be useful, because endpoints would initially only advertise host candidates. Thus both endpoints can learn the best suited TURN server using the remote peer's host address (Public IPv6 address). If PCP is used then server-reflexive candidates could also be learnt and advertised before relayed candidates and thus the alternate TURN server could be discovered using remote peer's host/server-reflexive candidates. This way client has to advertise the relayed candidate only once.

2) Remote peer does not support Trickle ICE. If both endpoints want faster call setup then hint approach will be useful. If local relayed candidate is nominated for media streams then ICE restart could be used to test and migrate the media session to the relayed candidate learnt from the alternate TURN server.
 
-Tiru

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Monday, April 07, 2014 8:19 PM
> To: [email-masked]
> Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-
> redirect-00.txt
> 
>  > Why does the client need this flexibility? What kind of external  > stimulus
> would cause the client to behave one way or the other?
> 
> I see two different primary criteria: session establishment time vs simplicity.
> 
> If you want to optimize for faster session establishment, then you would want to
> receive a "hint" that tells you where you will get better service. This allows you
> to continue using the existing-but-suboptimal allocation/binding while you are
> setting up the new allocation/binding.
> This potentially has greater associated internal complexity, since you've got to
> maintain multiple active associated sessions for the peer pairing and figure out
> when it's OK to switch over.
> 
> If you want to optimize for internal simplicity, then you probably just want to get
> an error response and deal with the associated offer updates, etc. There's only
> one activity to manage for the peer pairing at any particular point in time. You
> risk taking a bit longer for session establishment, but that might be a reasonable
> trade-off.
> 
> The choice also has something to do with the application provider's relationship
> to the relay provider, I think. A higher trust relationship on the performance side
> could lead the application provider to desire the simplicity of just switching over
> to another allocation/binding as quickly as possible. A lower trust relationship (I
> know you think this relay is better, but I want to check that myself) could lead
> the application provider to want to run tests and make an internal decision
> about which one to use.
> 
>  > T3) is "close" to P1 (resp. P3). As long as triangle routing is avoided,  > it
> doesn't really matter that the TURN server be halfway between the  > two. As
> long as it is close to the best path between P1 and P2, it's  > optimal. Is that
> understanding correct?
>  >
>  > So my thinking is that since all TURN servers are under the same  >
> administrative entity, we can expect that each server knows about the  > others'
> IP addresses, and can redirect intelligently on a  > CreatePermission or
> ChannelBind request containing one of the TURN  > servers' IP address in the
> XOR-PEER-ADDRESS attribute. That is, it would  > redirect the client to the peer's
> TURN server so that both TURN sessions  > are terminated on the same server.
> So I don't see a need for  > XOR-OTHER-ADDRESS in this case either.
> 
> You're right that as long as the relay server for at least one of the peers is very
> close to the peer itself, then that relay server will end up being the best
> candidate (or at least a very good one). However, if both of the current relay
> servers would end up resulting in triangle routing, it's important to be able to
> figure that out, which requires that you know both relay addresses and both peer
> addresses.
> 
> --Brandon
> 
> >> CHECK-ALTERNATE serves two purposes: backward compatibility and
> >> client flexibility. The client flexibility goal is spelled out in the
> >> i see now that the backward compatibility (prevent transmission of
> >> the ALTERNATE-SERVER attribute to a client that doesn't support this
> >> use) isn't stated anywhere. I'll be sure to clarify those points in
> >> the next revision.
> >
> >> converge as quickly as possible on the pair that will provide the
> >> best performance. Typically, the system will attempt to get them to
> >> use the same relay server. If each one picks the TURN server that is
> >> best based on its peer's relay address but the relay server was a bad
> >> pick in the first place, then you'll frequently end up with a bad
> >> alternate and never converge on a good pair. I think it requires a
> >> more complicated example than the one in the introduction to really spell this
> out.
> >>
> >> If T1, T2, and T3 are all part of the same system and P2 asks T3 for
> >> an alternate server to get to T1, the system will most likely send it
> >> to T1 in order to avoid unnecessary relay hops. Likewise, if P1 asks
> >> T1 for an alternate to T3, it will get T3. They would get a more
> >> optimal end-to-end connection, but not the best end-to-end
> >> connection, since in this case, you want them to converge on T2.
> >>
> >> I think you could probably get to the same decision using the
> >> combined set of responses for both the server-reflexive candidate and
> >> the relayed candidate, but I think that the addition of this
> >> attribute can help the system to get you there faster.
> >>
> > T3) is "close" to P1 (resp. P3). As long as triangle routing is
> > avoided, it doesn't really matter that the TURN server be halfway
> > between the two. As long as it is close to the best path between P1
> > and P2, it's optimal. Is that understanding correct?
> >
> > servers' IP address in the XOR-PEER-ADDRESS attribute. That is, it
> > would redirect the client to the peer's TURN server so that both TURN
> > sessions are terminated on the same server. So I don't see a need for
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.
>