Re: [tram] Éric Vyncke's No Objection on draft-ietf-tram-turnbis-27: (with COMMENT)

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

Hi Eric,

Please see inline

> -----Original Message-----
> From: Eric Vyncke (evyncke) <[e-mail]>
> Sent: Tuesday, July 9, 2019 2:49 AM
> To: Konda, Tirumaleswar Reddy
> <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [tram] Éric Vyncke's No Objection on draft-ietf-tram-turnbis-27:
> (with COMMENT)
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> Tiru
> 
> Thank you for your reply and your comments and actions.
> 
> Please see remaining points inline for lines starting with EV>
> 
> Regards
> 
> -éric
> 
> On 08/07/2019, 15:55, "Konda, Tirumaleswar Reddy"
> <[e-mail]> wrote:
> 
>     Hi Eric,
> 
>     Thanks for the review. Please see inline
> 
>     > -----Original Message-----
>     > From: tram <[e-mail]> On Behalf Of Éric Vyncke via
>     > Datatracker
>     > Sent: Sunday, July 7, 2019 1:49 PM
>     > To: The IESG <[e-mail]>
>     > Cc: [e-mail]; [e-mail]; [e-mail];
>     > [e-mail]
>     > Subject: [tram] Éric Vyncke's No Objection on draft-ietf-tram-turnbis-27:
>     > (with COMMENT)
>     >
> 
>     > For my own curiosity, isn't TURN scope broader than plain NAT: can it also
> be
>     > useful in the absence of NAT if inbound 'connection' are blocked by
> security
>     > policy ?
> 
>     Interactive Connectivity Establishment (ICE) helps solve the above problem
> by performing connectivity checks, but direct UDP connection will not be
> possible even with ICE if both endpoints are behind NATs that perform
> address and port dependent mapping. In addition, Enterprise firewall may
> block direct UDP connections but allow UDP traffic relayed through an
> Enterprise TURN server (please see
> https://tools.ietf.org/html/rfc7478#section-2.3.5.1).
> 
> EV> I am familiar with ICE __ and your last sentence is exactly what my initial
> comment was about: please goes beyond the NAT typical/common use case
> of TURN and also cite the firewall blocking inbound UDP. Just to improve
> understanding by the readers.

Sure, added the following paragraph to the Introduction section :

   In many enterprise networks, direct UDP transmissions are not
   permitted between clients on the internal networks and external IP
   addresses.  To permit media sessions in such a situation to use UDP
   and to avoid forcing the media sessions through TCP, Enterprise
   Firewall can be configured to allow UDP traffic relayed through an
   Enterprise relay server.  This scenario is required to be supported
   by the WebRTC requirements (Section 2.3.5.1 in [RFC7478]).


> 
>     >
>     > == COMMENTS ==
> >
>     > -- Section 3.1 --
>     >
>     > Is there any reason why MPTCP is not specified for the communication
>     > between TURN client and TURN server? There is a very short explanation
> in
>     > section 15 "TCP multi-path is not used by both SIP and WebRTC protocols
>     > [RFC7478] for media and non-media data" but it does not address the use
> of
>     > MPTCP between TURN client/server.
> 
>     TURN is typically used by SIP and WebRTC protocols to relay media streams,
> but RTP assumes a single path and make decisions based on the measured
> characteristics of this single path (with the exception of Multipath RTP
> discussed in https://tools.ietf.org/html/draft-ietf-avtcore-mprtp-03).
> 
> EV> suggest to add an informative reference to the I-D

draft-ietf-avtcore-mprtp has expired couple of years back. I don't think a reference to MPRTP is required.

> 
>     >
>     > -- Section 3.7 --
>     >
>     > The 500 bytes guideline to avoid fragmentation, is there any data backing
> the
>     > sentence "...will generally avoid IP fragmentation." ?
> 
>     Yes, If the PMTU is not known, and on legacy or otherwise unusual
> networks the guideline should work (see
> https://tools.ietf.org/html/rfc7252#section-4.6 and
> https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-08).
> 
> EV> RFC 7252 is about CoAP and is not "a guideline" per se but a reference to
> the IPv4 'assumed' MTU of 576. I would prefer a reference to RFC 7252 with
> 576 for IPv4 and 1280 for IPv6 for MTU. I am afraid that giving the number
> "500" is kind of misleading the reader. At the bare minimum, I suggest to add
> the reference to COAP, and use the number from CoAP if you want to
> specify numbers.

The above IPv4/IPv6 numbers are used in several other specifications by only referring to [RFC791] and [RFC1122], for example see SIG-002 in https://tools.ietf.org/html/rfc8612 

Cheers,
-Tiru

> 
> 
>