Re: [tram] [Tsv-art] Tsvart last call review of draft-ietf-tram-turnbis-25

[Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>]

On 2019-06-17 12:44, Konda, Tirumaleswar Reddy wrote:

You need to address these issues - e.g., by a version of the response above.

[TR1] Okay, will add the following lines:

TCP multi-path [RFC6824] is not supported by this version of TURN because TCP multi-path is not used by both SIP and WebRTC protocols [RFC7478] for media and non-media data. If the TCP connection between the TURN client and server uses TCP-AO [RFC5925], the client must secure application data (e.g. using SRTP) to provide confidentially, message authentication and replay protection to protect the application data relayed from the server to the peer using UDP.  Note that TCP-AO option obsoletes TCP MD5 option.  Unlike UDP, TCP without the TCP Fast Open extension [RFC7413] does not support 0-RTT session resumption. The TCP user timeout [RFC5482] equivalent for application data relayed by TURN is the use of RTP control protocol (RTCP). As a reminder,  RTCP is a fundamental and integral part of RTP.

Sorry, I find this very confusing. On the Client to TURN Server leg if that is using a TCP connection, then there are no issues with using either TCP-MP or TCP-AO options on that leg. They will have no impact on the TURN messages carried inside the TCP connection or how its outgoing IP/UDP packet. So from my perspective there are no necessity to discuss these as not supported.

What is discussed in this document are the options for the IP/UDP packet being sent or received by the turn server to the peer. Those IP/UDP Fields that can be controlled and have meaning are discussed here. Like the DSCP, where TCP will force the use of a single one, when UDP to UDP can support many as the field value is taken from the packet on the client to server leg, rather than an internal TURN message field.

I guess the issue here is that there is a lack of requirement making clear that for a number of the fields in the IP/UDP handled on the server to peer leg that needs to handling rules for the client to server transport.

I think what Section 14 and 15 talks about should be labeled relaying and not translation. And thus focus on how one avoid information or intent loss in the relay process. I understand why section 13 is called translation, but when we get down to it, it is the same here, but a focus on how the relay process maintain information of the IP layer, especially in the face of address family differences.

Cheers 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx
----------------------------------------------------------------------