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

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

Hi Joe,

Please see inline [TR]

From: Joe Touch <[e-mail]>
Sent: Thursday, June 20, 2019 6:00 AM
To: Konda, Tirumaleswar Reddy <[e-mail]>
Cc: Magnus Westerlund <[e-mail]>; [e-mail]; Brandon Williams <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-25


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Tiru,

This sort of patch isn’t sufficient. It doesn’t address the confusion throughout section 15 as to what’s actually happening.

Sec 15 shouldn’t talk about “setting” IP header values at all; it should refer to “configuring transport sessions” in the desired ways. Otherwise you’re implying direct packet-level conversion. Even the title of that section is a problem in this regard.

[TR] What title do you want me to use for Section 15 ?

Tthe sections themselves should be revised to similarly refer to transport-level actions, not packet level, e.g.:
15.1 TCP to UDP
              - because DSCP should not vary within a TCP session, there is no packet-level tracking of copying DSCP from TCP to UDP; instead, DSCP would be a property of the TCP session that would be used to configure the UDP socket pair.

[TR] Agreed, but the text looks correct to me. It says “Note, the TCP connection can only use a single DSCP code point so inter flow differentiation is not possible”.

              - IP fragmentation control needs to be explained in terms of UDP interactions

[TR] Yes, DONT-FRAGMENT attribute in the TURN message is used to set the DF bit in the outgoing IP header to 1. What specific change are you expecting ?

              - IPv6 fragmentation has nothing to do with the received packet (which is TCP

[TR] Same as above,  DONT-FRAGMENT attribute in the TURN message is used to set the DF bit in the outgoing IP header to 1.

              - IP options are *as default*; it’ isn’t correct that you never use IP options (or are you actively disabling them?)
                              NOTE: that goes for the direct IPv4 to IPv6 translation in section 4 (which is similarly problematic)

[TR]   I am not aware of default IPv4 options and extension headers, and I don’t see any default IPv4 options discussed in https://tools.ietf.org/html/rfc6274. What IP4 options and IPv6 extension headers are default ?
          RTP/RTCP do not use any IPv4 options and IPv6 extension headers. What is the loss of functionality if IP options and extension headers are not set by the TURN server for outgoing UDP packets to the peer ?


15.2 UDP to TCP
              - the last sentence of the second paragraph seems at odds with the first; the first says “set these once per connection”, it is sufficient IMO.

[TR] Okay, removed the last sentence of the second paragraph.

              -TCP DSCP should be based on the *first* UDP value seen (it could vary)

[TR] No, the client first establishes TCP connection with the server and exchanges TURN messages for allocation and permission, UDP packets can only be sent by the peer after permission is created. Please see https://tools.ietf.org/html/rfc7657#section-5.3

Cheers,
-Tiru

              - same issue with IP extension headers and options (presumably you use the default

Joe


On Jun 19, 2019, at 8:14 AM, Konda, Tirumaleswar Reddy <[e-mail]<mailto:[e-mail]>> wrote:

Hi Joe,

The IPv4 and IPv6 fragmentation description is specific to TCP-to-UDP relaying between the client and the peer (only for TCP-to-UDP relay, the DF attribute in the TURN message will be used to set the DF bit in the outgoing UDP packet to the peer). To avoid confusion, I have added two new sub-sections:
15.1.  IP Header Fields for TCP-to-UDP relaying and 15.2 IP Header Fields for UDP-to-TCP relaying

Please see the attached updated draft.

Cheers,
-Tiru