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

[Brandon Williams <[e-mail]>]

+1

When Tiru indicated that he had covered Karl's comments, I believe that 
he meant the other comments that were not asking to increase the scope 
of the document.

I think there will be enough work in this area to define the rationale 
and protocol changes that it would be an equivalent level of effort to 
change turnbis at this point vs just working it with a new draft. For 
that reason, I prefer covering the gap with a new draft.

If this does go in to turnbis, we'll need WG consensus to expand scope.

Chairs, Any suggestions on approach?

On 03/21/2018 11:23 AM, Konda, Tirumaleswar Reddy wrote:
>> -----Original Message-----
>> From: Olle E. Johansson [mailto:[e-mail]]
>> Sent: Tuesday, March 20, 2018 8:35 PM
>> To: Karl Stahl <[e-mail]>
>> Cc: Olle E Johansson <[e-mail]>; Konda, Tirumaleswar Reddy
>> <[e-mail]>; [e-mail]
>> Subject: Re: Multiple allocations SV: [tram] I-D Action: draft-ietf-tram-turnbis-
>> 15.txt
>>
>>
>>> 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.
> 
> The WG has only agreed on dual allocation, this is a new requirement for a specific deployment scenario.
> You may want to submit a new draft (just like we did for RFC8155).
> 
> -Tiru
> 
>>
>> 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
>>>
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>