TCPM meeting, IETF-112, online Thursday, November 11, 2021, 12:00 - 14:00 UTC (120 mins) WG Chairs: M. Scharf, Y. Nishida, M. Tuexen Note Taker: Gorry Fairhurst 1. WG Status Updates Agenda presented, no changes requested. draft-ietf-tcpm-rfc793bis is now in IESG Evaluation::Revised I-D Needed. Some review comments could benefit from discussion on the list, Wes will post emails as needed. HyStart++ is being implemented and will be presented next meeting. This meeting might be Michael Scharf's last one as a Chair, the plan is to step down after RFC793.bis is processed. 2. Working Group Items 2.1 RFC 6937bis: Proportional Rate Reduction for TCP https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-prr-rfc6937bis-01 Speaker: Yuchung Cheng (proxied by Chairs) Authors plan to submit a new revision for the next IETF meeting. Yoshifumi noted there were changes and asked if the changes were already in mainline. Neal C.: I believe the .bis will reflect the changes and will cover logic in Linux TCP Richard S.: Upcoming revision of BSD will address this, and have provided comments to authors. 2.2 RFC 8312 bis: CUBIC for Fast and Long-Distance Networks https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc8312bis-05 Speaker: Vidhi Goel Issues being tracked in github and are being addressed. There have been recent changes, see slides. There are Open Issues considering spurious congestion events. Plese read and send comments to the list. Stuart Cheshire: Noted there could be wireless issues from a sudden reduction in capacity, where Cubic took many RTTs to make a x10 reduction in rate. Praveen B.: Are the changes being made also reflected in the stacks being implemented today? Vidhi: We are trying to allow options, and avoid requiring changes. The ECN change (see slides) is one that ought to be changed - this reflects not just Linux, but other cases too. Neal C.: I'd like to encourage keeping the text on "undo" of variables after spurious ordering detection. Regarding cellular and Wireless - we didn't generally see losses from wireless segments so agree with Stuart about the main effect being physical layer rate changes. Lars E.: The main motivation was to document what was implemented. Markku's review noted places of conflict with the RFC Series. I think some of the changes reflect actual deployed code, rather than the previously specified methods. Ian S.: I think we should be careful to not include things that are required, but not implemented. Michael T.: I would note the differences between what major implementations do not want to do, and what they may implement in future. Vidhi: On using 'cwnd' instead of Flight_Size wasn't documented in the RFC series, so we needed to be careful. Lars: The current cubic draft updates an RFC that is PS. Michael T.: This normatively uses HyStart++ (SHOULD), and this is a dependency. Lars: HyStart++ is the only standards-track spec. in that space. Praveen: We're looking for others to implement the update to the latest spec., and hope to see this go to WGLC soon. Chairs: We expect to ask the WG to confirm the changes to the final version. 2.3 TCP YANG model - update https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-yang-tcp-04 Speaker: Michael Scharf Upcoming changes in -05. Suggest documenting differences with draft opsawg-l3sm-l3nm, and could add a new appendix to differentiate with the TCP-MIB (RFC4022). Martin Duke: What is the reasoning behind doing the comparison with the TCP MIB? Michael S: For those already implementing the MIB, this could help and understand the differences. 2.4 TCP-AO Test Vectors draft status https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-ao-test-vectors-02 Speaker: Juhamatti Kuusisaari Chairs: Please review and send comments, we are considering a WGLC for INFO RFC. 2.5 TCP-AO Interop Speaker: Greg Hankins Neil C: It seems over the past couple of months there are Linux contributions for TCP-AO. Michael S.: Did you look at the test vectors? It would be excellent to know if the vectors work. Michael T.: Do you know if the BSD implementation is to the base stack or some other? Greg H.: I will follow-up on these. 2.6 TCP EDO/EOS https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-tcp-edo-11 https://datatracker.ietf.org/doc/html/draft-touch-tcpm-tcp-syn-ext-opt-10 Speaker: Joe Touch (proxied by Chairs) TCP-EDO thought by editor to be ready for WGLC, and the second to be discussed. Wes: This seems stable and no known issues to us. Yoshifumi: I'm curious about middlebox interactions. As an individual, I would like to see the suitability of the SYN draft as a work item rather than individual. I will send comments. Martin D.: Are there any implementations? Wes: There was some work on EDO that provided feedback to the design, but no code ready to upstream. There is no driving need at this time to do this, but people have in the past asked for this. I think WGLC might detect if there are further inputs. Michael S. (as an individual): There was a strong need only a few years ago - we can't know the future, so documentation is useful. Martin D. (as an individual): Does EDO need to be standards track, wouldn't it need experimental experience? 3. Other Items 3.1 Updating RFC 5681 Speaker: Lars Eggert Should we do a revison, and should make this a full standard? Mirja K.: I think these changes need to be done first. Martin D.: I wonder about the ABC.bis? A full Internet Standard will be hard to modify. Praveen: The changes make sense to me. Not baking this in an Internet Standard makes sense. What are the other issues we want to do apart from the ssthresh change? Lars: I think we should start a short list. Gorry F.: I did try to catalogue what the RFC Series says about CC good practice in a TSVWG draft. There's quite a lot and it doesn't all sit well with current practice. I think we need to be careful about what we standardise, and think whether we can make claims across all transports/CCs. Bob B.: The changes on this slide are fine. Moving to Internet Standard isn't: RFC5681 Reno has low and reducing usage, while other CC's are taking over from it. So it would be odd to move such an algorithm to Internet Standard. Michael S.: 793.bis has a section with basic congestion control requirements. That changes the framing and may have some (editoral) impact on a 5681.bis. Chairs: Please take this discussion to the list. 3.2 Updating Appropriate Byte Counting (ABC) Speaker: Vidhi Goel Stretch ACKs>2 are common. Looking at removing the limit of 'L' in ABC and instead advocate pacing. Martin D.: I think we should update 5681 to do this. Mark Allman should be included in the loop and we should discuss what is safe on the list. Praveen: The Windows stack does not by default do pacing, and does do L=8. I think Linux does not pace TCP. This is a nuanced discussion about pacing. Vidhi: We have not reached consensus on this in the past. Without pacing, we could use a different 'L=10'. Ian S: RFC9002 says Senders MUST either use pacing or limit such bursts. Choice of '10' comes from the IW=10 EXP spec. It's a number that already exists. Praveen: '10' might be as good as '8'. Vidhi: The point we need to focus on is whether you can burst a cwnd in a single send? Yoshi: I think ABC doesn't specify the behavior during recovery phase. So, dup ack handling is only for reorder case? Vidhi: Right. it mentions about RTO cases, but doesn't specify the cases for fast retransmission. Chairs: Please continue this discussion on the list. 3.3 TCP Silent Close: For Cases Where Silence is Golden Speaker: Neal Cardwell Mirja K.: There seems a tradeoff here, I am not sure how the tradeoff is decided. Neil C.: This is mainly about middlebox memory, and the state can be recovered by garbage collection. Michael T.: If the app shuts down the read, should the TCP connection go away? Stuart C: I think the considerations need to be considered for NAPT and firewalls because TCP's state is recovered by the FIN/RST and that enables a longer timeout. Forcing more aggressive scavenging by middleboxes can motivate sending more keep-alive traffic, and that will have implications on the future mappings for UDP. If we make remove TCP FINs, we may see similar issues like in UDP bindings. Ingemar (via Jabber): Has this problem been identified by operators / vendors ? Chairs: Thanks for attending and keep discussing on the list!