> -----Original Message----- > From: Joe Touch <touch@xxxxxxxxxxxxxx> > Sent: Thursday, June 6, 2019 7:18 PM > To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx> > Cc: tsv-art@xxxxxxxx; draft-ietf-tram-turnbis.all@xxxxxxxx; ietf@xxxxxxxx; > tram@xxxxxxxx > Subject: Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis- > 25 > > This email originated from outside of the organization. Do not click links or > open attachments unless you recognize the sender and know the content is > safe. > > > > > On Jun 6, 2019, at 9:12 AM, Konda, Tirumaleswar Reddy > <TirumaleswarReddy_Konda@xxxxxxxxxx> wrote: > > > > Hi Joseph, > > > > Thanks for the review, Please see inline > > > >> -----Original Message----- > >> From: tram <tram-bounces@xxxxxxxx> On Behalf Of Joseph Touch via > >> Datatracker > >> Sent: Wednesday, June 5, 2019 11:34 AM > >> To: tsv-art@xxxxxxxx > >> Cc: draft-ietf-tram-turnbis.all@xxxxxxxx; ietf@xxxxxxxx; > >> tram@xxxxxxxx > >> Subject: [tram] Tsvart last call review of draft-ietf-tram-turnbis-25 > >> > >> This email originated from outside of the organization. Do not click > >> links or open attachments unless you recognize the sender and know > >> the content is safe. > >> > >> Reviewer: Joseph Touch > >> Review result: Ready with Issues > >> > >> This document has been reviewed as part of the transport area review > >> team's ongoing effort to review key IETF documents. These comments > >> were written primarily for the transport area directors, but are > >> copied to the document's authors and WG to allow them to address any > >> issues raised and also to the IETF discussion list for information. > >> > >> When done at the time of IETF Last Call, the authors should consider > >> this review as part of the last-call comments they receive. Please > >> always CC tsv- art@xxxxxxxx if you reply to or forward this review. > >> > >> As a preface, this review is performed focusing on the changes since > >> RFC 5766, as this document appears to be a fairly direct update of that > content. > > > > Yes. > > > >> > >> Transport issues: > >> > >> Although this document has substantial implications for transport > >> protocols, it does not significantly alter the content of RFC5766 in > >> this regard. However, there is a significant gap as follows: > >> > >> - The direct translation of TCP into UDP or UDP into TCP is arguably > >> a host endpoint emulation function, which strongly suggests that this > >> document needs to explicitly address both receiving and transmitting > transport options. > >> Even if all received options are ignored and no options are used on > >> transmission, that should be more directly stated – as well as the > >> impact of that decision, both on functionality and security. > > > > The specification has two sections 14 and 15 (IP Header Fields for UDP-to- > UDP translation and IP Header Fields for TCP-to-UDP translation) to discuss > direct translations. https://tools.ietf.org/html/rfc5766 only covered UDP-to- > UDP translation in Section 12. > > Yes, but both sections ignore the impact of transport options - both current > for TCP and pending for UDP. These are ignored both when packets with > such transport options are received (the input packet to the translation) and > whether / how they are used on transmit (the output packet) TURN is used to relay real-time data (e.g. audio and video streams) and the approach taken by VOIP related specifications is to avoid fragmentation for RTP packets. > > > > >> > >> Sec 2.7 might also note that the support for UDP fragmentation and > >> reassembly could be of benefit here in avoiding IP fragmentation, but > >> that would be contingent on the previous note – i.e., being able to > >> use and react to UDP options in the translation process. > > > > I don't get the comment, what specific change are you looking in the > document ? > > The doc currently indicates that UDP relies only on IP fragmentation, but this > isn’t the case with UDP options (there is a UDP-level frag and reassembly > that preserves port numbers on each fragment and would thus be TURN- > compatible). Okay, I will add the following line: However, Section 5.7 in https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-07 discusses Fragmentation option to support UDP fragmentation and reassembly to transfer UDP messages larger than the IP receive MTU. > > > > >> > >> Non-transport issues: > >> > >> Like RFC 5766, this doc continues to cite > >> I-D.rosenberg-mmusic-ice-nonsip as guidance, even using a gentle > >> version of “must”, but this no longer seems appropriate because that > >> document has expired over a decade ago. Either the guidance should be > >> summarized in this document or the recommendation should be removed. > > > > Good point, Revised ICE specification (https://tools.ietf.org/html/rfc8445) > has been updated to make the procedures independent of the signaling > protocol by removing the SIP and SDP procedures. > > > > I have updated the text as follows: > > > > For example, if TURN and ICE are used as part of a multimedia > > solution using SIP [RFC3261], then SIP serves the role of the > > rendezvous protocol, carrying the ICE candidate information inside > > the body of SIP messages [I-D.ietf-mmusic-ice-sip-sdp]. If TURN and > > ICE are used with some other rendezvous protocol, then ICE provides > > guidance on the services the rendezvous protocol must perform. > > > >> > >> Section 2.7 is incorrect in its claim of 576 for IPv4; it confuses > >> the receiver reassembly minimum (EMTU_R, 576) for the link MTU > >> (EMTU_S, 68). See draft-ietf-tunnels for details. If 576 is the > >> focus, at best it could be claimed that 576 is the “de-facto” EMTU_S for > IPv4. Other nits: > > > > Section 2.7 says IPv4 host must be capable of receiving a packet whose > length is equal to 576 bytes (EMTU_R, 576). > > Why do you say the text is incorrect ? > > 576 is the reassembly MTU, but is also referred as the PMTU. The PMTU is > EMTU_S and is strictly only 68. Got it, I will update the text as follows: If IPv4 support on legacy or otherwise unusual networks is a consideration, the application MAY assume on an effective MTU of 576 bytes for IPv4 datagrams, as every IPv4 host must be capable of receiving a packet whose length is equal to 576 bytes as discussed in [RFC0791] and [RFC1122]. Cheers, -Tiru > > >> > >> Sec 23 indicates the changes since RFC5766; a similar section > >> addressing changes since RFC6156 would be useful to add. > > > > Okay, added another Section (updates to RFC6156). > > > > Cheers, > > -Tiru > > > >> > >> > >> _______________________________________________ > >> tram mailing list > >> tram@xxxxxxxx > >> https://www.ietf.org/mailman/listinfo/tram > > _______________________________________________ > > Tsv-art mailing list > > Tsv-art@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/tsv-art
