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

From: "Aijun Wang" <[email-masked]>
Date: Tue, 6 Jan 2015 14:14:57 +0800

Hi, Brandon.

I read your draft just and wants to ask you some question for clarification:
1. Is it possible for two peers to select different Relay Server to
communicate? If so, will the communication channel between the Relay Server
will be changed by the CHECK-ALTERNATE attribute? If not, how to ensure two
peers select the same Relay Server? 
2. Is it better for ICE server to determine the appropriate Relay Server for
two peers at the beginning of ICE connectivity check? The determination
process can be based on information such as the load status of each Relay
Server, the link usage of its interfaces and the proximity of two
peers(based solely on the reflex-address of each peer).

Best Regards.

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Tuesday, December 30, 2014 6:04 AM
> To: [email-masked]
> Subject: [tram] Fwd: New Version Notification for
> draft-williams-peer-redirect-02.txt
> 
> Hi all,
> 
> I've just updated the peer redirect draft to provide the warning labels
that Ted
> asked for back in Toronto. I also added brief discussion of a load
balancing use
> case when adding a new flow to an existing allocation.
> 
> There's some work going on both here and in mmusic related to ICE that can
> help provide a framework for making more effective use of this redirection
> capability.
> 
> I hope that there might be enough interest in this draft for WG adoption
and
> would like to hear thoughts on that from the list.
> 
> Thanks,
> --Brandon
> 
> -------- Forwarded Message --------
> Subject: New Version Notification for draft-williams-peer-redirect-02.txt
> Date: Mon, 29 Dec 2014 16:53:47 -0500
> 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-02.txt
> has been successfully submitted by Brandon Williams and posted to the IETF
> repository.
> 
> Name:		draft-williams-peer-redirect
> Revision:	02
> Title:		Peer-specific Redirection for Traversal Using Relays
around NAT
> (TURN)
> Document date:	2014-12-29
> Group:		Individual Submission
> Pages:		13
> URL:
> http://www.ietf.org/internet-drafts/draft-williams-peer-redirect-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-williams-peer-redirect/
> Htmlized:       http://tools.ietf.org/html/draft-williams-peer-redirect-02
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-williams-peer-redirect-02
> 
> 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
> 
> 
> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.
> 
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Simon Perreault <[email-masked]>
Date: Tue, 6 Jan 2015 10:36:27 -0500

On Tue, Jan 6, 2015 at 1:14 AM, Aijun Wang <[email-masked]>
wrote:

> communicate?

It's already possible with today's ICE, without this draft. Or do you mean
something else?

> If so, will the communication channel between the Relay Server

Why would it be necessary that the two peers select the same server?

Simon

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 7 Jan 2015 13:57:22 +0800

Hi, Simon:

Please see the reply inline. 

Best Regards.

Aijun

From: Simon Perreault [mailto:[email-masked]] 
Sent: Tuesday, January 06, 2015 11:36 PM
To: Aijun Wang
Cc: Brandon Williams; [email-masked]
Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt

On Tue, Jan 6, 2015 at 1:14 AM, Aijun Wang <[email-masked]> wrote:

It's already possible with today's ICE, without this draft. Or do you mean something else?

【Aijun】: in http://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/, it described only the process that the communication endpoints under one same TURN server. The process for endpoints that under different TURN server is not mentioned and is complex if we allow it happen.

【Aijun】: To simplify the realization of TURN process. Two questions:

1. How do we encapsulate the application data between the TURN servers? Using the “ChannelData Message” or using pure UDP message? 

2. how about the TCP communication channel between two TURN servers?

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 7 Jan 2015 08:56:33 -0500

On Wed, Jan 7, 2015 at 12:57 AM, Aijun Wang <[email-masked]>
wrote:

> 【Aijun】: in http://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/, it
> described only the process that the communication endpoints under one same
> TURN server. The process for endpoints that under different TURN server is
> not mentioned and is complex if we allow it happen.
>

On the contrary, things would be more complex if we tried to disallow it.

> 【Aijun】: To simplify the realization of TURN process.
>

Sorry, I don't see how enforcing that would simplify anything. It would be
nice if it just happened because it would eliminate a leg and the TURN
server could apply hairpinning optimization, but from a protocol point of
view it would be exactly the same thing. Enforcing that this always happen
would actually make the protocol more complex.

> Two questions:
>
> 1. How do we encapsulate the application data between the TURN servers?
> Using the “ChannelData Message” or using pure UDP message?
>

Per the TURN spec it would be pure UDP. Each TURN server would not know it
is talking to another TURN server.

> 2. how about the TCP communication channel between two TURN servers?

Assuming you mean RFC 6062, it would be pure TCP. Each TURN server would
not know it is talking to another TURN server.

Simon

---

From: Brandon Williams <[email-masked]>
Date: Wed, 07 Jan 2015 16:35:16 -0500

see [bw] inline

> peers select the same Relay Server?

