Re: [tram] SSODA in TURN-bis

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.

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. 

Best Regards.

Aijun Wang.

From: tram [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
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/:: (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/:: 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> 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
https://www.ietf.org/mailman/listinfo/tram