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

["Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@xxxxxxxxxx>]

Hi Joe,

 

Please see inline [TR3]

 

From: Joe Touch <touch@xxxxxxxxxxxxxx>
Sent: Tuesday, June 18, 2019 8:00 PM
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.

---

See end...

On Jun 18, 2019, at 1:31 AM, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx> wrote:

 

Hi Joe,

 

Please see inline [TR2]

 

From: tram <tram-bounces@xxxxxxxx> On Behalf Of Joe Touch
Sent: Monday, June 17, 2019 7:48 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx>
Cc: Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>; ietf@xxxxxxxx; Brandon Williams <brandon.williams@xxxxxxxxxx>; draft-ietf-tram-turnbis.all@xxxxxxxx; tsv-art@xxxxxxxx; tram@xxxxxxxx
Subject: Re: [tram] [Tsv-art] 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.

---

 

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

 

Hi Joe,

 

Please see inline [TR1]

 …

On Jun 13, 2019, at 1:42 AM, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx> wrote:

 

...
The description in the document implies packet-to-packet translation, which
seems dangerous (even as a description). This is especially true for the
notion that each UDP packet is translated into exactly one TCP frame directly.

The TURN specification only discusses packet-to-packet translation for UDP-to-UDP relay and not for TCP-to-UDP relay.

 

Sec 15 talks about setting IP fragmentation based on the received messages. If this is not based on packet-to-packet translation, can you explain how this can be achieved? TCP sets DF for a connection, not on a per packet basis

 

[TR] It is not based on packet-to-packet translation. TURN client can set the DON’T-FRAGMENT attribute in the TURN message to tell the TURN server to set the DF bit in the resulting UDP datagram sent to the peer. Please seehttps://tools.ietf.org/html/draft-ietf-tram-turnbis-25#section-15

The section notes that only a single DSCP can be set for a TCP connection. A similar note should be included in the discussion of IP fragmentation and IP options  - these too can be set on a per-message basis for UDP, but not for TCP.

[TR1] Section 15 discusses both IP fragmentation and IP options, see https://tools.ietf.org/html/draft-ietf-tram-turnbis-25#section-15

It does, but incorrectly implies these are per packet decisions. As with that section’s description of DSCP, the descriptions of IP fragmentation and IP options need to indicate these are either not under user control (IP fragmentation) or per-connection (IP options) for TCP.

 

[TR2] No, the section does not say per-packet translations. Please see the below snip from Section 15

<snip>

      Preferred Behavior: When the server sends a packet to a peer in

      response to a Send indication containing the DONT-FRAGMENT

      attribute, then set the DF bit in the outgoing IP header to 1.  In

      all other cases when sending an outgoing packet containing

      application data (e.g., Data indication, ChannelData message, or

      DONT-FRAGMENT attribute not included in the Send indication), set

      the DF bit in the outgoing IP header to 0.

</snip>

 

Loosely restated, this says:

             

              when you get TURN message X, set the IP header as follows

 

That implies that each TURN message affects a single IP header. That implies packet translation, not content relay - especially because it cannot work for TCP content relay, where IP options cannot be controlled  mid-connection on a per-user-message basis....

 

[TR3] The above text is only for TCP-to-UDP relay, DF bit will be set in the outgoing UDP packet. The specification does not support TCP-to-TCP relay.

Again, despite claims of intent, this document’s description of all these translations inappropriately implies they are per-packet decisions throughout. This should further be corrected with some explicit text indicating otherwise - as has been noted throughout this thread.

 

[TR2] I will add the following line to avoid confusion:

 

Note that the server does not preform per-packet translation for TCP-to-UDP translation and vice-versa.

 

That seems reasonable, but….

The TURN server sets various fields in the IP header based on the DONT-FRAGMENT attribute in the TURN message and on a per-connection basis for the TCP connection.

 

That’s still confusing.

 

You’re not setting IP header values; you’re setting TCP or UDP parameters (which you hope will affect IP values).

 

Is this also based on the DF attribute in the TURN message, or would it be equally valid (and much more clear) to say that it is based on the DF value of a **TURN session***? I.e., what happens if you receive more than one TURN message with different DF parameters (itor if this is strictly prohibited, please cite where that is mandated).

 

[TR3] 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. I will re-phrase the text as follows:

 

Note that the server does not perform per-packet translation for TCP-to-UDP relay and vice-versa. For TCP-to-UDP relay, the TURN server sets the DF field in the outgoing UDP packet based on the presence of DONT-FRAGMENT attribute in the TURN message. For UDP-to-TCP relay, the TURN server sets various IP header fields in the TCP packets on a per-connection basis for the TCP connection.

 

Cheers,

-Tiru

 

Joe