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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

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

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

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