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

["Eric Vyncke (evyncke)" <[e-mail]>]

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