Re: [tram] SSODA in TURN-bis

Hi Justin,

option c) looks good, it was discussed in the WG sometime back that TURN-bis client MUST include R-A-F in the Allocate request.

-Tiru

From: Justin Uberti [mailto:juberti@google.com]
Sent: Friday, January 09, 2015 1:53 AM
To: Aijun Wang
Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org
Subject: Re: [tram] SSODA in TURN-bis

On Wed, Jan 7, 2015 at 11:14 PM, Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>> wrote:
Hi, Justin,

Is it more straightforward to define one new attribute that named “Additional-Address-Family ” instead of the R-A-F and  OPTIONAL-ADDRESS-FAMILY? The endpoint that does not include this attribute will be assigned the relay address that is the same type as seen from the source address of “Allocate Request” packet, not default in IPv4 relay address.

I suppose this could be a third option (c), in addition to (a) multiple R-A-F and (b) multiple optional-a-f.  Here's how a/b/c look on the wire when requesting v4+v6 simultaneously. If requesting v4 or v6 only for some reason, a/b/c would all send a single RAF.

a: RAF (v4) + RAF (v6)
a1: server is 5766: error (RAF required-comprehension but unknown)
a2: server is 6156: v4 address, or error (undefined behavior)
a3: server is SSODA: v4 address + v6 address
b: OAF (v4) + OAF (v6)
b1: server is 5766/6156: v4 address (OAF ignored)
b2: server is SSODA: v4 address + v6 address
c: AAF (v6)
c1: server is 5766/6156: v4 address (AAF ignored)
c2: server is SSODA: v4 address + v6 address

Note that for c), one could send RAF(v4) + AAF(v6), but since that would fail on a 5766 server, sending just AAF(v6) would be preferable.
Note that for b), if one sent OAF(v6) by itself for some reason, a 5766 server would return a v4 address, which is slightly inelegant.
For either b/c, we would need to say that including both RAF and OAF/AAF for the same address family is prohibited.

b) is nice in that it avoids implicit behavior (i.e. that IPv4 is the default AF), but feels a bit more complicated than c). I am supportive of either b)/c), with maybe a slight preference for c).

For reducing the port resource consumption on TURN server that described in https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01, we have another proposal http://datatracker.ietf.org/doc/draft-wang-tram-turnlite/ that can mitigate the ip address/port allocation burden on TURN server------All endpoints that under one TURN server can use the same IPv4/IPv6 relay  address/port.

The port consumption is a side benefit; the primary benefit of SSODA is the reduction in the overall number of candidates.

Best Regards.
Aijun Wang.

From: tram [mailto:tram-bounces@ietf.org<mailto:tram-bounces@ietf.org>] On Behalf Of Justin Uberti
Sent: Thursday, January 08, 2015 12:02 PM
To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org<mailto:tram@ietf.org>
Subject: [SPAM] Re: [tram] SSODA in TURN-bis

I promised I would write up a summary of the current mechanism, and what we could do instead, so here goes:

The currently documented mechanism is to send two R-A-F attributes in the request, and get back either a single address (from legacy servers), v4 + v6 addresses (from new servers), a single address + a 0.0.0.0/<http://0.0.0.0/>:: (for new servers that only support one address family), or an error-code (to indicate complete failure).

At the time, there were 2 concerns listed, namely:
1) sending multiple R-A-Fs is undefined behavior; old (6156) servers may fail the request completely, or do other weird things.
2) using 0.0.0.0/<http://0.0.0.0/>:: to indicate partial success is somewhat unclean; specifically, detailed error information cannot be included.

I also thought of a 3rd problem:
3) an old(5766) server may fail the request completely, due to the fact that R-A-F is comprehension-required. Thus an extra roundtrip may be needed in this case, negating one of the benefits of SSODA.

I think the ideal solution to #1/#3 is to add a new OPTIONAL-ADDRESS-FAMILY attribute, identical to R-A-F but comprehension-optional, where multiple values are explicitly supported. Old servers can safely ignore this and will return IPv4 (solving #3), while new servers can process this to return multiple XOR-RELAYED-ADDRESSes in the response.
#2 is not a serious issue, but it could easily be solved by defining a new ADDRESS-ERROR-CODE as follows:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |  Address Family                |  Rsvd  |Class|     Number    |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |      Reason Phrase (variable)                                ..

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Then a server could return a normal IPv4 address, but a error code for IPv6 with either 440 (unsupported address family) or 508 (insufficient capacity) or some other TBD error.

I advocate we do the OPTIONAL-ADDRESS-FAMILY attribute as it is simple and prevents potential interoperability problems with old servers. I could go either way on ADDRESS-ERROR-CODE.

On Wed, Jan 7, 2015 at 6:02 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com<mailto:tireddy@cisco.com>> wrote:
Hi all,

We are working on incorporating RFC6156 and SSODA into TURN-bis. During IETF-91 meeting there was discussion if the technique proposed in https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01 would break existing TURN server implementations.  Pal had mentioned testing with four implementations and did not face any problem.

Please let us know if there are any concerns with the existing proposal of conveying two REQUESTED-ADDRESS-FAMILY attributes with different attribute values in Allocate request ?

Cheers,
-Tiru

_______________________________________________
tram mailing list
tram@ietf.org<mailto:tram@ietf.org>
https://www.ietf.org/mailman/listinfo/tram