Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN)

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 18 Mar 2014 10:13:15 +0000

My initial comments

1) Introduction

Secondly,  with fewer local host ports there will be fewer NAT bindings for the NAT to keep track of, and fewer server reflexive candidates.

Comment> 
This benefits IPv4 only hosts and the above sentence may not be applicable for dual-stack hosts.  With IPv6 there will no NAT or even with NPTv6 it's just 1:1 mapping. Dual-stack host let's say behind both NAT44 and NPTv6, cannot use single ALLOCATE request to learn both relayed and server-reflexive addresses for both families. 

Additional details when client should use this mechanism will be helpful.

2)  If the Allocate Response contains only one XOR-RELAYED-ADDRESS
   attribute, then the client knows that the TURN server does not
   support SSODA.  The client can retry the missing address family
   allocations on new 5-tuples, if desired.  Subsequent Allocate
   requests towards the same TURN server SHOULD NOT include multiple
   REQUESTED-ADDRESS-FAMILY attributes

Comment>  
How will the client ever know that the server has upgraded and now supports the new mechanism proposed in the draft ?
May be the client once in a day can probe and find if the server supports multiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request.

3) Security Considerations section is missing. (Section 2.2 is assuming client has already authenticated)

4) How does this mechanism reduce the number of candidates gathered during the discovery process ?

5) Section 2.3
 
  The allocated non-ANY address can be used, but the client
   SHOULD NOT try to allocate any of the unsupported families on a
   different 5-tuple.

Comment> I guess the above line does not hold good for errors like "Insufficient capacity".

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Pal Martinsen (palmarti)
Sent: Monday, March 17, 2014 4:25 PM
To: [email-masked]
Subject: [tram] SSODA (Single SOcket Dual Allocation with TURN)

Hi TRAMsters,

Justin, Oleg and myself wrote up some of the thoughts regarding single socket dual IPv4/IPv6 allocations that was discussed earlier on the list. There are still open issues, but we feel it is important that the discussion continue on the list. 

Below are the submission details:

A new version of I-D, draft-martinsen-tram-ssoda-00.txt
has been successfully submitted by Paal-Erik Martinsen and posted to the
IETF repository.

Name: draft-martinsen-tram-ssoda
Revision: 00
Title: Single SOcket Dual Allocation with TURN
Document date: 2014-03-17
Group: Individual Submission
Pages: 8
URL:            http://www.ietf.org/internet-drafts/draft-martinsen-tram-ssoda-00.txt
Status:         https://datatracker.ietf.org/doc/draft-martinsen-tram-ssoda/
Htmlized:       http://tools.ietf.org/html/draft-martinsen-tram-ssoda-00

Abstract:
  This draft describes a simple method for allocating one IPv4 and one
  IPv6 relay address from a single ALLOCATE request to the TURN server.
  This saves local ports on the client, reduces the number of
  candidates gathered by the client, and reduces the number of messages
  sent between the client and the TURN server.

.-.
Pål-Erik

---

From: Simon Perreault <[email-masked]>
Date: Tue, 18 Mar 2014 10:35:56 -0400

Le 2014-03-18 06:13, Tirumaleswar Reddy (tireddy) a écrit :
> This benefits IPv4 only hosts and the above sentence may not be applicable for dual-stack hosts.  With IPv6 there will no NAT or even with NPTv6 it's just 1:1 mapping.

The statement would also apply to IPv6 hosts behind stateful IPv6
firewalls. I, for one, am behind such a firewall at work (actually two
layers of stateful IPv6 firewalls).

And NAT64...

> Dual-stack host let's say behind both NAT44 and NPTv6, cannot use single ALLOCATE request to learn both relayed and server-reflexive addresses for both families.

This is true, but if I'm not mistaken, and please correct me if I'm
wrong, in ICE you can not use a single TURN connection for creating both
a server-reflexive and a relayed candidate. Each candidate needs its own
socket. If that is correct then SSODA is no worse and no better than the
status quo in this regard.

> May be the client once in a day can probe and find if the server supports multiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request.

Good observation. IMHO that last sentence is not necessary for
interoperability. Let client implementers figure it out.

> 4) How does this mechanism reduce the number of candidates gathered during the discovery process ?

