TCPM meeting, IETF-115, London Wednesday, November 9, 2022 13:00-14:30 UTC (90 mins) Notetaker: Richard Scheffenegger WG Status updates ------------------------------------------------- Time: 15 minutes 15/90 EDO: Gorry: Ok, if there is intent to implement, if there is no intent why not make this EXP. Martin D: Why PS, if noone wants to implement or deploy. Michael T: There are discussions in the RFC of what NOT to do, in addition to the way how it may be done. Martin D: Great, but that would be a INFO RFC. Lars: It asks for an option number - if standard actions is required (IANA codepoint) this may a reason to go with PS. Working Group Items ------------------------------------------------- * Status of AccECN https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-19 Speaker: Bob Briscoe Time: 15 mins 30/90 Ian S: What is the expected deployment ratio btw AccECN option and the header only ACE counter? Bob: Option is to help with middleboxes, wide area; datacenter you would probably only go with the ACE counter. Martin: Is the AccECN option tested across the internet? Bob: Interop testing was locally only. Michael: We did testing between test lab in germany and the the IETF network. Bob: Did a lot of testing and investigation on option viability a couple years ago - there are papers about this. Although this is not recent testing. Christian: What happens on a path change during the negotiation? Bob: Handshake checks for bit mangling and path conformance - but not continually. At the moment, bleaching is in the first few hops. Could happen. But AccECN is a lot better than 3168, as it checks at all. If ECN is mangled - there is loss and CC will react to that. Lars: In QUIC we found the last hop was mangling. Richard: Had validated AccECN bits and option in previous IETF L4S interop testing - with expected (non-AccECN handshake on bleaching) results. Gorry: Mangling tests have complicated the draft. There is text in there - please read the draft. Other Items ------------------------------------------------- * Future Status of RFC 3465 Speaker: Martin Duke Time: 10 mins 40/90 Ian: BBR may be standardized. The SS algo is not HyStart++. What do we do with that? Martin: First, BBR is far from standardized. SS/CA model may be outdated by the BBR mechanism. So you don't need to rely on this document. Michael: What if in the future, people are not using HyStart++. Would like to have a future proof document. Martin: Is the consensus, that this is not the best practise. If you redefine slow start, you don't necessarily a doc downrev issue. Michael: That can specify whatever they want? Martin: Correct. Lars: Option: open up 5681 and have a bigger discussion around these topics. Martin: This scales the work up to 11. Unless someone takes up this task, this would be much larger task. Christian: I am with Lars and Michael with this discussion. It may be a mistake to specify the implementation. The intent of slow start is to avoid big overflows. Clear that HyStart does that. Other ways exist too. Much better to state principles rather than specific solutions. Martin: Are you volunteering? Christina: Aahhe.. no. Martin: Don't have the bandwidth to do this. Gorry: I may prefer option 1. Algo is an algo - we know we need to do something, but not yet what exactly. Michael Welzl: Maybe point 3, but with a SHOULD. Text in there to explain this. Michael T: It focuses on L=8. Martin: Yes, gives advice to use 8 if you don't know what else to pick. Martin: Action Item: No enthusiastic support, probably do nothing at this time. Ian: Poll: 9/12 to have a PS document in this space - fewer people in this room participated. Lars: No sense of urgency - motivates the passiveness. Christian: Should this be in CONGRESS? Martin: Ah, yes may be a good idea. * TCP ACK Rate Request https://datatracker.ietf.org/doc/html/draft-gomez-tcpm-ack-rate-request-06 Speaker: Carles Gomez Time: 10 mins 50/90 WG adoption poll: 21 persons raised hand, out of 24. Michio: Why is this is really needed. PSH is triggering an ACK in the datacenter use case. Michael: PUSH is not specific on the receiver side. For example, FreeBSD does not trigger an ACK on PSH. Gorry: Concerned. ACK mangling, QUIC we understand that. With TCP not so sure. Is there understanding what the network does 3449 with this option. Mirja: Christian: On TARR: if we do something for controlling ack rate in TCP, should we try to keep common concepts with the delayed ack option in QUIC? This would help building common experience, etc. Jonathan: This is not what the semantics of the PUSH flag are defined for. [misusing to trigger ACK] * TCP Service Affinity Option https://datatracker.ietf.org/doc/html/draft-wang-tcpm-tcp-service-affinity-option-00 Speaker: Wei Wang/Aijun Wang Time: 10 mins 60/90 Lars: I feel this is the wrong level to solve this problem. Always have to deal with legacy clients. Also, the network can change these signalling - a long number of things why this may be better to solve this in higher layers. Wei Wang: Problems in real-time processing of higher layers in the load balancer. Aijun Wang: Our solution is a hybrid solution between network, client and server. Bob: I tend to agree with Lars. First hash this info, cookie in the option. SYN-Cookie with more information in the SYN Cookie - allows you to get soft-state. There are things you can do so that clients would do this. Ian: I also agree with Lars. Serious policy concerns about how this is structured. SYN-Cookies would be preferred. Draft would need to be seriously changed to conform with IETF process. * Analysis for the Differences Between Standard Congestion Control Schemes https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-standard-cc-analysis-00 Speaker: Yoshifumi Nishida Time: 15 mins 75/90 Martin: 9002 is the best current practise, which we probably agree upon now. Lars: Thanks for doing the work about the differences. We deliberated over all of these chances - I would argue that 9002 more accurately reflects the current thinking. Thanks for this starting point for further discussion. Martin: 568