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

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

Hi Marc,

Please see inline

> -----Original Message-----
> From: Marc Petit-Huguenin [mailto:[e-mail]]
> Sent: Saturday, March 3, 2018 2:47 AM
> To: Konda, Tirumaleswar Reddy
> <[e-mail]>; [e-mail]
> Subject: Re: [tram] Review of dual allocation in TURNbis-11
> 
> As suggested by Brandon, I reviewed turnbis-14 for the modifications agreed
> on below, and found some discrepancies.  See inline.
> 
> On 02/09/2018 04:51 AM, Konda, Tirumaleswar Reddy wrote:
> >> -----Original Message-----
> >> From: Marc Petit-Huguenin [mailto:[e-mail]]
> >> Sent: Sunday, October 22, 2017 9:38 PM
> >> To: Konda, Tirumaleswar Reddy
> >> <[e-mail]>; [e-mail]
> >> Subject: Re: [tram] Review of dual allocation in TURNbis-11
> >>
> >> 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
> >>>>
> 
> [snip]
> 
> >>>
> >>>>
> >>>> - 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.
> >
> > ADDRESS-ERROR-CODE cannot use the same format as ERROR-CODE,
> ADDRESS-ERROR-CODE signals the IP address family for which the warning is
> generated + all the fields in the 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.
> >>
> >> 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.
> >
> > If the server does not support dual allocation but supports both IPv6 and
> IPv4 allocations, it will only allocate the IPv4 relayed address and not will not
> return ADDRESS-ERROR-CODE in the response, the client will know the
> server does not understand the ADDITIONAL-ADDRESS-FAMILY attribute
> (ADDITIONAL-ADDRESS-FAMILY is a comprehension-optional attribute).
> >
> >>
> >> Alternatively the server may not support IPv6 at all, in which case
> >> the second allocation will fail and was unnecessary.
> >
> > ADDRESS-ERROR-CODE signals both unsupported IP address type (0x02
> (IPv6 address family)) and the reason for failure (440 (unsupported address
> family)).
> >
> > Cheers,
> > -Tiru
> >
> >>
> >> 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 cannot find this update in turn-14.

This comment is partially addressed in -12 revision, step 9 (in Section 6.2 in -12 revision and Section 7.2 in -14 revision) is updated to discuss dual allocation. 
<snip>
If the server can fully meet
the request, then the server allocates one IPv4 and one IPv6
relay address, and returns an Allocate success response
containing the relayed transport addresses assigned to the dual
allocation.
</snip>

NEW:
If the server can fully meet
the request, then the server allocates one IPv4 and one IPv6
relay address, and returns an Allocate success response
containing the relayed transport addresses assigned to the dual
allocation in two XOR-RELAYED-ADDRESS attributes.

> 
> >>>
> >>>>
> >>>> 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.
> 
> Did not get answer to that and did not see it in turn-14.

I did not get this comment. If a request contains both REQUESTED-ADDRESS-FAMILY and ADDITIONAL-ADDRESS-FAMILY attributes, the request is rejected by the server. Further, only IPv6 address family is allowed in the 
ADDITIONAL-ADDRESS-FAMILY attribute.


> 
> >>>>
> >>>> 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.
> >>>
> 
> Same, there is no update since -11 in section 7.3 (formerly 6.3)

This comment is addressed in -12 revision itself, the updated text uses "relayed transport address or addresses" and " address family or families" to discuss the 
dual allocation case.

Cheers,
-Tiru

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