It does not. That's not the goal. The goal is being able to obtain two
candidates (IPv4 and IPv6 relayed candidates) using a single socket.

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: Oleg Moskalenko <[email-masked]>
Date: Tue, 18 Mar 2014 11:51:04 -0700

Hi Tiru

please see below:

On Tue, Mar 18, 2014 at 3:13 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> How will the client ever know that the server has upgraded and now
> supports the new mechanism proposed in the draft ?
> May be the client once in a day can probe and find if the server supports
> multiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request.
>

I guess so

> client has already authenticated)

I suppose that this document does not introduce any new security concerns
(besides the ones we already have about TURN in general)

> Comment> I guess the above line does not hold good for errors like
Do you mean a use case when one family relay address can be allocated - but
the other one can't - due to the exhaustion of capacity of that single
address family ? That's true. But we do know that that address family
cannot be allocated at the moment. So, I'd change the text to:

=======================================
The allocated non-ANY address can be used, but the client SHOULD NOT try to
allocate any of the unsupported families on a different 5-tuple within the
subsequent 600 seconds interval. After that interval, the allocation can be
re-tried.
=======================================

Agree ?

Thanks
Oleg

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 18 Mar 2014 13:20:07 -0700

Simon, please see below

On Tue, Mar 18, 2014 at 7:35 AM, Simon Perreault <
[email-masked]> wrote:

>
>
> > Dual-stack host let's say behind both NAT44 and NPTv6, cannot use single
> ALLOCATE request to learn both relayed and server-reflexive addresses for
> both families.
>
> idates gathered during the discovery process ?
>
>
Strictly speaking, a single client-side UDP socket can be used for both
purposes. When the client receives ALLOCATE response, it learns both the
reflexive address and the relayed address. This is from RFC 5766, about
ALLOCATE response content:

      - An XOR-MAPPED-ADDRESS attribute containing the client's IP address
      and port (from the 5-tuple).

      NOTE: The XOR-MAPPED-ADDRESS attribute is included in the response
      as a convenience to the client.  TURN itself does not make use of
      this value, but clients running ICE can often need this value and
      can thus avoid having to do an extra Binding transaction with some
      STUN server to learn it.

 When TCP is used then I am not sure that the same client socket / port can
be used for the dual purpose without some extra efforts. But with UDP we
indeed learn both candidates with single ALLOCATE request. So, with single
ALLOCATE request we are getting three candidates:

 - reflexive candidate (whatever address family it belongs to);
 - IPv4 relayed address;
 - IPv6 relayed address.

Thanks
Oleg

---

From: Simon Perreault <[email-masked]>
Date: Tue, 18 Mar 2014 16:22:45 -0400

Le 2014-03-18 16:20, Oleg Moskalenko a écrit :
>     > Dual-stack host let's say behind both NAT44 and NPTv6, cannot use
>     single ALLOCATE request to learn both relayed and server-reflexive
>     addresses for both families.
> 

I know that TURN allows it. Does *ICE* allow it?

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 18 Mar 2014 13:25:51 -0700

I am not sure that I understand why ICE must be concerned. From ICE point
of view, there are three unrelated different addresses. How ICE knows that
those three addresses are coming (eventually) from the same client socket ?
I did not get what is the problem. May be, that's more a problem of an ICE
implementation, not ICE specs problem ? Then I'd understand that.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 18 Mar 2014 16:35:37 -0400

Le 2014-03-18 16:25, Oleg Moskalenko a écrit :
> I am not sure that I understand why ICE must be concerned. From ICE
> point of view, there are three unrelated different addresses. How ICE
> knows that those three addresses are coming (eventually) from the same
> client socket ? I did not get what is the problem. May be, that's more a
> problem of an ICE implementation, not ICE specs problem ? Then I'd
> understand that.

It seems you're right. From RFC 5245:

   The agent will receive a Binding or Allocate response.  A successful
   Allocate response will provide the agent with a server reflexive
   candidate (obtained from the mapped address) and a relayed candidate
   in the XOR-RELAYED-ADDRESS attribute.

So it seems it is already possible without SSODA to have IPv4 and IPv6
server-reflexive and relayed candidates using only two sockets.

What is the advantage of SSODA again?

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 18 Mar 2014 13:38:07 -0700

