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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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>

 

 

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

 

Cheers,

-Tiru

 

Joe

 


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux