Re: [tram] Multiple allocations SV: I-D Action: draft-ietf-tram-turnbis-15.txt

["Olle E. Johansson" <[e-mail]>]

> On 20 Mar 2018, at 20:55, Karl Stahl <[e-mail]> wrote:
> 
>> This revision addresses comments from Mark, Karl and Noriyuki Torii.
> My comment about need for multiple allocations is NOT addressed.
> 
> Let me explain more clearly why multiple allocations is needed:
> 
> ICE is about finding all/many paths for the media, e.g. with the help of
> TURN servers.
> Those paths are not over ONE IPv4 network, over ONE IPv6 network or EXACTLY
> ONE OF EACH. 
> If fact, it is more common that you have several IPv4 networks paths.
> 
> Now that we have network provided TURN servers, you only ask for Allocation
> once (contrary to application provided TURN servers, where you can be
> directed to Allocate several times.) and thus we need all relay addresses in
> one allocation request.

I agree with Karl here, for network-provided turn servers (which is not defined
in the terminology section here on in 8155) I think there are use cases for 
multiple addresses in multiple families. 

I also understand that this will make the draft more complex. Consider
the case where a turn server have two IPv4 networks and one IPv6
and have run out of possible allocations on one IPv4 network - should
it send what’s available or send an error message and fail completely?

Regardless, this is a good time to fix this.

/O


> 
> Wasn't that the reason dual allocation was requested? The need for multiple
> allocation is stronger!
> 
> Please address this, e.g. like below (seems you are almost there).
> 
> /Karl
> 
> 
> ******************* Previous *******************
> 
> Allowing a turn allocation to return multiple relayed transport addresses,
> beyond ONE IPv4 and ONE IPv6 (which may sit on the same or on different
> interfaces/network segments), seems like very small step now when the dual
> allocation was put in place in this draft. We certainly need it (some
> reasons below) if TURN is going to be used where needed and we cannot wait
> for any additional draft.
> 
> Seems like it is sufficient to extent this table (found in draft 14) with 3
> new values (as shown): 
> 
> 16.  STUN Attributes
> 
>   This STUN extension defines the following attributes:
> 
>     0x000C: CHANNEL-NUMBER
>     0x000D: LIFETIME
>     0x0010: Reserved (was BANDWIDTH)
>     0x0012: XOR-PEER-ADDRESS
>     0x0013: DATA
>     0x0016: XOR-RELAYED-ADDRESS
>     0x0017: REQUESTED-ADDRESS-FAMILY
>     0x0018: EVEN-PORT
>     0x0019: REQUESTED-TRANSPORT
>     0x001A: DONT-FRAGMENT
>     0x0021: Reserved (was TIMER-VAL)
>     0x0022: RESERVATION-TOKEN
>     TBD-CA: ADDITIONAL-ADDRESS-FAMILY
> ADDITIONAL-ADDRESS-ALL
> ADDITIONAL-ADDRESS-ALLV4
> ADDITIONAL-ADDRESS-ALLV6
>     TBD-CA: ADDRESS-ERROR-CODE
>     TBD-CA: ICMP
> 
> Actually, browsing through the draft for ADDITIONAL-ADDRESS-FAMILY, very
> little text seems to be added for generalization to  ADDITIONAL-ADDRESS-xxx.
> Almost everything applies to ADDITIONAL-ADDRESS-xxx and can be reused.
> 
> ADDITIONAL-ADDRESS-ALL should be the default for any modern TURN client. 
> 
> Check! - We need this now.
> 
> Thanks,
> Karl
> 
>> -----Original Message-----
>> From: Karl Stahl [mailto:[e-mail]]
>> Sent: Sunday, March 4, 2018 10:36 PM
>> To: 'Marc Petit-Huguenin' <[e-mail]>; Konda, Tirumaleswar Reddy
>> <[e-mail]>; [e-mail]
>> Subject: SV: [tram] Review of dual allocation in TURNbis-11
>> 
>> Hi,
>> 
>> When we now have "dual allocation" into this draft (I see on page 26: "If
> the
>> client wishes to obtain one IPv6 and one IPv4 relayed transport address
> then
>> it includes an ADDITIONAL-ADDRESS-FAMILY transport address then it") can
>> we not generalize that further and allow MORE THAN ONE relayed transport
>> address (of any family) in response to an allocation?
>> 
>> I mean that a TURN server could have several relay interfaces at different
> IP-
>> addresses into different networks - not just the Internet, but also a VoIP
>> (higher quality) network e.g. by some triple play service provider, an IMS
>> network or some branch office network.
>> 
>> I think this is specifically important for network provided/auto
> discovered
>> turn servers (application provided turn servers could instead just list
> several
>> turn servers).
>> 
>> I saw someone snipped this about "SINGLE relayed transport address per
>> allocation request"
>>>> https://tools.ietf.org/html/rfc6156#section-3
>>>> <snip>
>>>> 
>>>>   TURN servers allocate a single relayed transport address per
>>>>   allocation request.  Therefore, Allocate requests cannot carry more
>>>>   than one REQUESTED-ADDRESS-FAMILY attribute.  Consequently, a
>> client
>>>>   that wishes to allocate more than one relayed transport address at
> a
>>>>   TURN server (e.g., an IPv4 and an IPv6 address) needs to perform
>>>>   several allocation requests (one allocation request per relayed
>>>>   transport address).
>>>> </snip>
>> 
>> but if that is remedied now, it seems like a small step to generalize so
> we can
>> get multiple relayed transport addresses from one allocate request?
>> 
>> /Karl
> 
> 
> -----Ursprungligt meddelande-----
> Från: tram [mailto:[e-mail]] För Konda, Tirumaleswar Reddy
> Skickat: den 18 mars 2018 09:51
> Till: [e-mail]
> Ämne: Re: [tram] I-D Action: draft-ietf-tram-turnbis-15.txt
> 
> This revision addresses comments from Mark, Karl and Noriyuki Torii.
> 
> -Tiru
> 
>> -----Original Message-----
>> From: tram [mailto:[e-mail]] On Behalf Of internet-
>> [e-mail]
>> Sent: Sunday, March 18, 2018 8:43 AM
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: [tram] I-D Action: draft-ietf-tram-turnbis-15.txt
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>> This draft is a work item of the TURN Revised and Modernized WG of the
>> IETF.
>> 
>>        Title           : Traversal Using Relays around NAT (TURN): Relay
> Extensions
>> to Session Traversal Utilities for NAT (STUN)
>>        Authors         : Tirumaleswar Reddy
>>                          Alan Johnston
>>                          Philip Matthews
>>                          Jonathan Rosenberg
>> 	Filename        : draft-ietf-tram-turnbis-15.txt
>> 	Pages           : 84
>> 	Date            : 2018-03-18
>> 
>> Abstract:
>>   If a host is located behind a NAT, then in certain situations it can
>>   be impossible for that host to communicate directly with other hosts
>>   (peers).  In these situations, it is necessary for the host to use
>>   the services of an intermediate node that acts as a communication
>>   relay.  This specification defines a protocol, called TURN (Traversal
>>   Using Relays around NAT), that allows the host to control the
>>   operation of the relay and to exchange packets with its peers using
>>   the relay.  TURN differs from some other relay control protocols in
>>   that it allows a client to communicate with multiple peers using a
>>   single relay address.
>> 
>>   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.
>> 
>>   This document obsoletes RFC 5766 and RFC 6156.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-tram-turnbis-15
>> https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-15
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-15
>> 
>> 
>> 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.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> tram mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tram
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>