My understanding is that with a single client socket, we are getting three
candidates - reflexive, IPv4 relayed, IPv6 relayed.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 18 Mar 2014 16:40:40 -0400

Le 2014-03-18 16:38, Oleg Moskalenko a écrit :
> My understanding is that with a single client socket, we are getting
> three candidates - reflexive, IPv4 relayed, IPv6 relayed.

Sure, but what's the point if you still need two sockets to get all four
candidates?

Simon

> On Tue, Mar 18, 2014 at 1:35 PM, Simon Perreault
> <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 18 Mar 2014 14:04:55 -0700

Without SSODA, if we want both IPv4 and IPv6 candidates, then we need:

1) two client sockets for two allocations
2) two server sockets for two allocations
3) two relayed sockets for the server relayed endpoints (one per allocation)

With SSODA:

1) One client socket for one allocation
2) one server socket for one allocation
3) two relayed sockets in single allocation

So, this is totally 6 sockets vs 4 sockets with SSODA:

1) 2 sockets vs 1 socket on client
2) 4 sockets vs 3 sockets on server

---

From: Simon Perreault <[email-masked]>
Date: Tue, 18 Mar 2014 17:08:44 -0400

> 2) 4 sockets vs 3 sockets on server

Aren't you missing one server-reflexive candidate in your "with SSODA"
scenario?

I'm assuming you want dual-stack server-reflexive and dual-stack relayed
candidates. If that assumption doesn't hold, please explain why.

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 18 Mar 2014 14:19:55 -0700

If we do want two server-reflexive candidates (both IPv4 and IPv6) then you
are right, two client sockets are involved. One client socket will have a
TURN allocation session (with dual relay candidates) and another will be
just a reflexive candidate obtained by STUN BINDING request.

We still have some noticeable optimization because we need only one TURN
allocation dialog (plus STUN stateless request for the second address
family candidate). So we still are consuming less resources, because a TURN
allocation is a much heavier thing than a STUN stateless request-response.

Oleg

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 19 Mar 2014 06:30:52 +0000

Hi Oleg,

Please see inline [TR]

From: Oleg Moskalenko [mailto:[email-masked]]
Sent: Wednesday, March 19, 2014 12:21 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Pal Martinsen (palmarti); [email-masked]
Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN)

Hi Tiru
please see below:

On Tue, Mar 18, 2014 at 3:13 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

Comment>

I guess so

I suppose that this document does not introduce any new security concerns (besides the ones we already have about TURN in general)

[TR] Yes, you just need say something similar to the above line.

5) Section 2.3

Do you mean a use case when one family relay address can be allocated - but the other one can't - due to the exhaustion of capacity of that single address family ? That's true. But we do know that that address family cannot be allocated at the moment. So, I'd change the text to:

=======================================
The allocated non-ANY address can be used, but the client SHOULD NOT try to allocate any of the unsupported families on a different 5-tuple within the subsequent 600 seconds interval. After that interval, the allocation can be re-tried.
=======================================
Agree ?
[TR] Yes
-Tiru
Thanks
Oleg

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 19 Mar 2014 09:48:25 +0000

On 19 Mar 2014, at 07:30, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Oleg,

Please see inline [TR]

Cc: Pal Martinsen (palmarti); [email-masked]<mailto:[email-masked]>

Hi Tiru
please see below:

Comment>

I guess so

I do not think the client should cache this information. It just needs to know if it specks to a SSODA server,if it does not it might do more steps to get all the allocated RELAY addresses the client needs.

It might have some positive security aspects. SSODA have the potential of reducing chatter between agent and TURN server. This means that the TURN server can put in more restrictive rate limiting hemes to restrict the number of allocate request it will handle without impacting the client.

5) Section 2.3

I am unsure.

This is a problem with the partial success scheme introduced in SSODA. The TURN server will return one valid XOR-ADDRESS and one ANY:0 address. We do not know the reason why the SSODA server used a ANY address.

Can we use the port number in the ANY address to distinguish between insufficient capacity and address type not supported on this server?

ANY:0 means address type not supported. I understand SSODA, but do not try to allocate this address on a different 5-tuple. This address type is disabled on this server.

ANY:9 means insufficient resources. Try again later.

Or is using port numbers like this a slippery slope?

.-.
Pål-Erik

