Re: [tram] SSODA in TURN-bis

[Justin Uberti <[e-mail]>]

On Thu, Jan 8, 2015 at 6:34 PM, Tirumaleswar Reddy (tireddy) <
[e-mail]> wrote:

>  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.
>

I'm not sure this is a good idea since 5766 servers will choke on this.


>
>
> -Tiru
>
>
>
> *From:* Justin Uberti [mailto:[e-mail]]
> *Sent:* Friday, January 09, 2015 1:53 AM
> *To:* Aijun Wang
> *Cc:* Tirumaleswar Reddy (tireddy); [e-mail]
> *Subject:* Re: [tram] SSODA in TURN-bis
>
>
>
>
>
>
>
> On Wed, Jan 7, 2015 at 11:14 PM, Aijun Wang <[e-mail]>
> 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:[e-mail]] *On Behalf Of *Justin Uberti
> *Sent:* Thursday, January 08, 2015 12:02 PM
> *To:* Tirumaleswar Reddy (tireddy)
> *Cc:* [e-mail]
> *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) <
> [e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>
>
>
>
>