------------------------------------------------- TCPM interim meeting Wednesday, April 29, 2020, 14:00 - 16:30 UTC WG Status Updates Working Group Items ------------------------------------------------- Notetaker: Richard Scheffenegger, NetApp * Requirements for Time-Based Loss Detection (14:15) https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-10 Speaker: Mark Allman Mark Allman: Minor problem when going from retransmission to loss detection language. Spin one more revision with that fixed. Michael Tüxen: WGLC will then be concluded for this draft. * RFC 793bis (14:25) https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-16 Speaker: Michael Scharf (document shephard) [ Wesley Eddy ] Mirja: We discussed change the reg policy for the header bit last meeting. Not that urgent any more. Should that be integrated into this doc? Michael Scharf: It makes sense to clean up the registry, some reserved bits don't even have an entry. Also move everything to one page. Alloc policy will not be in 793bis. This will only be about editorial changes to the IANA registry. For change in the policy, a separate document should be written. Mirja: The groups should decide, we have a -bis document, and we could change anything. Michael Scharf: This would be a change in the agreed scope of the document, I would prefer not to go down this road with this document. Consensus on list is to clean up the registry, but the allocation policy should be kept out of -bis for the moment. * RFC 2140bis (14:30) https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-02 Speaker: Michael Welzl Michael Tüxen (Chair): You are done with the document? Michael Welzl: Yes Chair: Ready for WGLC? Michael Welzl: Yes Michael Scharf: One more review should be done and we already have a volunteer. I will ping the person again who had agreed to review this. * Accurate ECN TCP Feedback: Changes & Status (14:35) https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-11 Speaker: Bob Briscoe Mangling Detection: Mirja - server doesn't know if there's been mangling if 3rd ACK of 3WHS is lost ... unless the session uses the AccECN option. Mirja: ACE Wrap behaviour - counter may stay the same in received ACKs. Need to be conservative about having had one CE, but not how many. Bob: New text talks more about the one counter wrap - not the first one. Mirja: Regarding the Update section: I don't think we update the old 3168, right? Bob: We replace those sections, 3168 is no longer relevant in those case. Michael Scharf (as individual): Slide 10 - more than what is on the slide was suggested as to how to address this problem. For instance, we could also use different length values for the different encodings. Two option codepoints are probably the easiest solution. Bob: Mirja originally don't like that option (different length options). The document already uses the length field to allow longer/shorter options. It was suggested to also use the length field to determine the order of the fields. Martin Duke (as individual): Why do we need to hold for ECT(1) decision? Michael Tüxen: Want to be on the safe side. We hope things get cleaned up soon - we need to reconsider if this doesn't happen soon. Martin Duke: Push to quick resolution in TSVWG. Bob Briscoe: I would like this draft not to be stuck if this doesn't get resolved. Mirja: I think there is no dependency from accecn -> l4s but only the other way around. We only need a flexible way to signal the ordering of counters in the option. Michael Tüxen: We don't want to hold this for too long. Gorry (TSVWG Chair): As soon as this is stable, check the RFC3168 updates using the TSVWG list... I don't think the dependency is large enough to hold this document. * Accurate ECN Linux Implementation: Experiences and Challenges (14:50) https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-11 Speaker: Ilpo Järvinen Bob Briscoe: On ACKs: It's still a SHOULD. If you would be doing the SHOULD properly (option on most ack) this problem (slide 8) would not exist. This issue only exists if you try to be (overly) sparse with the AccECN Options. Yoshi: Do we really need 24 bit counters? If we used only 22 bits, we would have enough space and there would be no need for a new byte. Bob: ACE is only 3 bits, and AccECN is designed to be working with just that. The options are there to provide fine granularity as an optional - decreasing the fidelity seems counterintuitive. Mirja: Q about the option: I don't fully understand the problem - as ACE the field should also be increasing. I don't think we need a separate field to distinguish which counter has increased. Ilpo: Cross checking on field is possible, but it may create loop of checks. Mirja: ECT0 and ECT1 distinction was not the core requirement - only CE information has to be accurate. If you can get the ordering information as a side effect, thats nice, but it was not a requirement * TCP RACK (15:15) https://tools.ietf.org/html/draft-ietf-tcpm-rack-08 Speaker: Yuchung Cheng Michael Tüxen: Looking forward for the updated document, thanks to all the hard work of the authors and reviewers. It improves the document! Non Working Group Items ------------------------------------------------- * YANG Model for Transmission Control Protocol (TCP) Configuration (15:30) https://tools.ietf.org/html/draft-scharf-tcpm-yang-tcp-04 Speaker: Mahesh Jethanandani Michael Tüxen: Mixed feedback (positive, and also not to adopt). Any opinions from people in attendance? Michael Tüxen: Chairs have not decided yet Martin Duke: Can someone articulate which TCP implementations may be using NETCONF to configure themselves. Michael Scharf (as author): Two use cases - one in the NETCONF WG, there is commercial interest in configuring TCP keep-alives (but that is currently outside of this specific YANG model). The second use case is BGP. Given these two use cases, sooner or later other uses may surface. More likely this will be used by devices / routers which already use NETCONF. It is unlikely that host operating systems will use a YANG model any time soon. Mirja: Needs works and commitment from people for this make it work. Needs to be correct. I think the plate is already quite full, we should complete other work first. Michael Scharf (as author): There were questions on the list whether this work is doable. The options are either to focus narrowly (as presented, needed in other WGs) or to extend the model for TCP configuration in stacks. Contributors in the room asked for the latter in earlier meetings, but that results in a number of extensions (e.g. ECN, TS, SACK turning on/off). The narrow focus seems to be the lower hanging fruit, a sophisticated configuration model could be followed up later. Martin (as individual): I would encourage WG to focus on known use cases. TCP config space is massive. I don't want to spend much time on something which has limited value. * HyStart++: Modified Slow Start for TCP (15:45) https://tools.ietf.org/html/draft-balasubramanian-tcpm-hystartplusplus-03 Speaker: Praveen Balasubramanian Mirja: The performance improvement was by avoiding RTOs Praveen: Spent less time recovering losses - avoid all kinds of problems by not overshooting the queue. Overshooting is a more severe problem. In none of the test the flow completion time was worse. Martin: State of the document: Experimental or Informational? Praveen: Open to changing the type of document. We would like others to use this, too. Richard: Would like to have this adopted as WG item eventually to address buffer overshoot. Yoshi: Informational can document the Microsoft implementation, EXP or PS would imply WG consensus on the content. Duke: If other people are interest in implementing this we would like to change the status. (+1 in the WebEx chat from Mirja and Rod) Michael Tüxen: Positive feedback from the floor. The chairs will discuss and will provide feedback to the mailing list. Side chat discussion on increasing ABC to PS: Praveen: Shocked that ABC is not in PS state. Mirja: We could move ABC to PS Michael Welzl: +1 Michael Tüxen (as individual): Anyone willing to spend cycles on that work? Mirja: We should probably read the document before we simply change the status. If that the right thing to do, it should be possible to change only the status without doing a -bis document Martin: ABC has no errata so there isn't really any need for a bis. Michael Welzl: There was a bit of recent list discussion not too long ago, regarding some part of it not being implemented in Linux. This was related to burst limitation. Mark (as the author of ABC) was also involved, and he said that some part of it (the L limiting burstyness) may not be a good way to do it in modern networks. So this probably does need an update, incorporating Linux implementation experience. * Advancing ACK Handling for Wireless Transports (15:55) https://tools.ietf.org/html/draft-li-tcpm-advancing-ack-for-wireless-00 Speaker: Rahul Jadhav Bob: Don't trade off speed for latency. Need to do ACK thinning properly at L4, so it's not done without knowledge of context in the network. Richard: Missing AckCC as list of previous work. You seem to be looking only at Web-like traffic with uni-directional transfers. I would be interested in situations in which sender and receiver roles change frequently. Praveen: Packet batching, LRO - there is already ACK stretching in practise because of these functionality. I would be very surprised if you see an ACK really every other wire packet. Rahul: It is a possibility to reduce the ACK rate even further. The transport layer is not in control of this reduction (Wifi batching) - this lack of control has a detrimental effect on overall performance. Gorry: I like this work, QUIC seems to be better than TCP. Maybe bringing a lot of different people together on this one, as there is a lot of use. * Sender Control of Delayed Acknowledgments in TCP: Problem Statement, (16:15) Requirements and Analysis of Potential Solutions https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-01 Speaker: Carles Gomez Michael Tüxen: Target status? Carles: INFO Gorry: RFC 7053 SCTP version of AckPull? Carles: Not yet looked at that one in particular. Gorry: When it was put up I was against it. I don't think these are real issues. I think this is dangerous to pursue. We should discuss this on the list before asking for WG adoption. Bob: It was me to suggest to move it into a requirements doc first. I hope people like the approach of pulling together all ideas. Agree that discussion is needed before adoption is asked. (+1 from Rod) Yuchung: A lot could be done from the ACKs. Two drafts, they are opposite of each other. Richard: We have had the experience that delayed ACKs are a major latency issue. We need to have a discussion about what to do about this. Michael Tuexen: Would be great if you can bring that to the list. Richard: Can do, let's continue the discussion on the WG list on this particular topic. Martin: I think we should adopt this draft only if we decide this is a problem we want to solve. In particular, I'd like to understand Gorry's objections, which I understand to be global.