-Tiru
Thanks
Oleg

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 19 Mar 2014 10:01:02 +0000

On 18 Mar 2014, at 22:19, Oleg Moskalenko <[email-masked]<mailto:[email-masked]>> wrote:

If we do want two server-reflexive candidates (both IPv4 and IPv6) then you are right, two client sockets are involved. One client socket will have a TURN allocation session (with dual relay candidates) and another will be just a reflexive candidate obtained by STUN BINDING request.

We still have some noticeable optimization because we need only one TURN allocation dialog (plus STUN stateless request for the second address family candidate). So we still are consuming less resources, because a TURN allocation is a much heavier thing than a STUN stateless request-response.

I was thinking about an alternate way of getting the IPv6 RFLX candidate.

1. Use IPv4 to allocate a dual IPv4/IPv6 SSODA RELAY addresses.
2. From HOST IPv6 address send a some data (STUN packet?) to the RELAY IPv6 address.
3. Receive data on the IPv4 “tunnel” and look at the PEER ADDRESS, this will be the RFLX IPv6 address.

But… What about permissions. Any clever way of getting the TURN server to securely accept traffic from your IPv6 RFLX address? It is a nice way to actually check connectivity before the real connectivity checks.

Probably easier with a STUN Binding request if the TURN server also supports STUN. We should definitively add some wording in the SSODA draft that a SSODA server should also respond to STUN Binding Request to solve the missing RFLX candidate problem.

.-.
Pål-Erik

Oleg

On Tue, Mar 18, 2014 at 2:08 PM, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:

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

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

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Mar 2014 10:10:52 -0400

Le 2014-03-19 06:01, Pal Martinsen (palmarti) a écrit :
> Probably easier with a STUN Binding request if the TURN server also
> supports STUN. We should definitively add some wording in the SSODA
> draft that a SSODA server should also respond to STUN Binding Request to
> solve the missing RFLX candidate problem.

TURN servers usually respond to Binding requests...

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 19 Mar 2014 09:47:05 -0700

> TURN servers usually respond to Binding requests...
yes, that's true. I do not see a problem here.

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 19 Mar 2014 09:55:26 -0700

Hi Pal

please see inline:

On Wed, Mar 19, 2014 at 2:48 AM, Pal Martinsen (palmarti) <
[email-masked]> wrote:

>  I do not think the client should cache this information. It just needs
> to know if it specks to a SSODA server,if it does not it might do more
> steps to get all the allocated RELAY addresses the client needs.
>

My understanding is that a client app can be a very long-living client app,
and it can connect to both old and new TURN servers. And a TURN server can
be upgraded overnight. So the client app has to learn somehow at some
momemnt of time that the server has been upgraded.

>   I suppose that this document does not introduce any new security
> concerns (besides the ones we already have about TURN in general)
>
>  It might have some positive security aspects. SSODA have the potential
> of reducing chatter between agent and TURN server. This means that the TURN
> server can put in more restrictive rate limiting hemes to restrict the
> number of allocate request it will handle without impacting the client.
>

OK

> Do you mean a use case when one family relay address can be allocated -
> but the other one can't - due to the exhaustion of capacity of that single
> The allocated non-ANY address can be used, but the client SHOULD NOT try
> to allocate any of the unsupported families on a different 5-tuple within
> the subsequent 600 seconds interval. After that interval, the allocation
> can be re-tried.
>  This is a problem with the partial success scheme introduced in SSODA.
> The TURN server will return one valid XOR-ADDRESS and one ANY:0 address. We
> do not know the reason why the SSODA server used a ANY address.
>
>  Can we use the port number in the ANY address to distinguish between
> insufficient capacity and address type not supported on this server?
>
>  ANY:0 means address type not supported. I understand SSODA, but do not
> try to allocate this address on a different 5-tuple. This address type is
> disabled on this server.
>
I think  that assigning special meanings to the port numbers is indeed
somewhat a slippery slope... but if we do want to do something like that, I
would suggest using standard  error codes as the port numbers, not some
arbitrary values like 9. For example, "insufficient capacity" partial error
would be signaled as ANY:508 address value.

Thanks
Oleg

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 20 Mar 2014 02:48:08 +0000

Inline [TR]

I am unsure.

