Re: [tram] Review of dual allocation in TURNbis-11

[Marc Petit-Huguenin <[e-mail]>]

Inline.

On 10/16/2017 07:14 PM, Konda, Tirumaleswar Reddy wrote:
> Thanks Marc for the detailed review, Please see inline
> 
>> -----Original Message-----
>> From: tram [mailto:[e-mail]] On Behalf Of Marc Petit-
>> Huguenin
>> Sent: Saturday, October 14, 2017 12:59 AM
>> To: [e-mail]
>> Subject: [tram] Review of dual allocation in TURNbis-11
>>
>> I should first apologize the the delay in reviewing this draft.  I never managed
>> to get a sponsorship that spans the whole lifetime of a draft (or a Working
>> Group for that matter), and that why it is so difficult for me to work on IETF
>> stuff in a sustained and consistent manner.
>>
>> Anyway, I was working on a review for turnbis-11 that was specifically
>> focusing on the synchronization with stunbis, but I kept be distracted by
>> issues related to the dual allocation feature.  So I decided instead to send a
>> separate email for that, to make things less confusing.
>>
>> My main comment about the dual allocation approach is about the choice of
>> adding a new attribute for that.  STUN supports sending multiple attributes
>> of the same type, and has a default processing rule for them ("Any attribute
>> type MAY appear more than once in a STUN message.  Unless specified
>> otherwise, the order of appearance is significant:  only the first occurrence
>> needs to be processed by a receiver, and any duplicates MAY be ignored by a
>> receiver.")
>>
>> So a TURNbis client that wants to do a dual allocating adds two REQUESTED-
>> ADDRESS-FAMILY (RAF), one for IPv4 and one for IPv6.  An RFC 5766 server
>> will just use the first one and ignore the second.  The TURNbis client receives
>> only one XOR-RELAYED-ADDRESS (XRA), for the first RAF it sent.
>>
>> The client can choose the order, so it receives immediately a XRA from the
>> family it is most interested in, and can try a second allocation for the other if
>> the server is implementing RFC 5766
> 
> 
> No, the above change contradicts the behavior defined in 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>
> 
> You may want to go through the long discussion in the WG to pick a new
> attribute (ADDITIONAL-ADDRESS-FAMILY) for dual-stack allocation.

I still think it is unnecessarily complicated, but all right.

> 
>>
>> I think that this makes for simpler rules to implement and simpler text.
>>
>> Now some more specific comments about the text:
>>
>> - Title and abstract
>>
>> The draft should obsolete both RFC 5766 and RFC 6156, and that fact should
>> be repeated in the abstract.  The authors of RFC 6156 should be
>> acknowledged either in the Acknowledgment or Contributors section.
> 
> Done. 
> 
>>
>> - Section 5.
>>
>> The first item in the bullet list should say "the relayed transport address or
>> addresses;"
> 
> Updated line to say "All TURN operations revolve around allocations, and all TURN messages are associated with either a single or dual allocation."
> 
>>
>> In the the fourth item, there is one time-to-expiry per relayed transport
>> address.
>>
>> Same for the list of permissions in the fifth item.
>>
>> "Both the relayed transport address and the 5-tuple MUST be unique across
>> all allocations, so either one can be used to uniquely identify the allocation."
>>
>> With the dual allocation, the 5-tuple no longer uniquely identify an allocation.
> 
> Yes, fixed. 
> 
>>
>> - Section 6.2
>>
>> I would suggest to make ADDRESS-ERROR-CODE more generic by renaming it
>> as WARNING-CODE and use the same format than for ERROR-CODE.  Then
>> allocate a new error code for that specific warning.  I would suggest to
>> request the 0x8009 codepoint for that attribute.
> 
> I don't understand the need to change ADDRESS-ERROR-CODE !

To make it more generic and reusable in future specifications.

> 
>>
>> Also I think we needs two different warnings, one that states that dual
>> allocation is not available in a TURNbis server, but both protocols are
>> available, and another that says that dual allocation failed because one of
>> the two protocols is not available.  This is to let the client know that it is
>> useless to try another allocation for the missing protocol.
> 
> I don't get the reason for two different warnings. 

A server may support both IPv6 and IPv4 allocations and not support dual allocation, in which case the client can do a second allocation for the IPv6 relayed address.

Alternatively the server may not support IPv6 at all, in which case the second allocation will fail and was unnecessary.

Using two different warnings permits to know if the second allocation will succeed or not.

> 
>>
>> What is the policy when reserving the next port with the EVEN-PORT
>> attribute in a dual allocation, but one of them fails to find a pair of
>> subsequent ports available?
> 
> It's discussed in section 6.1
> 
> <snip>
>    Clients MUST NOT
>    include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request
>    that contains an EVEN-PORT attribute with the R bit set to 1.
> </snip>
> 
>>
>> It is not said that the Allocate successful response must contain two XRAs
>> after a successful dual allocation.
> 
> Good point, Updated draft. 
> 
>>
>> I would also suggest to add some text that says that when a TURNbis server
>> sends an Allocate success response, it must always send the XRAs in the
>> same order than the RAFs were sent.  So in case the server sends back by
>> mistake two XRAs, the first one matches the one requested by the client.
>>
>> The bullet list at the end needs also to be fixed for dual allocation.
> 
> Agreed, fixed. 
> 
>>
>> - Section 6.3
>>
>> Here's too, the text needs to be updated for the dual allocation case.
> 
> 
> Yup, updated.
> 
> Cheers,
> -Tiru
> 


-- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug