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

[Magnus Westerlund <[e-mail]>]

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. 

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