I think  that assigning special meanings to the port numbers is indeed somewhat a slippery slope... but if we do want to do something like that, I would suggest using standard  error codes as the port numbers, not some arbitrary values like 9. For example, "insufficient capacity" partial error would be signaled as ANY:508 address value.
[TR] There are two types of errors long-term (unsupported family), short-term (insufficient capacity, quota exceeded etc.). For the short-term errors, the server can suggest the client to re-try after specific duration. I don't think it's a good idea to populate error codes in the port field.
-Tiru
Thanks
Oleg

---

From: Justin Uberti <[email-masked]>
Date: Wed, 19 Mar 2014 21:58:05 -0700

A few comments on things that were raised in this discussion:

- Using port numbers to indicate errors is a slippery slope. But I'm not
convinced it's even necessary; it's not clear to me that there's a case
where the client needs to take different action based on the error code. If
it is necessary, one solution might be to include ERROR-CODE attributes in
the partial success message.
- Client should not cache any information about the server other than for
an active allocation. If SSODA isn't supported, there's little harm in
trying again the next time.
- SSODA should work fine for both TCP and UDP server connections. I don't
see any difference here.
- Regarding srflx candidates - there is no need for SSODA to try to get
multiple srflx candidates; you just get srflx for the IPvX that you used to
connect to the TURN server, which is fine. When you are dual-stack, you
will connect from both interfaces to the TURN server. This is important
because you want to use the same socket you use for TURN for ICE as well
(this ensures proper working of peer-reflexive candidates learned from
XOR-PEER-ADDRESS).

The overall allocation sequence will yield these candidates (for a
single-interface, dual-stack host, single dual-stack TURN server),
prioritized in descending order:
1) host IPv6
2) host IPv4
3) srflx IPv6 (from TURN IPv6 conn)
4) srflx IPv4 (from TURN IPv4 conn)
5) relay IPv6 (from TURN IPv6 conn)
6) relay IPv6 (from TURN IPv4 conn)
7) relay IPv4 (from TURN IPv6 conn)
8) relay IPv4 (from TURN IPv4 conn)

SSODA allows the same socket to be used for 1, 3, 5, 7 as well as 2, 4, 6, 8

On Wed, Mar 19, 2014 at 9:55 AM, Oleg Moskalenko <[email-masked]>wrote:

> My understanding is that a client app can be a very long-living client
> app, and it can connect to both old and new TURN servers. And a TURN server
> can be upgraded overnight. So the client app has to learn somehow at some
> [email-masked]

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 19 Mar 2014 22:18:47 -0700

I agree. I suggested ANY:error_code only as an alternative to ANY:9.
Overall, I think that we can assume that the allocation could not be
completed for some reason and that can be retried later.

Oleg

On Wed, Mar 19, 2014 at 9:58 PM, Justin Uberti <[email-masked]> wrote:

>>> May be the client once in a day can probe and find if the server
>>> supports multiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE
>>> request.
>>>
>>>   I guess so
>>>
>>>
>>>

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 20 Mar 2014 08:59:17 +0000

Thanks for summarising.

On 20 Mar 2014, at 05:58, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

- Using port numbers to indicate errors is a slippery slope. But I'm not convinced it's even necessary; it's not clear to me that there's a case where the client needs to take different action based on the error code. If it is necessary, one solution might be to include ERROR-CODE attributes in the partial success message.

RFC4583 Distinguishes between port 0 and port 9 (Discard port).

Distinguishing between address type not supported and address type temporarily exhausted is probably not important as the client should not keep state for the next call.

How do we deal with alternate server? Should we enable the possibility to send each address type to different servers. A fun engineering task, but will probably get complicated and not solve many real world problems?

- Client should not cache any information about the server other than for an active allocation. If SSODA isn't supported, there's little harm in trying again the next time.

+1
- SSODA should work fine for both TCP and UDP server connections. I don't see any difference here.

The connection between agent and TURN server or TURN-TCP?

- Regarding srflx candidates - there is no need for SSODA to try to get multiple srflx candidates; you just get srflx for the IPvX that you used to connect to the TURN server, which is fine. When you are dual-stack, you will connect from both interfaces to the TURN server. This is important because you want to use the same socket you use for TURN for ICE as well (this ensures proper working of peer-reflexive candidates learned from XOR-PEER-ADDRESS).

