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

[Joe Touch <touch@xxxxxxxxxxxxxx>]

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.

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.

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

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

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

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

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. 

 

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