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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@xxxxxxxxxx> · Fri, 21 Jun 2019 09:35:03 +0000

Hi Joe,

Please see inline [TR1]

From: Joe Touch <touch@xxxxxxxxxxxxxx> 

Sent: Friday, June 21, 2019 11:34 AM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx>

Cc: Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>; tram@xxxxxxxx; Brandon Williams <brandon.williams@xxxxxxxxxx>; draft-ietf-tram-turnbis.all@xxxxxxxx; tsv-art@xxxxxxxx; ietf@xxxxxxxx

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.

Hi, Tiru,

On Jun 20, 2019, at 3:46 AM, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx> wrote:

Hi Joe,

Please see inline [TR]

...

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 ?

Sec 14 could be “UDP relay”

Sec 15 could be “Mixed transport relay” or “TCP/UDP and UDP/TCP relay”

In both cases, the issue isn’t to focus on the IP header fields.

[TR1] Okay. Updated Section 14 title  to “UDP-to-UDP relay”, Section 15 “TCP-to-UDP relay” and added new Section 16 “UDP-to-TCP relay”

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

It’s not a note. It’s the point. You don’t set the outgoing to the incoming per se; you set the *TCP connection* to use the DSCP of the first UDP packet.

[TR1] Agreed, updated text as follows:

      The TCP connection can only use a single DSCP
      code point so inter flow differentiation is not possible, see
      Section 5.1 of [RFC7657].  The server sets the outgoing value to
      the DSCP code point used by the TCP connection, unless the server
      includes a differentiated services classifier and marker
        [RFC2474].

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

Again, you’re talking about building a network layer packet header. The point is that you should be describing this in terms of “setting the UDP packet to not fragment”. That is NOT merely IP DF=1; that would only prevent *in-network* fragmentation.
 You need to tell UDP not to source fragment too.

And all of this should be described in a way that doesn’t imply that the only approach is to have the user build the packet all the way to the IP headers.

Here’s why it matters - an IPv4 packet can *already be source fragmented* and still have the individual fragments set DF=0. DF=0 just means the *network* should not sub-fragment what it receives, not that the packet is “atomic” (not fragmented
 a the source AND not fragmentable by the network)

[TR1] Got it, Thanks for the clarification. Updated text as follows:
When the server sends a packet to a peer in response to a Send indication containing the DONT-FRAGMENT attribute, then set the outgoing UDP packet to not fragment.

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

The server doesn’t ignore the the fragment fields of the received packets; it uses them to reassemble (by the IP stack). They are ignored in terms of whether to set the *transport* to avoid UDP using source fragmentation. Again, though,
 this isn’t about setting IP header fields.

[TR1] Okay, fixed as follows:
If the TCP traffic arrives over IPv6, the server relies on the presence of DON’T-FRAGMENT attribute in the send indication to set the outgoing UDP packet to not fragment.

              - 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 inhttps://tools.ietf.org/html/rfc6274.
 What IP4 options and IPv6 extension headers are default ?

By “default” I’m referring to system-wide configurations to use particular IP options. Your description appears to prevent their use; are you actively prohibiting all IP options? Even system-wide defaults, if so configured?

[TR1] No, system defaults are not prohibited. 

          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 ?

You would be expecting the transport to override a system-wide network default, which may not be possible on some systems.

You can probably just say “use system defaults”.

[TR1] Works for me, updated both IPv4 option and IPv6 extension headers in all sections.

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
seehttps://tools.ietf.org/html/rfc7657#section-5.3

OK, but then you need to say *in this section* how you expect to set the TCP DSCP. The text is confusing - it talks about “server-to-client” matching “client-to-server” - that’s just the other direction of the same TCP connection. If you
 are referring to other endpoints or transport protocols, be specific and clear. 

[TR] I will modify the text as follows:
Ignore the incoming DSCP value. When TCP  is used between the client and the server, a single DSCP should be used for all traffic on that TCP connection. Note, TURN/ICE occurs before application data is exchanged.

-Tiru

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 <TirumaleswarReddy_Konda@xxxxxxxxxx> 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

_______________________________________________

Tsv-art mailing list

Tsv-art@xxxxxxxx

https://www.ietf.org/mailman/listinfo/tsv-art