I think dual stacked host can benefit from SSODA as well. Use IPvX to allocate the RELAY addresses. The reflexive candidate of IPvY needs to be learnt with a STUN binding request. This saves the TURN server for work like checking credentials, alternate server might kick in, ++.

Only drawback is in some cases you might end up converting from IPvX to IPvY on the TURN server. Not sure how expensive such an IP address translation is?

Peer reflexive adresses are learnt when sending a STUN binding request from your HOST address towards any of the remote HOST, RFLX or RELAY candidates. If the XOR-PEER-ADDRESS in the STUN Binding Response differs from your SRFLX previously discovered it is a PRFLX candidate. I do not see the need for a direct mapping of HOST addr type and RELAY addr type necessary. Or?

In a IPv6 deployment you might get lucky and get a PRFLX candidate without having SRFLX candidate. Dependant on the remote side setup. This is useful in a webRTC Trickle ICE scenario where you must chose if you want to spend time slots on connectivity checks or candidate gathering.

The overall allocation sequence will yield these candidates (for a single-interface, dual-stack host, single dual-stack TURN server), prioritized in descending order:
1) host IPv6
2) host IPv4

I would like fewer candidates

1) host IPv6
2) host IPv4
3) srflx IPv4 (From SSODA allocate Request)
4) srflx IPv6 (STUN Binding Request, With Trickle Ice might be deferred to later stage)
5) relay IPv4 (From SSODA Allocate Request)
6) relay IPv6 (FROM SSODA Allocate Request)

The client needs to take some decision on how to contact the TURN server. There should be a discovery mechanism for that.. Not just IPv4 or IPv6, but UDP, TCP, TLS and DTLS as well.

.-.
Pål-Erik

On Wed, Mar 19, 2014 at 9:55 AM, Oleg Moskalenko <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pal

please see inline:

On Wed, Mar 19, 2014 at 2:48 AM, Pal Martinsen (palmarti) <[email-masked]<mailto:[email-masked]>> wrote:

Comment>

I guess so

My understanding is that a client app can be a very long-living client app, and it can connect to both old and new TURN servers. And a TURN server can be upgraded overnight. So the client app has to learn somehow at some momemnt of time that the server has been upgraded.

OK

5) Section 2.3

Thanks
Oleg

---

From: Simon Perreault <[email-masked]>
Date: Thu, 20 Mar 2014 09:29:35 -0400

> SSODA allows the same socket to be used for 1, 3, 5, 7 as well as 2, 4, 6, 8

Great summary. Makes total sense.

Thanks,
Simon

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 20 Mar 2014 15:39:22 +0000

I don’t think using XOR-RELAYED-ADDRESS with ANY to mean partial failure is a good idea.

STUN attributes are cheap.  I suggest an a new attribute UNAVAILABLE-ADDRESS-FAMILY, which can be sent in an SSODA success response.  If we want to be able to distinguish reasons for unavailability, the attribute can be formatted as address-family/error-code/reason-phrase.

In principle UNAVAILABLE-ADDRESS-FAMILY could be sent in SSODA failure responses as well, if people think it would be useful to be able to describe cases where the IPv4 and IPv6 allocations failed for different reasons.

Additionally — I don’t like SSODA’s mechanism of deliberately triggering behavior that’s undefined according to RFC 6156.  It seems like this will be fragile.  I’d suggest instead that we define a comprehension-optional ADDITIONAL-REQUESTED-ADDRESS-FAMILY attribute, formatted identically to REQUESTED-ADDRESS-FAMILY, which a SSODA-aware TURN server will use but a strict 6156 TURN server will ignore.

On Mar 19, 2014, at 10:48 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

Inline [TR]

I am unsure.

[TR] There are two types of errors long-term (unsupported family), short-term (insufficient capacity, quota exceeded etc.). For the short-term errors, the server can suggest the client to re-try after specific duration. I don’t think it’s a good idea to populate error codes in the port field.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 20 Mar 2014 09:13:08 -0700

On Thu, Mar 20, 2014 at 1:59 AM, Pal Martinsen (palmarti) <
[email-masked]> wrote:

