TCPM meeting, IETF-109, online Tuesday, November 17, 05:00 - 07:00 UTC (120 mins) Note Taker: Gorry Fairhurst WG Status updates ------------------------------------------------- Current work items were reviewed. Lars: We started work on revising the cubic RFC 8312 to align with Linux, and would like to hear from other implementations. Please interact in the github repro. Working Group Items ------------------------------------------------- * Updates to draft-ietf-tcpm-yang-tcp-00 https://tools.ietf.org/html/draft-ietf-tcpm-yang-tcp-00 Speaker: Mahesh Jethanandani Looking at implementations in Linux. Milestone suggested as April 2021. * More Accurate ECN Feedback in TCP https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-13 Speaker: Bob Briscoe Michael Scharf: I agree to the current encoding proposal. But I think there are tradeoffs in using the different encodings and not all aspects have been presented. I'll follow-up on the list. Gorry: I will follow-up on-list regarding the new ACK Filtering text. I think this needs a little more work, which should be done quickly. * ECN++: Adding Explicit Congestion Notification https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-06 Speaker: Bob Briscoe No questions. * RFC 793bis https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-19 Speaker: Wesley Eddy Bob Briscoe: On RFC5681 ... why do you say the baseline CC needs to be in the spec (E.g. in a lightweight implementation)? Martin: Why do we say this? Wes: RFC1122 says use Reno. Martin: I will think. Jana: I would recommend we move away from specifying Reno just because it was in the original spec. Wes: I think we ought to say an IETF-specified CC. Martin: +1 Jana: I would push back. I don't yet see a set of good principles for what a CC needs. I would personally allow other CCs, even outside the RFC series. Other Items ------------------------------------------------- * TCP ACK Rate Request Speaker: Carles Gomez https://tools.ietf.org/html/draft-gomez-tcpm-ack-rate-request-01 Jonathan: I think that the use of N field and the reorder flag are orthogonal based on value of R field. Both could be overlaid on the same byte. Continue discussion on the list. * TCP ETS: Extensible Timestamps in Microseconds and Network RTT Measurements https://tools.ietf.org/html/draft-yang-tcpm-ets-00 Speaker: Kevin Yang Richard Scheffenegger: The SYN option could be much more space-efficient. It could be an extension to TS differentiated by the length field. Bob Briscoe: +1 Vidhi Goel: Good work, and delayed ACK should be done, what is the use case? Congestion control? Praveen: Delayed ACK is useful in DC, not sure this needs to be combined with TS. * Update on MPTCP RobE https://tools.ietf.org/html/draft-amend-tcpm-mptcp-robe Speaker: Jiao Kang and Markus Amend Chairs: Does the IPR allow implementation in an Open Source implementation? Please take to mailing list. Lars: If you open source the code that will be good. I think the question is whether others can implement the spec based on the spec without a licence? * Progress for Accurate Data Scheduling by Server in MPTCP https://tools.ietf.org/html/draft-kang-tcpm-accurate-data-scheduling-by-server-01 Speaker: Jiao Kang No questions. * Fault Management Enhancement in MPTCP https://tools.ietf.org/html/draft-kang-tcpm-fault-management-in-mptcp-session-00 Speaker: Jiao Kang Yoshifumi: Clients can know the failures in subflows from ICMP or reset or timeout. What's the use case for this proposal? Jiao: Sever sides can collect info from multiple connections, hence have better understanding of the network status than single client. Yoshifumi: It would be better to clarify it in next version of the draft. Jiao: We will. * RFC 6937bis https://tools.ietf.org/html/draft-mathis-tcpm-rfc6937bis-00 Speaker: Matt Mathis Richard Scheffenegger: I like this work and the plan to move to PRR to PS. FreeBSD is doing a form of PRR from a few weeks ago. Jonathon M: What about ECN? Matt: Linux CWR code use a form of PRR. We expect ECN discussion, but do not plan major changes when advancing this along the standards track. Praveen: Is there more about Policers? Matt: Policing is still prevalent, and being introduced in new places in the Southern Hemisphere. Jana: PRR is a form of soft pacing. I think that pacing is being used by default, and its value with pacing. I am also interested in how the two might interact? Matt: The way they implement the timestamps per packet might influence the answer. Yuchung: When you see ACKs, when there re stretch-ACKs the burst needs to be handled by pacing - which depends on cwnd (when there is no ACK clock). Jana: I agree, I think we need to explain the extra benefit that PRR brings. Chairs: I see interest, let's see if there is support for this on the list. * TCPLS Speaker: Olivier Bonaventure Paper to be published Jana: How does this work with terminating connections in a middlebox? Olivier: You can detect the presence of a proxy. Jana: I understand. If I try to negotiate with a TLS endpoint this is a different entity. Olivier: You could look at the TCP sequence numbers and use the TLS info to find the existence of the proxy. Yoshifumi: How do you wish to proceed in the IETF? O: We first try to understand cases where the two protocols bring benefit. We can offer a way to exchange reliable transport options using TLS, and get new opportunities. Meeting ended.