TCPM meeting, IETF-111, online ============================== Tuesday, July 27, 2021, 23:00 - 01:00 WG Chairs: Yoshifumi Nishida; Michael Scharf; Michael Tüxen WG Note Taker: Gorry Fairhurst WG Status updates ================= * RFC2140.bis is in RFC Ed Queue. * RFC793.bis in IETF LC. Working Group Items =================== Adding jitter resiliency to HyStart++ ------------------------------------- https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-hystartplusplus-02 Speaker: Praveen Balasubramanian Should the document be EXP or Standards Track? Yoshifumi: There are parameters in the algorithm, will you fix the values? Praveen: We will examine tradeoffs and make recommendations. Yoshifumi: Do you have a way to dynamically find good parameters? Praveen: No, not really. This is more a research question. Bob Briscoe: I wanted to clarify that the RTT threshold rationale needs to be explained in the draft. Richard: I hear discussion of constants. I would suggest EXP status, unless there are recommended values that are clear. Martin Duke: EXP can be problematic. If we can find confidence we should make it PS. Christian: We should go for PS. +2 from jabber. Michael Scharf: Aim for PS now. The WG can make the final decision durin WGLC. Michael T.: Do you do any form of pacing? Praveen: Not at the moment, it could be added to an implementation. TCP YANG model - update ----------------------- https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-yang-tcp-02 Speaker: Michael Scharf Mahesh: We seem to have resolved the issues and have an implementation, what is needed to complete WGLC? Michael S.: There are no open issues in the ID. There is an open issue about implementation and the availability of open source code for TCP-AO. Mahesh: Is the lack of an open source implementation an issue? Michael T./Yoshifumi: This document does not need to be blocked on this. Mahesh: This also depends on the netconf module, which is pending publication in netconf. We could coordinate with the netconf documents (we don't expect these to change) Michael T.: The chairs will discuss the WGLC timing. Martin Duke (on chat): If we don't think additional facts will emerge, I say we just ship it. It is not hard to understand this document without the NETCONF one. More Accurate ECN Feedback in TCP --------------------------------- https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-15 Speaker: Bob Briscoe Praveen: I am not convinced that pure ACKs should be ECN capable. Bob: This draft does not require you to send pure ACKs, but explains what you need to do if you wish to monitor congestion on the ACK stream. Praveen: What happens if a receiver doesn't send an ACK? Bob: Nothing special, ACKs can be lost. Yuchung: What happens if you have super segments e.g. from GRO. Bob: If you have 16 packets represented, then offload would normally send a burst of ACKs corresponding to all the segments. (There are also counters, especially if you send the option you can ignore wraps.) Yuchung: Linux does not send extra ACKs, to make more CE ACKs. Yuchung: Are you going to publish the scenarios for testing the minimal option (fewest number of ACKs)? Bob: We will publish a tech report. Yuchung: Can we use the version without ACK options. We do use GRO with large segments (>>16). Bob: I think the option is needed at high rates. The use without the option is intended as a stop gap. Michael S.: There was originally pushback from implementors against the option in order to keep things simple. Question to the group: Has the view on using the option changed? Bob: The recommendation is now stronger - because of more observed ACK Filtering. Richard S.: For constrained environments it is possible to get sufficiently accurate feedback without the option. Yuchung: As NICs get faster, GRO is important. We need to check this. Praveen: I worry about middlebox behaviours when using the options on Internet paths. Bob: The draft has a lot on how to handle middleboxes. We'd like to test more at larger scale. RFC 8312 bis: CUBIC for Fast and Long-Distance Networks ---------------------------------------------------------- https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc8312bis-02 Speaker: Vidhi Goel Praveen: Do you expect to see performance differences with respect to the previous RFC? Vidhi: For linux no. It already implements this. There would be benefits relative to the current RFC. Praveen: Could you mention the places where there is improvement - in an email? Yuchung: Linux does not do ABC. An ACK for 100 packets, then cwnd will grow by the size that is ACK'ed. Stretch-ACKs are common. Should we change ABC? Vidhi: If you enable ABC, you adjust by bytes acknowledged. This was originally based on 2 segments/ACK - the main thing is counting the bytes, even if L does not equal 2. The ABC spec is maybe not aligned to practice. Richard S.: ABC was mainly used to guard against ACK-Splitting attacks. Martin: If the WG thinks the L=2 guidance is obsolete, then we could mention this here. Yuchung: Maybe we should update the RFC with respect to the stretch ACKs. Martin: Should we update the ABC spec? Vidhi: There are also cases where we need to add pacing cases. This could be a good place to describe this. Praveen: I think updating ABC would be a better way to make this change, because many things refer to ABC. Martin: Maybe someone should make a first move for an ABC.bis? Yoshifumi: This draft does not have to wait for an ABC.bis to be published. Martin: The reference to ABC is informative in this draft. You could refer normatively to RFC5681 if you need a normative reference to byte counting. Lars: ABC is referenced informatively by many specs; I don't see a need for a normative reference here. End of meeting.