>
>  Thanks for summarising.
>
>  On 20 Mar 2014, at 05:58, Justin Uberti <[email-masked]> wrote:
>
>  Distinguishing between address type not supported and address type
> temporarily exhausted is probably not important as the client should not
> keep state for the next call.
>
>  How do we deal with alternate server? Should we enable the possibility
> to send each address type to different servers. A fun engineering task, but
> will probably get complicated and not solve many real world problems?
>

I would like to invoke YAGNI here and avoid doing this work. It diminishes
the benefit of SSODA to have v4-only and v6-only servers.

>
>   - Client should not cache any information about the server other than
> for an active allocation. If SSODA isn't supported, there's little harm in

agent and TURN server. I wasn't sure what the actual issue was here, but
Oleg mentioned this in a recent message.

>  I think dual stacked host can benefit from SSODA as well. Use IPvX to
> allocate the RELAY addresses. The reflexive candidate of IPvY needs to be
> learnt with a STUN binding request. This saves the TURN server for work
> like checking credentials, alternate server might kick in, ++.
>
>  Only drawback is in some cases you might end up converting from IPvX to
> IPvY on the TURN server. Not sure how expensive such an IP address
> translation is?
>
>  Peer reflexive adresses are learnt when sending a STUN binding request
> from your HOST address towards any of the remote HOST, RFLX or RELAY
> candidates. If the XOR-PEER-ADDRESS in the STUN Binding Response differs
> from your SRFLX previously discovered it is a PRFLX candidate. I do not see
> the need for a direct mapping of HOST addr type and RELAY addr type
> necessary. Or?
>
>  In a IPv6 deployment you might get lucky and get a PRFLX candidate
> without having SRFLX candidate. Dependant on the remote side setup. This is
> useful in a webRTC Trickle ICE scenario where you must chose if you want to
> spend time slots on connectivity checks or candidate gathering.
>
>

That is fine - that's a client choice, and doesn't affect SSODA.

>
>  The client needs to take some decision on how to contact the TURN
> server. There should be a discovery mechanism for that.. Not just IPv4 or
> IPv6, but UDP, TCP, TLS and DTLS as well.
>
>  .-.
> Pål-Erik
>
>
>
>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 20 Mar 2014 09:26:34 -0700

On Thu, Mar 20, 2014 at 8:39 AM, Jonathan Lennox <[email-masked]> wrote:

>  STUN attributes are cheap.  I suggest an a new attribute
> UNAVAILABLE-ADDRESS-FAMILY, which can be sent in an SSODA success response.
>  If we want to be able to distinguish reasons for unavailability, the
> attribute can be formatted as address-family/error-code/reason-phrase.
>

>  In principle UNAVAILABLE-ADDRESS-FAMILY could be sent in SSODA failure
> responses as well, if people think it would be useful to be able to
> describe cases where the IPv4 and IPv6 allocations failed for different
> reasons.
>

This would be essentially ERROR-CODE with an address family. We could make
a new attribute as you describe, or we could try to claim some of the
reserved bits in the existing ERROR-CODE.

>
>  Additionally — I don’t like SSODA’s mechanism of deliberately triggering
> behavior that’s undefined according to RFC 6156.  It seems like this will
> be fragile.  I’d suggest instead that we define a comprehension-optional
> ADDITIONAL-REQUESTED-ADDRESS-FAMILY attribute, formatted identically to
> REQUESTED-ADDRESS-FAMILY, which a SSODA-aware TURN server will use but a
> strict 6156 TURN server will ignore.
>

Agree this would be a better approach.

>
>  On Mar 19, 2014, at 10:48 PM, Tirumaleswar Reddy (tireddy) <
> [TR] There are two types of errors long-term (unsupported family),
> short-term (insufficient capacity, quota exceeded etc.). For the short-term
> errors, the server can suggest the client to re-try after specific
> duration. I don’t think it’s a good idea to populate error codes in the
> port field.
>
> -Tiru
>
> Thanks
> Oleg

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 20 Mar 2014 16:32:04 +0000

On Mar 20, 2014, at 12:26 PM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Mar 20, 2014 at 8:39 AM, Jonathan Lennox <[email-masked]<mailto:[email-masked]>> wrote:
I don’t think using XOR-RELAYED-ADDRESS with ANY to mean partial failure is a good idea.

