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

[Joe Touch <touch@xxxxxxxxxxxxxx>]

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.

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.

Joe