TCPM meeting, IETF-113, hybrid Monday, March 27, 2023 15:30-17:00 JST (90 mins) Notetaker: Momoka Yamamoto, Eric Gorbaty ## WG Status updates {#wg-status-updates} Time: 15 minutes ## Working Group Items {#working-group-items} ### AccECN and ECN++ updates {#accecn-and-ecn-updates} https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/ https://datatracker.ietf.org/doc/draft-ietf-tcpm-generalized-ecn/ Speaker: Bob Briscoe Time: 20 mins On Markku review: Brian Trammell: It's probably sufficient to say "additional combinations of these bit fields may be allocated by IANA subject to Standards Action" Mirja Kühlewind: I don’t think we need to create a registry. So I would say no need to mention IANA Richard Scheffenegger: We've had the discussion around ACK-on-ACK (which really may only happen with ACK++ as mentioned). I don't buy the idea of it causing data segment retransmissions. Richard Scheffenegger: Since any new data packet will get an ACK (with the most recent ACE counter), breaking any "chain" of "continuous retransmissions"... (Received indications of a vendor interested in getting AccECN deployed in production "soon", based off the FreeBSD stack... Maybe in conjunction with iOS/MacOS support). Brian Trammell: Mirja/Bob: if the TCP flags aren't already somehow in an IANA registry, then agree -- no need to involve IANA. haven't checked though. if the flags are already mentioned in an IANA registry then there's probably a (admittedly, potentially pedantic) need to inform them via this draft. I don't think there is though (checking via RFC 7125) so yeah, agree with Mirja, no need to invoke IANA on ACE. Questions: Michael Tüxen: Clarification. Is it part of kernel? Bob: It's not in upstream yet. That's in progress. Ilpo is helping. Markku Kojo: But but the problem is that if this feature causes for fast retransmit, it's problem. And then it would say, should not use without by timestamps or SACK enabled. It would say must not use. Because there it also interface or confuse this auth recovery. Confuses limited transmit confuses, PRR, it causes extra packets for making this more aggressive than it is supposed to be. And it breaks FRTO and Eifel. It requires quite a complicated scenario, but still there is area or maybe more than once scenarios where it breaks it. Richard: We've discussed it about 6 month ago already. If you have some specific scenarios that cause issues, please let us know. Markku: I will. Mirja Kühlewind: Do you agree this is the problem for ECN++ as we don't see this issue without ECN++. Markku: But, this draft specifies the logic. Bob: I indicated agree with you Mirja, but what the AccECN draft says about ack on ack cannot be applied unless you're also putting the ECN capability on pure ACKs. You wouldn't be acknowledging them unless they had ECN capability, which is why I'm suggesting we move it in ECN++. The AccECN describes simple requirements and refer ECN++ for the detailed logics. Yoshifumi: ECN++ is experimental. I think you should make that clear in this draft. That's might be useful. ### TCP ACK Rate Request {#tcp-ack-rate-request} https://datatracker.ietf.org/doc/draft-ietf-tcpm-ack-rate-request/ Speaker: Carles Gomez Time: 15 mins Gorry: Do you have data that 1 ack per RTT doesn't has positive performance? Carles Gomez(presenter): We will try to get some data. Mirja Kühlewind: There is a similar discussion in QUIC about this. have concerns about bursting/pacing without using normative language. Carles Gomez(presenter): OK. Will add some normative language there. Yoshifumi (as individual): So let's say we set 5 or 6 to R, a bit big value. If timeout out happened here, then congestion window becomes one. In this case, if the receiver still thinks R is 5 or 6, then the performance will be degraded. What do you think about this case? Carles Gomez(presenter): That's a good point. A safety mechanism is needed. Richard Scheffenegger: A more generic description would be useful as the TARR option is under the sender's control. Rather than describe each specific instance (e.g. slow start, RTO, ...) provide guidance that the sender should be choosing a TARR value appropriate on what the sender requires at that moment. Bob Briscoe: if we specify specific ABC behavior, it might not be an experimental doc anymore. ## Other Items {#other-items} ### Service Affinity Solution for TCP based Application in Anycast Situation {#service-affinity-solution-for-tcp-based-application-in-anycast-situation} https://datatracker.ietf.org/doc/draft-wang-tcpm-tcp-service-affinity-option/ Speaker: Wei Wang/Aijun Wang Time: 15 mins Yoshifumi (as individual): This seems to be a broad concept such as TCP connection migration and service affinity is one use case for it. I might prefer a different option name because of it. Also, there are possible security concerns associated with the connection migration based on what has been suggested, primarily via having the ability to steal connections. Wei Wang: We hope to improve in security areas. Hope to get more feedback. Aijun Wang: Gave further clarification on security concerns, has some ideas on how the current approach meets some security requirements. Mirja Kühlewind: I see your need. But the security problem is very big, not sure we can solve it with a TCP option. Wei Wang: The security concerns have been noted. Ian Swett (as individual): A question is this proposal is at the right layer as this seems very difficult to deploy. Lars Eggert: Expressed some doubts about the interest in adoption here, interested in understanding what questions need to be asked in order for this to change, since the trajectory has been that the sufficient interest or implementations are not evident. Yoshifumi: What do you want to see in the future version of the draft? Lars: ideally, I would like to see interests from implementors and people want to deploy it. Mirja Kühlewind: Further clarified concerns about security, indicating that this adds extra vulnerability on top of TCP which is already vulnerable, doesn't think that a solution is to be found as a TCP option, and standardization will be impossible that way. I recommend you to think about a completely different solution to solve this issue. ### Aggregated Option for SYN Option Space Extension {#aggregated-option-for-syn-option-space-extension} https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg-syn-ext/ Speaker: Yoshifumi Nishida Time: 15 mins Lars: (clarification). We have UTO as an example for not using SYNs. Lars: Do we have an option that is cached between connection instances? Ian: TFO? Lars: True. That might be only use case. Yoshifumi: How about MSS? Lars: I'm concerning the case where caching info was for different nodes. Andrew McGregor: It't not a problem for large operators that use load balancers. Richard Scheffenegger: I would like to see some benefits for applying this to MSS and window scale options. Martin Duke: Very intrigued. Doesn't have a lot of the difficult consequences of some of the other option space solutions that that people come up with. So this is great. Lars: There might be a solution that was not possible before as the world is changing.