[bw] Yes, they can select different relay servers. The mechanism doesn't 
add any new restriction in that regard, nor does it changes the 
communication channel between the servers (there's no need for that). 
Basically, redirect would end up providing a new relay candidate and 
there's some ongoing work in mmusic that will help ICE to make more 
effective use of the new relay candidate.

> peers(based solely on the reflex-address of each peer).

[bw] I'm not sure what you're getting at here. The 3rd party relay 
system has the necessary information to determine whether a redirect 
would be beneficial, so why would it make sense for something else to 
make that determination?

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

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 8 Jan 2015 09:33:09 +0800

Hi, Brandon:

Best Regards.
Aijun Wang.

> Sent: Thursday, January 08, 2015 5:35 AM
> To: Aijun Wang; [email-masked]
> > communicate? If so, will the communication channel between the Relay
> > Server will be changed by the CHECK-ALTERNATE attribute? If not, how
> > to ensure two peers select the same Relay Server?
> 
add
> any new restriction in that regard, nor does it changes the communication
> channel between the servers (there's no need for that).
there's
> some ongoing work in mmusic that will help ICE to make more effective use
of
> the new relay candidate.

[Aijun]: section 2.4 and section 10.1&10.2 of the draft
http://www.ietf.org/id/draft-ietf-tram-turnbis-00.txt describe the process
for transferring data via the TURN server(here we select the brief
description in section 2.4 for discussion):
----------------------------------------------------------------------------
----------------------------------------------
When using the Send mechanism, the client sends a Send indication to
   the TURN server containing (a) an XOR-PEER-ADDRESS attribute
   specifying the (server-reflexive) transport address of the peer and
   (b) a DATA attribute holding the application data.  When the TURN
   server receives the Send indication, it extracts the application data
   from the DATA attribute and sends it in a UDP datagram to the peer,
   using the allocated relay address as the source address.  Note that
   there is no need to specify the relayed transport address, since it
   is implied by the 5-tuple used for the Send indication.

   In the reverse direction, UDP datagrams arriving at the relayed
   transport address on the TURN server are converted into Data
   indications and sent to the client, with the server-reflexive
   transport address of the peer included in an XOR-PEER-ADDRESS
   attribute and the data itself in a DATA attribute.  Since the relayed
transport address uniquely identified the allocation, the server
   knows which client should receive the data.
----------------------------------------------------------------------------
---------------------------------------------------
So, from the client to TURN server, the application data is encapsulated in
the DATA attribute and also the XOR-PEER-ADDRESS should be included. But
from TURN server to the peer, it is one pure UDP datagram, there is no any
STUN attribute included, and the application data is directly on the UDP
data part. Then it is different for application data transfer between
client/server and server/peer pair. 
If we allow the communication pair connected two different TURN servers, how
to transport application data between two TURN servers? Using send
indication or use pure UDP datagram? How does the upstream TURN server know
the transport address of the downstream TURN Server?  

> 
> > 2. Is it better for ICE server to determine the appropriate Relay
> > Server for two peers at the beginning of ICE connectivity check? The
> > determination process can be based on information such as the load
> > status of each Relay Server, the link usage of its interfaces and the
> > proximity of two peers(based solely on the reflex-address of each peer).
> 
> [bw] I'm not sure what you're getting at here. The 3rd party relay system
has
> the necessary information to determine whether a redirect would be
beneficial,
> so why would it make sense for something else to make that determination?
> 

[Aijun]: My concern at here is same as the above question: how the upstream
TURN server knows the transport address of downstream TURN server for one
peer? If ICE can determine the appropriate TURN server for the corresponding
communication pair, then there is no need the server redirect mechanism. Am
I right?

> >> There's some work going on both here and in mmusic related to ICE
> >> that can help provide a framework for making more effective use of
> >> this redirection capability.
> >>
> >> <[email-masked]>, Tirumaleswar Reddy <[email-masked]>,
> >> Williams, Brandon <[email-masked]>
> >>
> >>
> >> has been successfully submitted by Brandon Williams and posted to the
> >> IETF repository.
> >>
> >> Htmlized:
http://tools.ietf.org/html/draft-williams-peer-redirect-02
> >> Brandon Williams; Senior Principal Software Engineer Emerging
> >> Products Engineering; Akamai Technologies Inc.
> >>
> >>

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 8 Jan 2015 14:20:59 +0800

Hi, Simon,

I have covered all your concerns in the response to Mr.Brandon, please refer to it.

Best Regards.

Aijun

From: Simon Perreault [mailto:[email-masked]] 
Sent: Wednesday, January 07, 2015 9:57 PM
To: Aijun Wang
Cc: Brandon Williams; [email-masked]
Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt

On Wed, Jan 7, 2015 at 12:57 AM, Aijun Wang <[email-masked]> wrote:

Sorry, I don't see how enforcing that would simplify anything. It would be nice if it just happened because it would eliminate a leg and the TURN server could apply hairpinning optimization, but from a protocol point of view it would be exactly the same thing. Enforcing that this always happen would actually make the protocol more complex.

Two questions:

Per the TURN spec it would be pure UDP. Each TURN server would not know it is talking to another TURN server.

Assuming you mean RFC 6062, it would be pure TCP. Each TURN server would not know it is talking to another TURN server.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 8 Jan 2015 10:22:22 -0500

> description in section 2.4 for discussion):

I'll just copy my answer to your similar question in another email:

That's not what will happen. There are two allocations on the same server.
Conceptually, the packets will loopback from the first allocation's relayed
address to the second allocation's relayed address, and will then be sent
to host B over the same 5-tuple that host B initially used to send its
allocate request.

A server can also notice when two allocations are talking to each other and
apply hairpinning optimization and avoid looping back real packets.

> the transport address of the downstream TURN Server?

Peer A communicates its relayed address to peer B through ICE. Peer B
includes that address in a Send indication that it sends to its own TURN
server. B's server then sends a raw UDP packet to A's server.

> peer?

(see above)

> If ICE can determine the appropriate TURN server for the corresponding

I don't see how you come to this conclusion. This mechanism has nothing to
do with the 2-servers case. It applies to TURN in general.

Simon

---

From: Brandon Williams <[email-masked]>
Date: Thu, 08 Jan 2015 13:26:33 -0500

See inline ...

> description in section 2.4 for discussion):

[bw] I consider the "(server-reflexive)" to be incorrect. When only one 
peer is using a relay, then this would be the server-reflexive or host 
address, but when both are using relays then it would be the relay address.

> communication pair, then there is no need the server redirect mechanism. Am

[bw] The server knows the relay address of the remote peer via the 
XOR-PEER-ADDRESS attribute, and that is used to direct traffic to the 
downstream relay. The upstream relay doesn't need to know the nature of 
the downstream address, just that this is the address to use to get data 
to the peer.

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 9 Jan 2015 10:28:25 +0800

Hi, Simon, Brandon,

Please see the reply below.

From: Simon Perreault [mailto:[email-masked]] 
Sent: Thursday, January 08, 2015 11:22 PM
To: Aijun Wang
Cc: Brandon Williams; [email-masked]
Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt

On Wed, Jan 7, 2015 at 8:33 PM, Aijun Wang <[email-masked]> wrote:

That's not what will happen. There are two allocations on the same server. Conceptually, the packets will loopback from the first allocation's relayed address to the second allocation's relayed address, and will then be sent to host B over the same 5-tuple that host B initially used to send its allocate request.

A server can also notice when two allocations are talking to each other and apply hairpinning optimization and avoid looping back real packets.

[Aijun]: I also copy the answer in previous mail as below. After these discussion, I think it is better to do one summary of our discussion in these interactive e-mail. 

[Aijun]: No. There is only one allocation on TURN server for each client. Actually, there are two address in TURN server, one is the “Relayed Transport Address” for every client, the other is “TURN Server Transport Address” that is same to every client. (please refer to  the figure 1 in http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-2 )

For data sending process, please refer to http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-16, that described as below:

The client now sends a ChannelData message to the server with data

   destined for Peer B.  The ChannelData message is not a STUN message,

   and thus has no transaction id.  Instead, it has only three fields: a

   channel number, data, and data length; here the channel number field

   is 0x4000 (the channel the client just bound to Peer B).  When the

   server receives the ChannelData message, it checks that the channel

   is currently bound (which it is) and then sends the data onward to

   Peer B in a UDP datagram, using the relayed transport address as the

   source transport address and 192.0.2.210:49191 (the value of the XOR-

   PEER-ADDRESS attribute in the ChannelBind request) as the destination

   transport address. 

