TCPM meeting, IETF-118, Prague Monday, November 6, 2023 15:30-17:00 3 Chairs Notetaker: Gorry Fairhurst 1. WG Status updates including rechartering Document status was reviewed by the Chairs. Accurate ECN is being advanced to the AD - there are additional comments to be provided by M Kojo and their may be last comments that might need to be taken into account before the document is progressed. The chairs will work with the AD. Generalized ECN is near WGLC. The new proposed charter was discussed. The group discussed where CC work would land, and this would normally be in CCWG. Other topics could still need liaison between groups. 1. Working Group Items * Status of Generalized ECN / ECN++ https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-14 Speaker: Bob Briscoe Michael Tuexen: There is intention to restart the work on SCTP with ECN. The draft has been revived, but the content has not yet been updated. Bob: Then ought I to not comment this old ID? Michael: Yes. Gorry: As TSVWG Chair: I think you can still refer to the SCTP base spec as not defining ECN and say there is work-in-progress on ECN for SCTP. Martin Duke: Is Marku's comment about just this? Chairs: It is about ACKs of ACKs. He has promised new text. Martin: I will wait 24 hours. Reviewers: Gorry (must review as WG responsible for ECN); Mirja will review; Bob will look for others. * Status of ACK Rate Request https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-ack-rate-request-03 Speaker: Carles Gomez Gorry: Why 1-4 RTTs in the draft? Ian: I think the proposal was to change this 1-4 ACKs per RTT. Gorry: Aha, that was not what I read, that does seem to reflect what was talked about in QUIC, so this is likely an editorial issue, we can follow-up on the list. Gorry: You say in some places for not do things because of an RWIN limit. But, can't the RWIN change at any time, so is this really a thing that can be used to decide when to update the ACK policy? Carles: I'd like to discuss on the list. Gorry: Sure, that would be good. Bob: There are various conditions that trigger an ACK. This is called out in Specs. Carles: The intention was not to change these specs. * EDO on Linux https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-tcp-edo-13 Speaker: Kuniyuki Iwashima (remote) Ian: Is the intent that this is a temp problem needing GSO to be disabled? Kuniyuki: The intention is to support GSO and GRO in future. Michael Tuexen: Is the baseline without LRO, etc. Kuniyuki: Yes. Martin: Thanks for presenting this. I have been curious about this for 2 decades. What is the most important use case - do you have one in mind? Kuniyuki: I think there are cases that need more than 40 bytes of options. Martin: Did you observe any odd middlebox behaviour on the network? Kuniyuki: Not used on the Internet yet. Yoshifumi: This could be useful when using a combinations of options, e.f. MPTCP and AO or using many SACK blocks. Martin: I see, and maybe this could live with fewer SACK blocks. Wolfgang: How is the EDI portion counted - is the extended option counted as window size? Kuniyuki: No. Matt: I am aware of NATs that rewrite payloads (e.g., the FTP control channel) that can result in segmented packets. Someone can check if these are common? Ian: There could be security considerations for long lists of options, I think this ought to be in the draft. Yoshifumi (as Chair): Now, we have an implementations of EDO. Do we have any blockers of this draft? Michael Tuexen: Please send comments to the editors using the mailing list, so they can respond and learn from what we have seen presented today. 1. Other Items * RFC 5681bis (TCP CC) / RFC 3465bis (ABC) Speaker: Martin Duke Martin: Lars is expecting to open an edit on this, if people are willing to help. Please volunteer to help. I plan to keep talking about this. * Opportunistic TCP-AO with TLS https://datatracker.ietf.org/doc/html/draft-piraux-tcp-ao-tls-00 Speaker: Maxime Piraux Yoshifumi: What will happen if there is a partial failure? When the server does not support TCP-AO? Maxime: The server should not enable AO, it could be solved if the draft is updated to consider this. Michael: What is the interaction with TLS key updates? Maxime: The key updates do not update the master secret, and we don't think we should synch the TLS key updates. At the moment there is no impact, but at some time you need to update the AO keys. We need to think more. Michael: We have similar concerns with SCTP key updates over long sessions. * TCP FWA: Fast Window Advance for TCP https://datatracker.ietf.org/doc/html/draft-thejeswara-tcpm-tcp-fwa-01 Speaker: Thejeswara Reddy (remote) This concerns messages (e.g., SIP over TCP), which can result in old data being held when the cwnd reduces. Altanai: In some connections a SIP might wnat to ressue SIP requests, how will this work? Thejeswara: This is controlled by the application. Igor L: For bulk transmission, you can have filled the entire receive buffer, so you need to wait at least one RTT to clear this buffer. How does this look for a regular receiver? what is the user interface? Thejeswara: Yes, requires one RTT. Thejeswara: The interface looks the same. Igor: The TCP receiver recieves a byte stream, how does it know about the gap? Thejeswara: The receiver does not see the sequence number. Igor: I am unsure this is usable. Bob: Do we need to use a TCP flag for this? Can we overide other flags such as URG or PSH in combination to make more codepoints. Chairs: Let's first see how useful this is. Please continue to discuss on the list. * * *