TCPM meeting, IETF 104, Prague Monday, March 25, 2019, 13:50-15:50 (Afternoon session I) Chairs: Yoshifumi Nishida (excused), Michael Scharf, Michael Tuexen Notetaker: Colin Bookham Note-well/Agenda bashing - RFC 8511 (draft-ietf-tcpm/alternativebackoff-ecn) is the only recent RFC. WG documents - 3 covered by presentations during session. - draft-ietf-tcpm-rto-consider-08 recent updates and progress on mailing list. Chairs waiting for reviews before moving to LC. - draft-ietf-tcpm-rack-04 has expired (to be discussed). - draft-ietf-tcpm-tcp-edo-10 expired. - draft-ietf-tcpm-rfc793bis-12 has been recently updated and is in pretty good shape. Chairs discussing what to do to move this document forward. - draft-touch-tcpm-2140bis-06 WG acceptance call finished. Understanding of chairs is that there is consensus to adopt this document. Draft-ietf-lwig-tcp-constrained-node-networks-05 - Presented at IETF 103 in LWIG and TCPM sessions - Work progressing on document to incorporate comments. - Feedback in general is pretty good, and authors believe the document is ready for LC. 0-RTT TCP Convert Protocol draft-ietf-tcpm-converters-06 Olivier Bonaventure - Converter protocol is an application-level protocol listening on a well-known TCP port. - Commands/responses are sent inside the SYN/SYN-ACK packets and are encoded as TLVs. - Provides 0-RTT to minimize connection establishment delays. - Converter advertises to clients the TCP options that it supports. Requires no encapsulation (uses plain transport mode). Main use-case is Multipath TCP. - Main changes from IETF 103. - Removed Error TLV from RSTs. - Simplified the design by removing TFO. Cookies are now embedded in the converter protocol. - Overview of Converter-Assisted MPTCP (MP_CAPABLE) session establishment (both when server supports MPTCP and does not support MPTCP). - Work on this document has been adoption from Broadband Forum for WT-378 and 3GPP for the ATSS service in 5G networks (TS 23.501). Praveen: Curious why TFO is not used. Olivier: Requirement is for cookie. Authors believe it is easier to put it in the SYN. Praveen: Using TFO API is probably cleaner. Mohamed: Previous versions used separate TFO, but feedback from other implementations prefer cookie in TLV. Olivier: Cookie in SYN is yet to be tested in the wild with middleboxes. But we have an application that can support the cookie in the TLV itself. Olivier: If there is a consensus of TFO option with zero length we are happy to adopt that approach. Chris: Test data shows no TFO option is better. Michael Scharf/chair: Can authors show how BBF and 3GPP are using this protocol? Mohamed: Preference would be to go Standards Track but would also be okay to remain experimental. - Ongoing implementation effort exists. - Chairs will be looking to move to WGLC soon (maybe before next meeting), but document does need update. More Accurate ECN Feedback in TCP / ECN++ draft-ietf-tcpm-accurate-ecn, draft-ietf-tcpm-generalized-ecn Mirja Kuehlewind / Bob Briscoe - Make ECN provide better feedback information than classic ECN. - AccECN provides more accurate information to the sender. - Optional AccECN TCP option to provide more information. Michael Scharf (from floor): Forward compatibility speculates that AccECN will the move-forward protocol, but it is only experimental. Bob: Meant to say that sentence AccECN forward compatibility applies to any future ECN solution. Gorry: Related to L4S which is also experimental, so there are two experiments here. Should we be concerned about running these two experiments in parallel? - AccECN implementation ported to latest v5.1 Linux kernel. - Authors have addressed all comments, and draft has been around for a while. No further comments from floor. - Document to be updated with minor clarity edits. - ~10 people have read current or previous version of document. - No concerns from floor about moving document to WGLC soon. Bob: Overview of bugfix to prevent ECN++ disabling ECN on 84% of servers. Individual documents Transmission Control Protocol (TCP) YANG Model draft-scharf-tcpm-yang-tcp Michael Scharf Presented new document in TCPM and raises question on whether WG needs to work on a YANG model for TCP. - TCP used by many control and management plane protocols. - Requires TCP stack configuration and monitoring on network elements. - Some vendors have implemented TCP MIB per RFC 6643, but SNMP MIBs are being replaced by YANG modules. - Overview of existing TCP MIB and mapping to YANG model (mostly read-only/monitoring). - Question is whether to do a straightforward replace of the MIBs in RFC 6643 in YANG or should it be extended as a successor of the MIB. Mikael Abrahamsson: Statement not question. We’re using YANG to administer everything – I would like a comprehensive TCP YANG model. Please do not translate the existing TCP MIB. Lars: Remembers when WG did the MIBs and it was super-painful. Unless there is a line of operators that want this, I would not do it as it’s going to be painful. There is almost no commonality across TCP stacks, which is what makes it hard. Mohamed: We can find a balance. If we see some existing YANG models such as BGP, it has some generic TCP parameters that can be re-used. I support this work. Mikael Abrahamsson: I’ll take less if required (this is not an all-or-nothing deal). There must be a base of baseline functionality that all stacks share. We can start there. It doesn’t have to be perfect day one. Lars: This will get very complicated very quickly. It changes with every kernel version. Re-iterated that we shouldn’t do this. Philipp S. Tiesel: Looking at this from TAPS perspective, if we could import this stuff it would be useful. Some discussion with Michael Tuexen around whether this would make the whole thing more complicated. - This is a placeholder and we don’t need to come to conclusion today. - Proposal from Michael is to have another talk on this at the next meeting unless WG believes we should stop any further effort in this. DNS Transport over TCP - Operational Requirements draft-ietf-dnsop-dns-tcp-requirements Duane Wessels - Encourages the practice of permitting DNS messages to be carried over TCP. - Large responses cause issues – the choice is to fragment or truncate which means DNS clients need complex retry logic. - RFC 7766 DNS Transport over TCP Implementation states that TCP may be used first without trying UDP but does not make recommendations to operators. - This draft encourages operators to ensure that DNS over TCP is on par with UDP and focuses on the operational requirements. - Overview and some detail on connection management/termination. Praveen: Is there any study about current levels of the use of DNS over TCP? Duane: There probably are for DNS over TLS – maybe 1% or 2%. Praveen: Are there any recommendations for using TCP first over UDP? Duane: No current recommendations. Tommy: Thanks for doing this. Concern about saying all servers SHOULD use TFO (perhaps use MAY, and perhaps indicate there are known issues with TFO). Second comment is to recommend the use of DNS over TLS. Jana: Also suggested using the MAY wording. TCP advancements in Windows Praveen Balasubramanian Improving TCP stack in windows on nearly 800 million devices running Windows 10. - Overview/recap of TCP improvements Jana: When did you change from compound to cubic? Praveen: About a year and half back. Latency fluctuations e.g. in virtualized environments caused compound issues that are much better dealt with by cubic (in terms of throughput). - Improved slow start using HyStart and Limited Slow Start after exit. Jana: Very interesting. Short discussion on HyStart exit and use of LSS after HyStart exit. - RACK updates: Compliant with draft-ietf-tcpm-rack-04 which has expired. Request to WG to try and move this document forward on standards track. Chairs will speak with authors. Hiren: How does RACK and 3 DUPACK work together? Praveen: Explanation on use. Hiren: Have you looked at PRR? Praveen: Yes, currently looking at it. Felix: Both loss detection algorithms do you have data on when DUP ACK is better than RACK? Praveen: No data on which one is better. Randall: Middleboxes sometimes strip out SACK options, and in that case DUP ACK is better. - Lower Initial RTO Jana: Is there any data to see if initialRTO of 1 second would cause retransmissions. Praveen: No measured data, but it is possible get statistics from TCP. Mikael: Is ECN on by default? Praveen: Server is on, client is off. Mikael: Would you consider setting client to on by default? Praveen: Currently experimenting with TFO. Mikael: Does this relate to the XBOX stack as well? Praveen: Yes. QUIC Loss Detection and Congestion Control draft-ietf-quic-recovery Jana Iyengar QUIC Overview - Long header – only used for handshake/session establishment - Short header – only has a few fields – used after session establishment. - Frames: different types with different sets of fields; note ACK and STREAM. STREAM carries application data. ACK is acknowledgement. - QUIC connection can have multiple streams where each one has a stream ID. STREAM data has offset field. - Each Packet may have multiple stream frames, and each stream frame may have a different stream ID. A packet may even carry multiple stream frames and an ACK frame. - ACK frame contains highest packet number seen so far (not necessarily in sequence), time since largest ACKed was received, and contiguous ACK ranges. - Stream IDs and stream offsets are used to define delivery order. - Should ACK every other packet (subject to 25ms delayed ACK timer) Eric: Is 25msec for an ACK latency fixed and is that short for high-latency connections? Jana: No impact for high latency connections as this is not related to RTT. - If no ACKs are received, Probe Timeout (PTO) sends 1 or 2 probe packets. Timeout does not necessarily mean packet loss. When ACK comes back QUIC does the calculation of packet loss. Gorry: What does a probe packet contain? Jana: Suggestion is to send new data. Praveen: Current draft suggests new data, otherwise highest packet from old data. Jana: Believe similar text exists in QUIC draft. Hiren: Does QUIC follow RACK and TLP as per the RACK draft? Jana: No, but we need to look at those drafts and make sure we are aligned. End of Meeting.