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

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

Hi Magnus,

Please see inline 

> -----Original Message-----
> From: Magnus Westerlund <[e-mail]>
> Sent: Tuesday, July 9, 2019 1:40 PM
> To: [e-mail]; Konda, Tirumaleswar Reddy
> <[e-mail]>; [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)
> 
> Hi,
> 
> A comment inline regarding MP-TCP.
> 
> 
> On Mon, 2019-07-08 at 21:19 +0000, Eric Vyncke (evyncke) wrote:
> > 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:
> >
> >
> >     >
> >     > == 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
> 
> So on the client to server path there is a possibility to use MP-TCP to
> potentially improve that specific leg of the communication. It can be
> negotiated in the TCP connection if desired. However, to be clear I
> don't think there is a reason to recommend and definitely not mandate
> MP-TCP support if one supports the TCP transport in the client to
> server interface. Also it creates a potentially interesting
> interactions between the framework using TURN, like ICE when a mobility
> events happen. It may also result in sub-optimal routing in cases where
> a client selects to use multiple interfaces to have one MP-TCP
> connection to one TURN server, rather than the best TURN server per
> interface.
> 
> Also, I think discussing MP-RTP here is missleading. Because with MP-
> RTP I would treat the TURN relayed address as one particular point of
> presence for the TURN client side implementation, in addition to any
> direct from the corresponding interface that may be possible to
> establish. There are some discussion of this in the MP-RTP draft.
> 
> So it would be possible to state that an TURN client MAY attempt to
> negotiate MP-TCP with the TURN server but support of MP-TCP in TURN
> servers are OPTIONAL. In addition TURN clients on hosts with multiple
> interfaces and access to multiple TURN servers should consider if there
> are certain interfaces and TURN server combinations that results in
> shorter paths, and therefore can benefit from using multiple TURN
> servers, even if they can be reached from multiple interfaces.

If the host has multiple interfaces and discovers multiple TURN servers, https://tools.ietf.org/html/rfc7982 discusses mechanism to influence the TURN server selection. I can add the following line:
If a host with multiple interfaces discovers a TURN server in each interface, the mechanism described in [RFC7982] can be used by the TURN client to influence the TURN server selection.

-Tiru

> 
> Cheers
> 
> 
> >
> >     >
> >     > -- 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.
> 
> I think I mostly agree with Eric here. So 576 is a recommendation on
> the IPv4 minimal required packet size reception capability. Then you
> have subtracted the overhead for TURN roughly. And still 576 bytes IPv4
> packets may be fragmented, the true minimal size is 68 bytes. And the
> use of an assumption of 1280 minus TURN overhead is almost as likely to
> not result in fragmentation as 500 bytes. Becasue the networks that
> will have issues with your 1200 payload is likely going to have issues
> with 500 bytes too. So from my perspective giving that very low
> recommendation does not reflect today's network. And the COAP
> recommendation of meeting 576 bytes total is for constrained devices
> and their link layers. TURN's primary users in media applications are
> normally not targeting that type of link layers that has such a limited
> MTU.
> 
> Cheers
> 
> Magnus Westerlund
> 
> 
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------