This would be essentially ERROR-CODE with an address family. We could make a new attribute as you describe, or we could try to claim some of the reserved bits in the existing ERROR-CODE.

Formatting-wise, yes, I’d use some of the reserved bits in ERROR-CODE to carry the address family.

I think that giving it a different attribute number would be a good idea, though, since it’s semantically different.

Inline [TR]

I am unsure.

tram mailing list

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 20 Mar 2014 22:29:26 -0700

Please see inline:

On Thu, Mar 20, 2014 at 9:32 AM, Jonathan Lennox <[email-masked]> wrote:

>
>  On Mar 20, 2014, at 12:26 PM, Justin Uberti <[email-masked]> wrote:
>
>   On Thu, Mar 20, 2014 at 8:39 AM, Jonathan Lennox <[email-masked]>wrote:
>
>>  I don't think using XOR-RELAYED-ADDRESS with ANY to mean partial
>> failure is a good idea.
>>
>  This would be essentially ERROR-CODE with an address family. We could
> make a new attribute as you describe, or we could try to claim some of the
>  Formatting-wise, yes, I'd use some of the reserved bits in ERROR-CODE to
> carry the address family.
>
>  I think that giving it a different attribute number would be a good
> idea, though, since it's semantically different.
>

[Oleg] That's probably OK. I guess we want it in comprehension-optional
range; then we can try to make it somewhat backward compatible for older
clients.

>
>    Additionally -- I don't like SSODA's mechanism of deliberately
>> triggering behavior that's undefined according to RFC 6156.  It seems like
>> this will be fragile.  I'd suggest instead that we define a
>> comprehension-optional ADDITIONAL-REQUESTED-ADDRESS-FAMILY attribute,
>> formatted identically to REQUESTED-ADDRESS-FAMILY, which a SSODA-aware TURN
>> server will use but a strict 6156 TURN server will ignore.
>>
>
[Oleg] I actually think that the original proposal of two equally important
"symmetric" REQUESTED-ADDRESS-FAMILY attributes is "cleaner" than
introducing an "asymmetric" schema of "primary" and "additional" addresses
families. I feel that there may be a number of potential behavioral and
compatibility issues if we treat them differently.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 21 Mar 2014 09:38:12 -0700

On Thu, Mar 20, 2014 at 10:29 PM, Oleg Moskalenko <[email-masked]>wrote:

> Please see inline:
>
>
> On Thu, Mar 20, 2014 at 9:32 AM, Jonathan Lennox <[email-masked]>wrote:
>
>>
>> idea, though, since it’s semantically different.
>>
>
>>    Additionally — I don’t like SSODA’s mechanism of deliberately
>>> triggering behavior that’s undefined according to RFC 6156.  It seems like
>>> this will be fragile.  I’d suggest instead that we define a
> [Oleg] I actually think that the original proposal of two equally
> important "symmetric" REQUESTED-ADDRESS-FAMILY attributes is "cleaner" than
> Agree it is semantically cleaner (which is why I liked it), but Jonathan's
point about undefined behavior is a good one. I would rather have a
slightly less clean design that I feel confident will work across all
5766-compliant servers, than a perfect design that fails completely in 1%
of cases.

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 21 Mar 2014 17:50:27 +0000

On Mar 21, 2014, at 12:38 PM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Mar 20, 2014 at 10:29 PM, Oleg Moskalenko <[email-masked]<mailto:[email-masked]>> wrote:

[Oleg] I actually think that the original proposal of two equally important "symmetric" REQUESTED-ADDRESS-FAMILY attributes is "cleaner" than introducing an "asymmetric" schema of "primary" and "additional" addresses families. I feel that there may be a number of potential behavioral and compatibility issues if we treat them differently.

Agree it is semantically cleaner (which is why I liked it), but Jonathan's point about undefined behavior is a good one. I would rather have a slightly less clean design that I feel confident will work across all 5766-compliant servers, than a perfect design that fails completely in 1% of cases.

Exactly.  The intention is that these two attributes *would* be semantically identical, for a server that supports SSODA; it’s only the backward-compatibility case that would be treated differently.

Additionally, it would give clients control over what happens (i.e., which address they get) if they do turn out to be talking to a 5766 (well, 6156) server, rather than having the result be unpredictable.