It described clearly the “relayed transport address” is used as the source transport address, not the address that the host B send the allocate request. So is it problematic? 

Peer A communicates its relayed address to peer B through ICE. Peer B includes that address in a Send indication that it sends to its own TURN server. B's server then sends a raw UDP packet to A's server.

[Aijun] How the B’s server find A’s server and how the A’s server find A then if you use the raw UDP packet? Under current ICE procedure, Host B will send application data in encapsulate format, together with the XOR-PEER-Address to indicate it want to send to peer A, where is the information of A’s relay? 

has
beneficial,

(see above)

[Aijun] There is no attribute to transfer the well-known TURN Server Transport address now in current ICE RFC/Draft.

I don't see how you come to this conclusion. This mechanism has nothing to do with the 2-servers case. It applies to TURN in general.

[Aijun] Let’s discuss this later after we reach an agreement on the above two questions.

Simon

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 9 Jan 2015 10:40:09 +0800

Hi, Brandon:

Aijun Wang
Best Regards.

> Sent: Friday, January 09, 2015 2:27 AM
> >> any new restriction in that regard, nor does it changes the
> > http://www.ietf.org/id/draft-ietf-tram-turnbis-00.txt describe the
> > process for transferring data via the TURN server(here we select the
> > brief description in section 2.4 for discussion):
> >     attribute and the data itself in a DATA attribute.  Since the
> > relayed transport address uniquely identified the allocation, the server
> > So, from the client to TURN server, the application data is
> > encapsulated in the DATA attribute and also the XOR-PEER-ADDRESS
> > should be included. But from TURN server to the peer, it is one pure
> > UDP datagram, there is no any STUN attribute included, and the
> > application data is directly on the UDP data part. Then it is
> > different for application data transfer between client/server and
server/peer
> pair.
> > If we allow the communication pair connected two different TURN
> > servers, how to transport application data between two TURN servers?
> > Using send indication or use pure UDP datagram? How does the upstream
> > TURN server know the transport address of the downstream TURN Server?
> 
peer is
> using a relay, then this would be the server-reflexive or host address,
but when
> both are using relays then it would be the relay address.
> 

[Aijun]: There are two relay address, one is the TURN server well-known
address, another is the relay address that allocated to each client. Which
one should be used then? On the other hand, when client want to send traffic
to other peer, it does not know whether the other part is under the same
TURN server or not, how do it select this information?

> >> [bw] I'm not sure what you're getting at here. The 3rd party relay
system
> the downstream address, just that this is the address to use to get data

[Aijun]: as the definition in
http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-14.3, the
XOR-PEER-ADDRESS is the address seen from the TURN server, so it can't be
used to find the relay address of the remote peer, and then can't be used to
direct traffic to downstream relay.

---

From: Brandon Williams <[email-masked]>
Date: Fri, 09 Jan 2015 12:12:43 -0500

By relay address, I mean the XOR-RELAYED-ADDRESS returned in the 
allocation request. This clearly identifies the true source and 
destination for the data in the packet as well as the two relay servers 
involved. If both relayed addresses are on the same server, it will of 
course know that and be able to optimize as Simon indicated in an 
earlier e-mail.

--Brandon

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 12 Jan 2015 08:43:03 +0800

Hi, Brandon:

In http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10.1, it is
described as below:

When forming a Send indication, the client MUST include an XOR-PEER-
   ADDRESS attribute and a DATA attribute.  The XOR-PEER-ADDRESS
   attribute contains the transport address of the peer to which the
   data is to be sent, and the DATA attribute contains the actual
   application data to be sent to the peer.

So, there is no XOR-RELAYED-ADDRESS attribute included to identify the
peer's allocated relay address. On the other hand, XOR-RELAYED-ADDRESS is
mainly refer to the requester's allocated relay address, not the
corresponding peer. Will we define again one new attribute, such as
XOR-PEER-RELAYED-ADDRESS to transfer the next TURN server's information?

Even if so, what will be the source address for the packet from the second
TURN server to destination peer? If we use the XOR-RELAYED-ADDRESS, then the
return packet from the peer will be passed back directly to the first TURN
server, results in non-symmetric route. If we use XOR-PEER-RELAYED-ADDRESS,
then what is the source address for the packet from the second TURN server
back to the first TURN server?

Best Regards.

> From: Brandon Williams [mailto:[email-masked]]
> Sent: Saturday, January 10, 2015 1:09 AM
allocation
> request. This clearly identifies the true source and destination for the
data in
> the packet as well as the two relay servers involved. If both relayed
addresses
> are on the same server, it will of course know that and be able to
optimize as
> Simon indicated in an earlier e-mail.
> 
> --Brandon
> 
> > [Aijun]: There are two relay address, one is the TURN server
> > well-known address, another is the relay address that allocated to
> > each client. Which one should be used then? On the other hand, when
> > client want to send traffic to other peer, it does not know whether
> > the other part is under the same TURN server or not, how do it select
this
> information?
> > http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-14.3,
> > the XOR-PEER-ADDRESS is the address seen from the TURN server, so it
> > can't be used to find the relay address of the remote peer, and then
> > can't be used to direct traffic to downstream relay.
> >
> >
> 
> 
> --

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 12 Jan 2015 10:53:36 +0000

Hi Aijun,

