TCPM meeting, IETF-102, Montreal Tuesday, July 17, 9:30 - 12:00 WG Chairs: Michael Tüxen, Yoshifumi Nishida, Michael Scharf (not attending) Notes: Gorry Fairhurst ============================================================================================================ 1. WG Status updates draft-ietf-tcpm-alternativebackoff passed to IESG. Other drafts progressing in the WG. Jana I: What is the status of RTO reconsider work item? Chairs (Yoshifumi Nishida): This draft expired as we explained in the previous meeting. We were looking for an editor who is intersted in this. Jana: I spoke to Mark and he seemed willing to make a new revision. I am happy to help push this draft forward. Yoshi: Would you be an editor? Jana: If necessary, but just check with Mark at first. Michael T: The final contents of the document needs to reflect WG consensus. Mirja K: There was some agreement off list between the authors and others, which can be a starting point. ============================================================================================================ 2. Working Group Items ------------------------------------------------------------------------------------------------------------- 2.1 RFC793.bis - (presented by chairs on behalf of the authors) - Please review this draft on the list. ------------------------------------------------------------------------------------------------------------- 2.2 RACK Updates - Yuchung Cheng Yuchung: Reordering detection section added. Bob Briscoe: I wonder if the initial reordering window could be a Max of 3 DupACKs and a RTT, to allow this to be used in the future? Yuchung C: What happens when timer constraints are no longer an issue? (e.g., as hardware improves). Bob: Could this use e.g. RTT/16 as a threshold? Christopher P: You could have a bigger reordering window than the RTT itself in some cases (links). Yuchung: If you used a smoothed average, then this should still work to a certain extent. Christoph P: Is that because the SRTT also then increases? Yuchung: Yes, we wanted to keep this loose to allow implementation flexibility. Ian Swett: I got some new data suggesting MinRTT/8 may be a good starting point (see talk in MAPRG at IETF-102). Yuchung: We did not previously see a difference when we looked at /4 or /8, but happy to learn more from others. Michael Tuexen (from floor): I suggest you could replace "4" by a named variable, so it could be changed if needed. Jana: Is this ready for WGLC? Chairs: This draft has a good shape. However, we would like to wait a little more for implementor comments, and provide feedback if they have any. ------------------------------------------------------------------------------------------------------------- 2.3 Accurate ECN updates - Bob Briscoe - Describes an appendix (B) to document the rationale for the use of the TCP header field bits. Jana: Given we have code in the Internet that is years old, what chance do we have that those bits will ever be returned? Mirja K: If you wish to use those bits you need a different safety measure to start using these. This is not what is planned here. - DCTCP experiences runs of CE-marks for a time, and then runs of ECT(). The marking pattern is different. Yuchung C: From my point of view implementation complexity needs to have a benefit. I do not know how critical it is to handle ACK loss. DCTP is widely implemented and GRO is usable within a DC and needed for high rates. If ACE can be experimented with, I would like to do understand this. Bob: I can't do real experiments, so we need to use a testbed, that constrains the testing. Yoshi: Are you suggesting two drafts? Yuchung C: I prefer two parallel drafts as a starting point, simple is good. Middlebox traversal is really hard. Gorry F: I am concerned about us introducing two approaches (both of which will inevitably be used in the wider Internet) - and then we are planning to use this to build protocol machines on top. I think the WG as a whole needs to understand the proposals and we should try to find one method. Neil C: Should we wait for a CC that actually uses this? Mirja K: I think the best use-case is ECN++, which is a motivation for allowing fro supporting ACcECN first. Without this we can make little progress with a CC. Manesi ... : In the deployment issue: Do you see AccEcn as more robust or not? Bob: If there is loss, then AccECN will be more robust. You don't know of ACK loss, and this is hidden with DCTP approach. It does have a GRO issue. Manesi ... : Does GRO have performance impacts? Yuchung: For fast networks, GRO is critical for fast networks. For 10 Mbps paths, probably not. Manesi ... : Are there tunnel concerns? Bob: Not specifically, TSVWG has work to address this. Neil: There is software GRO that can presumably be aware of accurate ECN. Gorry F: The idea of understanding the GRO implications seems really useful, Neil do you have any feeling about hard it is to look at how hard this may be to do? Neil: My intuition is that software GRO could perhaps be done efficiently, but I am not an expert, we should get feedback from those who understand this from the Linux stack. Mirja: I would say you should provide a recommendation about passive measurement of ECN with a note that you have to see the SYN. This could change in future. Bob: Yes, you have to read the draft to read the header. Gorry: The issue with passive measuring isn't that this is bad - I think operators in the network may learn useful things by seeing the protocol machinery of ECN is actually working. An important issue is when a CE-mark is reported, this does not indicate a network problem, we need to be careful to say that passive measurement of reported ECN marking does not indicate any sort of performance issue - CE-marking is absolutely normal network behaviour. Michael Scharf (remote): I am not suggesting to change the wire protocol. Mirja K: << >>. Bob B: We will work to resolve the issues in a new rev. ============================================================================================================ 3. Other Items ------------------------------------------------------------------------------------------------------------- 3.1 Disabling PAWS When Other Protections Are Available - Yoshifumi Nishida Bob: In the three cases (MTPTCP, TLS, etc) don't you know by negotiating these that you do not need to use a TS. Randall Stewart: You negotiate these simultaneously. So you do not know which you use. Bob: You said there were cases of an attack with 50% chance, is it worth for protecting after the event? Yoshi: Hmm.. guess no. Randall: There are other methods to protect from off-path attacks. I don't like this. I would rather see other things happening. I can look at the timestamps in ACKs to understand better how the feedback reflects capacity and that helps with my work on BBR. You need this on data and ACKs. Yoshi: Do you need this on all packets? I guess you only need to set TS when you retransmit packets Randall: It might work. Combining the TS and Sequence number provides more info. It doesn't have to be TS, but this already is really useful to the stack. Richard Scheffenegger: Yes, agree with Randall - I think something along those lines is in my expired draft... We discussed about this at the time. Michael T (from floor): The protection offered by TLS actually detects problems, but also causes a decryption failure. TLS is not being robust, and would as designed tear down the connection. Stuart Cheshire: To make TLS work with this, you would need to change TLS to report-back the problem to let TCP deal with this rather than TLS breaking the connection. Yuchung: Cross-layer optimization is always tricky. Also, if you just put TS in retransmitted packets, there are also implications that may need a repacketization when you have/have not TS. This can impact implementation. Yoshi: Sounds like an implementation problem to me. Yuchung: In IETF, implementation problem is a problem Neil: Timestamps are useful. There also TCP receivers that use TS for a RTT estimate to perform receive buffer auto-tuning. I do see potential value in negotiating disabling PAWS, or to negotiate a TS format (e.g., microsec timestamps) - an example is using PAWS when there are microsec TS requires the PAWS mechanisms to be changed. I support a proposal for alternate proposals for TS. Although, I also think the current TS overhead in the header is justified. Brain: I think TS could be terrible! They radiate a lot of information about the stack. But, what I wanted to say was that I have an old draft that tried to address a different problem, but this was not progressed. I think the TS negotiation idea by endpoints is useful. ------------------------------------------------------------------------------------------------------------- 3.2 Making TCP faster and cheaper for applications - Soheil Hassas (remote) / Yuchung Cheng (local) - TCP Transmit ZeroCopy in Linux, and other features of the stack. Jana: I would like to understand workloads and the value of TSO. Soheil: Most things I spoke about are 100 Gbps NICs on emerging platforms. ZeroCopy saves cycles, for 100 Gbps NICs you need TSO to saturate the NIC. Jana: How much applies to Internet workloads. Soheil: It limits 100 connections on a single. Neil: Most of these seem likely to benefit Internet-facing applications. TSO helps (but to a lesser extent - because the flows are 10s-100s Mbps), but the TSO bursts are constructed as 1 ms worth of data, (e.g. 4 packets at 100 Mbps) so this definitely adds value. ------------------------------------------------------------------------------------------------------------- 3.3 TCP Usage Guidance in the Internet of Things (IoT) - Carles Gomez Carles: Document has been presented in LWIG and TCPM. The next version is expected to be submitted in Sept 2018 and ask for WGLC. Chairs: Please provide feedback. The meeting closed at 12:00 noon.