TURN was originally written as a backup service when ICE fails. It also did provide fallback when ICE clients wanted to talk to non-ICE clients (But then the default candidate must be set to the relay address. The point is that the allocated public RELAY address on the turn server works as a normal UDP (or TCP if that is in use) port. That means that any client can send its RTP packet or whatever as normal without any knowledge regarding TURN.As long as the client have installed the necessary permissions.

If the to TURN servers are needed due to restricting FWs the traffic between the two public RELAY addresses will be pure UDP or TCP.  No need for any additional information. 

With ICE it might be possible to end up with asymmetrical routing. Not sure how common that is. I am inclined to blame the network if that occurs, ICE only probes and ties to get the packets through. 

I do not understand what you are trying to solve below.

.-.
Pål-Erik

> On 12 Jan 2015, at 01:43, Aijun Wang <[email-masked]> wrote:
> 
> Hi, Brandon:
>

---

From: Brandon Williams <[email-masked]>
Date: Mon, 12 Jan 2015 10:44:53 -0500

XOR-PEER-ADDRESS contains "the transport address of the peer". It is not 
required to be a specific type of address (host, reflexive, or relay). 
It will be any address that can be used to deliver data to the remote 
peer. If two TURN relays are used, then the XOR-PEER-ADDRESS attribute 
in Send and Data indications will contain the remote peer's allocated 
relay address. There is no need the for either of the relays to even be 
aware that the transport address is a relay address.

Consider the following:

A <-> XA <-> TA|RA <-> RB|TB <-> XB <-> B
|              |         |              |
|---- TURN ----|-- UDP --|---- TURN ----|

A and B are the two peers' host addresses.
XA and XB are the two peers' reflexive addresses.
TA and TB are the relay servers' addresses used as the TURN session 
endpoints.
RA and RB are the two peers' allocated relay addresses.

A Send indication from A to TA uses RB as the XOR-PEER-ADDRESS. When A's 
relay receives the Send indication, it sends the data in a plain UDP 
datagram with RA as the source and RB as the destination. When B's relay 
receives the UDP datagram, it sends a Data indication from TB to B with 
RA as the XOR-PEER-ADDRESS.

--Brandon

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 13 Jan 2015 08:50:33 +0800

Hi, Brandon

Thanks for your vivid graph for our discussion. Two questions are raised
here:

1. How does TURN server A decide when to use UDP to send app data, and when
to use TURN to send app data? Which criteria can assistant the TURN server A
to make this decision?
In http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10.2, it
describes the TURN server will send UDP raw packet to the peer, regardless
the peer is awareness or unawareness the existence of TURN.

2. In your example, if TURN B use the DATA indication to B, what will B do
if it does not support the TURN encapsulation?

Best Regards. 

> From: Brandon Williams [mailto:[email-masked]]
> Sent: Monday, January 12, 2015 11:45 PM
peer. If
> two TURN relays are used, then the XOR-PEER-ADDRESS attribute in Send and
> Data indications will contain the remote peer's allocated relay address.
There
> is no need the for either of the relays to even be aware that the
transport
> address is a relay address.
> 
> Consider the following:
> 
datagram
> with RA as the source and RB as the destination. When B's relay receives
the
> UDP datagram, it sends a Data indication from TB to B with RA as the
> XOR-PEER-ADDRESS.
> 
> --Brandon
> 
> > In http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10.1,
> > it is described as below:
> >
> > peer's allocated relay address. On the other hand, XOR-RELAYED-ADDRESS
> > is mainly refer to the requester's allocated relay address, not the
> > Even if so, what will be the source address for the packet from the
> > second TURN server to destination peer? If we use the
> > XOR-RELAYED-ADDRESS, then the return packet from the peer will be
> > passed back directly to the first TURN server, results in
> > non-symmetric route. If we use XOR-PEER-RELAYED-ADDRESS, then what is
> > the source address for the packet from the second TURN server back to
the
> first TURN server?

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 13 Jan 2015 09:28:59 +0800

Hi, Pal:

Best Regards.

> From: tram [mailto:[email-masked]] On Behalf Of Pal Martinsen
> (palmarti)
> Sent: Monday, January 12, 2015 6:54 PM
> To: Aijun Wang
> Cc: [email-masked]; Brandon Williams
> Subject: Re: [tram] New Version Notification for
> TURN was originally written as a backup service when ICE fails. It also did
> provide fallback when ICE clients wanted to talk to non-ICE clients (But then the
> default candidate must be set to the relay address. The point is that the
> allocated public RELAY address on the turn server works as a normal UDP (or
> TCP if that is in use) port. That means that any client can send its RTP packet or
> whatever as normal without any knowledge regarding TURN.As long as the
> client have installed the necessary permissions.

[Aijun]: I agree with it. This is also the mechanism used by current TURN solution. 

> 
> If the to TURN servers are needed due to restricting FWs the traffic between
> the two public RELAY addresses will be pure UDP or TCP.  No need for any
> additional information.

[Aijun]: We should consider not only the communication between the two TURN Servers, but also the procedures from the second TURN server to the destination peer. For more detail discuss, please refer to my previous mail to Brandon, we can discuss it together with that thread.

> 
> With ICE it might be possible to end up with asymmetrical routing. Not sure
> how common that is. I am inclined to blame the network if that occurs, ICE only
> probes and ties to get the packets through.
> 
[Aijun]: The problem of asymmetrical routing is raised by the current ICE/TURN solution, not the fault of network.

> I do not understand what you are trying to solve below.

[Aijun]: Brandon illustrates one good graph for the possible problem that I mentioned here, please refer to it for our ongoing discussion.

> > the source address for the packet from the second TURN server back to the
> first TURN server?
> >
> > Best Regards.
> >

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 13 Jan 2015 08:38:53 +0000

> On 13 Jan 2015, at 01:50, Aijun Wang <[email-masked]> wrote:
> 
> Hi, Brandon
> 

TURN sever A sends “app data” to client A. This is the “private” side of the TURN server. TURN server A sends TURN encapsulated data (data ind or channel) back to client A using the same 5 tuple client A used to send his allocate request. TURN allows the client to use UDP, TCP or TLS to do this. 

What happens on the “public” side of the TURN server is always UDP (Unless the TURN server supports TURN-TCP and the client have asked for a TCP port allocation). 

The remote side do not need to know that it is sending packets to a TURN server, and that the packets would “magically” be sent to the client that allocated that port. Think of TURN as a mechanism to move your box out on the Internet and obtaining public routable IP.  

> if it does not support the TURN encapsulation?
There is no way a TURN server would send data ind to a client without the client having allocated a port.
Without client B sending the allocate request there would not be a binding in the NAT either. 

.-.
Pål-Erik

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 13 Jan 2015 17:28:36 +0800

> Sent: Tuesday, January 13, 2015 4:39 PM
> To: Aijun Wang
> > 1. How does TURN server A decide when to use UDP to send app data, and
> > when to use TURN to send app data? Which criteria can assistant the
> > TURN server A to make this decision?
> > In http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10.2,
> > it describes the TURN server will send UDP raw packet to the peer,
> > regardless the peer is awareness or unawareness the existence of TURN.
> >
> 
> TURN sever A sends “app data” to client A. This is the “private” side of the
> TURN server. TURN server A sends TURN encapsulated data (data ind or
> channel) back to client A using the same 5 tuple client A used to send his
> allocate request. TURN allows the client to use UDP, TCP or TLS to do this.
> 
> What happens on the “public” side of the TURN server is always UDP (Unless
> the TURN server supports TURN-TCP and the client have asked for a TCP port
> allocation).
> 
> The remote side do not need to know that it is sending packets to a TURN
> server, and that the packets would “magically” be sent to the client that
> allocated that port. Think of TURN as a mechanism to move your box out on the
> Internet and obtaining public routable IP.
> 

I agree with you at these points. But my concern focus on the communication channel between TURN Server A/TURN Server B and TURN B/Peer B. In current TURN draft, they all use the pure UDP packet. But in Brandon's graph, they are different: the previous pair use pure UDP datagram, but the latter pair use DATA indication, which is not described in current TURN draft, and will lead the TURN server A be confused, because it might face the TURN Server B and other communication peer, such as peer C that directly connected on the TURN server A.  Which encapsulation method will be used then?

> > 2. In your example, if TURN B use the DATA indication to B, what will
> > B do if it does not support the TURN encapsulation?
> >

Actually true. But my concern here focus still on the data forwarding plane, not the control plane of TURN solution. 

> >> XOR-PEER-ADDRESS contains "the transport address of the peer". It is
> >> not required to be a specific type of address (host, reflexive, or relay).
> >> two TURN relays are used, then the XOR-PEER-ADDRESS attribute in Send
> >> and Data indications will contain the remote peer's allocated relay address.
> > There
> >> A Send indication from A to TA uses RB as the XOR-PEER-ADDRESS. When
> >> A's relay receives the Send indication, it sends the data in a plain
> >> UDP
> > datagram
> >>> In
> >>> http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10.1,
> >>> So, there is no XOR-RELAYED-ADDRESS attribute included to identify
> >>> the peer's allocated relay address. On the other hand,
> >>> XOR-RELAYED-ADDRESS is mainly refer to the requester's allocated
> >>> relay address, not the corresponding peer. Will we define again one
> >>> new attribute, such as XOR-PEER-RELAYED-ADDRESS to transfer the next
> >>> TURN server's
> >> information?
> >>>
> >>> non-symmetric route. If we use XOR-PEER-RELAYED-ADDRESS, then what
> >>> is the source address for the packet from the second TURN server
> >>> back to
> > the
> >> first TURN server?
> >>>
> >>> Best Regards.
> >>>
> >>>>> each client. Which one should be used then? On the other hand,
> >>>>> when client want to send traffic to other peer, it does not know
> >>>>> whether the other part is under the same TURN server or not, how
> >>>>> do it select
> >>> this
> >>>> information?
> >>>>>
> >>>>
> >>>>>
> >>>>> http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-14.3
> >>>>> , the XOR-PEER-ADDRESS is the address seen from the TURN server,
> >>>>> so it can't be used to find the relay address of the remote peer,
> >>>>> and then can't be used to direct traffic to downstream relay.
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 13 Jan 2015 18:54:28 +0000

On 13 Jan 2015, at 10:28, Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
Cc: [email-masked]<mailto:[email-masked]>; Brandon Williams

On 13 Jan 2015, at 01:50, Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Brandon

Thanks for your vivid graph for our discussion. Two questions are
raised
here:

I agree with you at these points. But my concern focus on the communication channel between TURN Server A/TURN Server B and TURN B/Peer B. In current TURN draft, they all use the pure UDP packet. But in Brandon’s graph, they are different: the previous pair use pure UDP datagram, but the latter pair use DATA indication, which is not described in current TURN draft,

Unless I am missing something this is described in section 10.3.

and will lead the TURN server A be confused, because it might face the TURN Server B and other communication peer, such as peer C that directly connected on the TURN server A.  Which encapsulation method will be used then?

UDP. But that requires client a to set the correct permissions to allow traffic from C to be relayed to A.

We are discussing normal TURN operation here? If not I apologise if I have missed something in the discussion.

.-.
Pål-Erik

There is no way a TURN server would send data ind to a client without the
client having allocated a port.
Without client B sending the allocate request there would not be a binding in
the NAT either.

.-.
Pål-Erik

Best Regards.

-----Original Message-----
From: Brandon Williams [mailto:[email-masked]]
Sent: Monday, January 12, 2015 11:45 PM
To: Aijun Wang; [email-masked]<mailto:[email-masked]>
Subject: Re: [tram] Fwd: New Version Notification for

Consider the following:

A Send indication from A to TA uses RB as the XOR-PEER-ADDRESS. When
A's relay receives the Send indication, it sends the data in a plain
UDP
datagram
with RA as the source and RB as the destination. When B's relay
receives
the
UDP datagram, it sends a Data indication from TB to B with RA as the
XOR-PEER-ADDRESS.

--Brandon

In

Best Regards.

-----Original Message-----
From: Brandon Williams [mailto:[email-masked]]
Sent: Saturday, January 10, 2015 1:09 AM
To: Aijun Wang; [email-masked]<mailto:[email-masked]>
Subject: Re: [tram] Fwd: New Version Notification for

By relay address, I mean the XOR-RELAYED-ADDRESS returned in the
allocation
request. This clearly identifies the true source and destination
for the
data in
the packet as well as the two relay servers involved. If both
relayed
addresses
are on the same server, it will of course know that and be able to
optimize as
Simon indicated in an earlier e-mail.

--Brandon

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

---

From: Brandon Williams <[email-masked]>
Date: Tue, 13 Jan 2015 18:09:11 -0500

I agree with Pål-Erik that we're discussing existing TURN functionality 
here. There is no outstanding problem with a use-case involving two TURN 
relay servers, one for each peer. The existing protocol supports this 
just fine.

Maybe the lengthy back-and-forth discussion suggests that there could be 
some value in documenting this particular use case somewhere (turnbis? a 
separate draft?) to help clarify it for future implementers.

--Brandon

On 01/13/2015 01:54 PM, Pal Martinsen (palmarti) wrote:
>
>> On 13 Jan 2015, at 10:28, Aijun Wang <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>> Cc:[email-masked] <mailto:[email-masked]>; Brandon Williams
>>>> On 13 Jan 2015, at 01:50, Aijun Wang <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>> Hi, Brandon
>>>>
>> I agree with you at these points. But my concern focus on the
>> communication channel between TURN Server A/TURN Server B and TURN
>> B/Peer B. In current TURN draft, they all use the pure UDP packet. But
>> in Brandon’s graph, they are different: the previous pair use pure UDP
>> datagram, but the latter pair use DATA indication, which is not
>> described in current TURN draft,
>
>> and will lead the TURN server A be confused, because it might face the
>> TURN Server B and other communication peer, such as peer C that
>> directly connected on the TURN server A.  Which encapsulation method
>> will be used then?
>>
>
>> Actually true. But my concern here focus still on the data forwarding
>> plane, not the control plane of TURN solution.
>>
>>> .-.
>>> Pål-Erik
>>>
>>>
>>>> Best Regards.
>>>>
>>>>
>>>>> To: Aijun Wang; [email-masked] <mailto:[email-masked]>
>>>>>>> To: Aijun Wang; [email-masked] <mailto:[email-masked]>
>>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 14 Jan 2015 09:55:24 +0800

Hi, Brandon & pal:

Let's consider the following graph:

A <-> XA <-> TA|RA <-> RB|TB <-> XB <-> B
|           |        |           |
|           |                    |
|           |                    |
|           +----------XC<--->C       |
|                                |
|---- TURN -----|--- UDP --|---- TURN --------|

If there is another peer(peer C) connected directly to TURN Server A at the same time, then TURN Server A will use also the pure UDP packet to relay data from A to C. Then, how this packet pass through the EDM NAT device that locates before peer C?  Peer C only send request packet to TURN Server A's TA address previously.

Actually, I consider current TURN draft only consider the scenarios that there exist only one TURN Server, and will lead more complex design if it want to solve the TURN-to-TURN at the same time.

Best Regards.
Aijun Wang

> Sent: Wednesday, January 14, 2015 7:09 AM
> To: Aijun Wang
> Cc: [email-masked]
> I agree with Pål-Erik that we're discussing existing TURN functionality here.
> There is no outstanding problem with a use-case involving two TURN relay
> servers, one for each peer. The existing protocol supports this just fine.
> 
> >>>> 1. How does TURN server A decide when to use UDP to send app data,
> >>>> and when to use TURN to send app data? Which criteria can assistant
> >>>> the TURN server A to make this decision?
> >>>> In
> >>>> http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10.2,
> >>> TURN sever A sends “app data” to client A. This is the “private”
> >>> side of the TURN server. TURN server A sends TURN encapsulated data
> >>> (data ind or
> >>> channel) back to client A using the same 5 tuple client A used to
> >>> send his allocate request. TURN allows the client to use UDP, TCP or
> >>> TLS to do this.
> >>>
> >>> What happens on the “public” side of the TURN server is always UDP
> >>> (Unless the TURN server supports TURN-TCP and the client have asked
> >>> for a TCP port allocation).
> >>>
> >>> The remote side do not need to know that it is sending packets to a
> >>> TURN server, and that the packets would “magically” be sent to the
> >>> client that allocated that port. Think of TURN as a mechanism to
> >>> move your box out on the Internet and obtaining public routable IP.
> >>>
> >>
> >> B/Peer B. In current TURN draft, they all use the pure UDP packet.
> >> But in Brandon’s graph, they are different: the previous pair use
> >> pure UDP datagram, but the latter pair use DATA indication, which is
> >> not described in current TURN draft,
> >
> >> and will lead the TURN server A be confused, because it might face
> >> the TURN Server B and other communication peer, such as peer C that
> >>>> 2. In your example, if TURN B use the DATA indication to B, what
> >>>> will B do if it does not support the TURN encapsulation?
> >>>>
> >>> There is no way a TURN server would send data ind to a client
> >>> without the client having allocated a port.
> >>>>> XOR-PEER-ADDRESS contains "the transport address of the peer". It
> >>>>> is not required to be a specific type of address (host, reflexive,
> >>>>> or relay).
> >>>>> two TURN relays are used, then the XOR-PEER-ADDRESS attribute in
> >>>>> Send and Data indications will contain the remote peer's allocated
> >>>>> relay address.
> >>>> There
> >>>>> TA and TB are the relay servers' addresses used as the TURN
> >>>>> session endpoints.
> >>>>> A Send indication from A to TA uses RB as the XOR-PEER-ADDRESS.
> >>>>> When A's relay receives the Send indication, it sends the data in
> >>>>> a plain UDP
> >>>> datagram
> >>>>> UDP datagram, it sends a Data indication from TB to B with RA as
> >>>>> the XOR-PEER-ADDRESS.
> >>>>>
> >>>>> --Brandon
> >>>>>
> >>>>>> So, there is no XOR-RELAYED-ADDRESS attribute included to
> >>>>>> identify the peer's allocated relay address. On the other hand,
> >>>>>> relay address, not the corresponding peer. Will we define again
> >>>>>> one new attribute, such as XOR-PEER-RELAYED-ADDRESS to transfer
> >>>>>> the next TURN server's
> >>>>> information?
> >>>>>>
> >>>>>> Even if so, what will be the source address for the packet from
> >>>>>> the second TURN server to destination peer? If we use the
> >>>>>> non-symmetric route. If we use XOR-PEER-RELAYED-ADDRESS, then
> >>>>>> what is the source address for the packet from the second TURN
> >>>>>> server back to
> >>>> the
> >>>>> first TURN server?
> >>>>>>
> >>>>>> Best Regards.
> >>>>>>
> >>>>>>>> well-known address, another is the relay address that allocated
> >>>>>>>> to each client. Which one should be used then? On the other
> >>>>>>>> hand, when client want to send traffic to other peer, it does
> >>>>>>>> not know whether the other part is under the same TURN server
> >>>>>>>> or not, how do it select
> >>>>>> this
> >>>>>>> information?
> >>>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-1
> >>>>>>>> 4.3 , the XOR-PEER-ADDRESS is the address seen from the TURN
> >>>>>>>> server, so it can't be used to find the relay address of the
> >>>>>>>> remote peer, and then can't be used to direct traffic to
> >>>>>>>> downstream relay.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 14 Jan 2015 08:00:59 +0000

> On 14 Jan 2015, at 02:55, Aijun Wang <[email-masked]> wrote:
> 
> Hi, Brandon & pal:
> 
> If there is another peer(peer C) connected directly to TURN Server A at the same time, then TURN Server A will use also the pure UDP packet to relay data from A to C.
Close. The packet will be TURN encapsulated from A to TA, and then from TA to C pure UDP. 

> Then, how this packet pass through the EDM NAT device that locates before peer C?  Peer C only send request packet to TURN Server A’s
> TA address previously.
> 
That is a problem client C needs to handle. Probably by using its own TURN server. ICE will also help in this case and might render any of the TURN servers redundant.

> Actually, I consider current TURN draft only consider the scenarios that there exist only one TURN Server, and will lead more complex design if it want to solve the TURN-to-TURN at the same time.

I disagree. The current suite of ICE/TURN/STUN RFCs do support this nicely. I do not think further discussion on the list is appropriate, but will be happy to have a chat during the next IETF meeting explaining things. 

.-.
Pål-Erik

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 14 Jan 2015 16:53:45 +0800

Hi, Pal:

> Sent: Wednesday, January 14, 2015 4:01 PM
> To: Aijun Wang
> > If there is another peer(peer C) connected directly to TURN Server A at the
> same time, then TURN Server A will use also the pure UDP packet to relay data
> from A to C.

Why TURN Server A send packet to C via TA, but send packet to TURN Server B via RA? This problem may be subtle, but it influence the solution of several scenarios.

> > Then, how this packet pass through the EDM NAT device that locates
> > before peer C?  Peer C only send request packet to TURN Server A’s TA
> address previously.
> >
> That is a problem client C needs to handle. Probably by using its own TURN
> server. ICE will also help in this case and might render any of the TURN servers
> redundant.
> 
> > Actually, I consider current TURN draft only consider the scenarios that there
> exist only one TURN Server, and will lead more complex design if it want to
> solve the TURN-to-TURN at the same time.
> >
> 
> I disagree. The current suite of ICE/TURN/STUN RFCs do support this nicely. I
> do not think further discussion on the list is appropriate, but will be happy to
> have a chat during the next IETF meeting explaining things.

Ok, If possible, we can discuss this more detail face to face, but the mail exchange is also one channel to think it deeply and can assist us design one more lightweight solution.
> >> There is no outstanding problem with a use-case involving two TURN
> >> relay servers, one for each peer. The existing protocol supports this just fine.
> >>
> >> Maybe the lengthy back-and-forth discussion suggests that there could
> >> be some value in documenting this particular use case somewhere
> >> (turnbis? a separate draft?) to help clarify it for future implementers.
> >>
> >> --Brandon
> >>
> >>>>>> 1. How does TURN server A decide when to use UDP to send app
> >>>>>> data, and when to use TURN to send app data? Which criteria can
> >>>>>> assistant the TURN server A to make this decision?
> >>>>>> In
> >>>>>> http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10.
> >>>>>> 2, it describes the TURN server will send UDP raw packet to the
> >>>>>> peer, regardless the peer is awareness or unawareness the
> >>>>>> existence of TURN.
> >>>>>>
> >>>>>
> >>>>> side of the TURN server. TURN server A sends TURN encapsulated
> >>>>> data (data ind or
> >>>>> send his allocate request. TURN allows the client to use UDP, TCP
> >>>>> or TLS to do this.
> >>>>>
> >>>>> (Unless the TURN server supports TURN-TCP and the client have
> >>>>> asked for a TCP port allocation).
> >>>>>
> >>>>> The remote side do not need to know that it is sending packets to
> >>>>> a TURN server, and that the packets would “magically” be sent to
> >>>>> the client that allocated that port. Think of TURN as a mechanism
> >>>>> to move your box out on the Internet and obtaining public routable IP.
> >>>>>
> >>>>
> >>>> pure UDP datagram, but the latter pair use DATA indication, which
> >>>> is not described in current TURN draft,
> >>>
> >>>> directly connected on the TURN server A.  Which encapsulation
> >>>> method will be used then?
> >>>>
> >>>
> >>> We are discussing normal TURN operation here? If not I apologise if
> >>> I have missed something in the discussion.
> >>>
> >>> .-.
> >>> Pål-Erik
> >>>
> >>>
> >>>
> >>>>>
> >>>>
> >>>>
> >>>> Actually true. But my concern here focus still on the data
> >>>> forwarding plane, not the control plane of TURN solution.
> >>>>
> >>>>> .-.
> >>>>> Pål-Erik
> >>>>>
> >>>>>
> >>>>>> Best Regards.
> >>>>>>
> >>>>>>
> >>>>>>> XOR-PEER-ADDRESS contains "the transport address of the peer".
> >>>>>>> It is not required to be a specific type of address (host,
> >>>>>>> reflexive, or relay).
> >>>>>>> Send and Data indications will contain the remote peer's
> >>>>>>> allocated relay address.
> >>>>>> There
> >>>>>>> When A's relay receives the Send indication, it sends the data
> >>>>>>> in a plain UDP
> >>>>>> datagram
> >>>>>>>> When forming a Send indication, the client MUST include an
> >>>>>>>> XOR-PEER-  ADDRESS attribute and a DATA attribute.  The
> >>>>>>>> XOR-PEER-ADDRESS  attribute contains the transport address of
> >>>>>>>> the peer to which the  data is to be sent, and the DATA
> >>>>>>>> attribute contains the actual  application data to be sent to the
> peer.
> >>>>>>>>
> >>>>>>>> XOR-RELAYED-ADDRESS is mainly refer to the requester's
> >>>>>>>> allocated relay address, not the corresponding peer. Will we
> >>>>>>>> define again one new attribute, such as
> >>>>>>>> XOR-RELAYED-ADDRESS, then the return packet from the peer will
> >>>>>>>> be passed back directly to the first TURN server, results in
> >>>>>>>>>> well-known address, another is the relay address that
> >>>>>>>>>> allocated to each client. Which one should be used then? On
> >>>>>>>>>> the other hand, when client want to send traffic to other
> >>>>>>>>>> peer, it does not know whether the other part is under the
> >>>>>>>>>> same TURN server or not, how do it select
> >>>>>>>> this
> >>>>>>>>> information?
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 14 Jan 2015 10:36:39 +0000

On 14 Jan 2015, at 09:53, Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Pal:

-----Original Message-----

On 14 Jan 2015, at 02:55, Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Brandon & pal:

If there is another peer(peer C) connected directly to TURN Server A at the
same time, then TURN Server A will use also the pure UDP packet to relay data
from A to C.
Close. The packet will be TURN encapsulated from A to TA, and then from TA to
C pure UDP.

My mistake. Packets to C goes from RA.

Assuming TA is the “private” side of the TURN server an RA is the “public”.

The only one that is able “speak” to the 5-tuple TA is A that did send the allocate request.

The problem is we are not discussing. We are trying to tell you that this is already covered in the existing suite of RFCs.

.-.
Pål-Erik

.-.
Pål-Erik

Best Regards.
Aijun Wang

-----Original Message-----
From: Brandon Williams [mailto:[email-masked]]
Sent: Wednesday, January 14, 2015 7:09 AM
To: Aijun Wang
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [tram] New Version Notification for

--Brandon

On 13 Jan 2015, at 10:28, Aijun Wang <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

-----Original Message-----
From: tram [mailto:[email-masked]] On Behalf Of Pal
Martinsen
(palmarti)
Sent: Tuesday, January 13, 2015 4:39 PM
To: Aijun Wang
Cc:[email-masked]<http://ietf.org> <mailto:[email-masked]>; Brandon Williams
Subject: Re: [tram] New Version Notification for
draft-williams-peer-redirect-02.txt

On 13 Jan 2015, at 01:50, Aijun Wang <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

Hi, Brandon

communication channel between TURN Server A/TURN Server B and
TURN

UDP. But that requires client a to set the correct permissions to
allow traffic from C to be relayed to A.

.-.
Pål-Erik

There is no way a TURN server would send data ind to a client
without the client having allocated a port.
Without client B sending the allocate request there would not be a
binding in the NAT either.

.-.
Pål-Erik

Best Regards.

-----Original Message-----
From: Brandon Williams [mailto:[email-masked]]
Sent: Monday, January 12, 2015 11:45 PM
To: Aijun Wang; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
Subject: Re: [tram] Fwd: New Version Notification for

XOR-PEER-ADDRESS contains "the transport address of the peer".
It is not required to be a specific type of address (host,
reflexive, or relay).
It will be any address that can be used to deliver data to the
remote
peer. If
two TURN relays are used, then the XOR-PEER-ADDRESS attribute in
Send and Data indications will contain the remote peer's
allocated relay address.
There
is no need the for either of the relays to even be aware that
the
transport
address is a relay address.

Consider the following:

--Brandon

In
1,

XOR-PEER-RELAYED-ADDRESS to transfer the next TURN server's
information?

Best Regards.

-----Original Message-----
From: Brandon Williams [mailto:[email-masked]]
Sent: Saturday, January 10, 2015 1:09 AM
To: Aijun Wang; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
Subject: Re: [tram] Fwd: New Version Notification for

By relay address, I mean the XOR-RELAYED-ADDRESS returned in
the
allocation
request. This clearly identifies the true source and
destination for the
data in
the packet as well as the two relay servers involved. If both
relayed
addresses
are on the same server, it will of course know that and be
able to
optimize as
Simon indicated in an earlier e-mail.

--Brandon

http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section
-1

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

---

From: Brandon Williams <[email-masked]>
Date: Wed, 14 Jan 2015 11:10:44 -0500

> Ok, If possible, we can discuss this more detail face to face, but the mail exchange is also one channel to think it deeply and can assist us design one more lightweight solution.

I also don't see much value in continuing this discussion on the list, 
because I'm not getting the sense the e-mail exchange is bringing 
additional clarity. A face-to-face discussion in Dallas will probably 
resolve this quite quickly.

--Brandon

---

From: Brandon Williams <[email-masked]>
Date: Fri, 16 Jan 2015 09:36:07 -0500

Hi Aijun,

If both A and C are using TA as their TURN relay address, they will 
still each get a different allocated relay address (call them RA and 
RC). Traffic from B or C to A will use RA as the XOR-PEER-ADDRESS value 
and traffic from A or B to C will use RC as the XOR-PEER-ADDRESS value. 
In this way, TA can clearly identify the intended recipient of any pure 
UDP packet arriving on a relay address. Neither of the TURN relays is 
required to "know" that the remote peer is using a relay, although relay 
TA could optimize communication between A and C if it recognizes that 
both peers' relay addresses are local.

No changes are required to the existing RFCs in order to facilitate this 
communication. All that is required is for each of the peers to specify 
the correct XOR-PEER-ADDRESS. The client may know the nature of the 
specified address, but the relay server does not need to know.

--Brandon

PS: As I suggested in an earlier e-mail, I'm not getting the sense that 
e-mail communication is proving to be effective at resolving this issue. 
I think this same question has been answered multiple times in different 
ways, and further related questions on the list will be 
counterproductive. I don't want to discourage you or anyone from asking 
questions on the list about how this stuff works, but I think this 
particular issue will be resolved more easily face-to-face in Dallas.

On 01/16/2015 04:53 AM, Aijun Wang wrote:
> Hi, Pal:
>
> http://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/?include_text=1
> has the following describes:
>
> “…The TURN protocol was designed to be used as part of the ICE
>
>     (Interactive Connectivity Establishment) approach to NAT traversal,
>
>     though it also can be used without ICE.”
>
>  From our discussion or your teaching in previous mail, It is obviously
> that TURN can’t worked alone itself. It need additional process for UDP
> packet to pass through NAT before C----as you said, “…That is a problem
> client C needs to handle. Probably by using its own TURN server. ICE
> will also help in this case and might render any of the TURN servers
> redundant…)
>
> For TCP transport, this will be even worse, because TCP requires first
> the channel being built before peer can exchange STUN/TURN packet. But
> the TCP channel will not be built successfully due to TURN server
> allocates specific relay address for every client, which is also
> different from the TURN server’s well-known address that is used to
> receive the Send Indication.
>
> Even for UDP transport as that described in current TURN/ICE, Let’s
> suppose C can receive the UDP packet( NAT device has been punched via
> other means), and C will send back the return packet via also UDP
> packet,  which destination will be RA. Then the TURN Server will see a
>   XOR-PEER-ADDRESS(XC’) of client C that is different from the value XC,
> this will then influence the procedure of permission control on TURN
> Server established before.
>
> Have you ever consider these situations? If possible, I can explain the
> detail process later when we meet the upcoming IETF conference.
>
> Best Regards.
>
> Aijun Wang.
>
> *From:*Pal Martinsen (palmarti) [mailto:[email-masked]]
> *Sent:* Wednesday, January 14, 2015 6:37 PM
> *To:* Aijun Wang
> *Cc:* [email-masked] <mailto:[email-masked]>; Brandon Williams
> *Subject:* Re: [tram] New Version Notification for
>     On 14 Jan 2015, at 09:53, Aijun Wang <[email-masked]
>     On 14 Jan 2015, at 02:55, Aijun Wang <[email-masked]
>     Why TURN Server A send packet to C via TA, but send packet to TURN
>     Server B via RA? This problem may be subtle, but it influence the
>     solution of several scenarios.
>
> Assuming TA is the “private”side of the TURN server an RA is the “public”.
>
> The only one that is able “speak”to the 5-tuple TA is A that did send
> the allocate request.
>
>
> Ok, If possible, we can discuss this more detail face to face, but the
> mail exchange is also one channel to think it deeply and can assist us
> design one more lightweight solution.
>
> The problem is we are not discussing. We are trying to tell you that
> this is already covered in the existing suite of RFCs.
>
> .-.
>
> Pål-Erik
>
>
>

---

From: Brandon Williams <[email-masked]>
Date: Fri, 16 Jan 2015 11:35:18 -0500

Oops ... just to be clear ... I meant "If both A and C are using TA as 
their TURN server address", meaning that's the other side of the TURN 
5-tuple.