TCPM meeting, IETF-94, Yokohama, Japan Thursday, November 5, 9:00 - 11:30 ==================================== Chairs: Yoshifumi Nishida Pasi Sarolahti Michael Scharf (not on-site) Note takers: Christoph Paasch David Hayes (minutes revised 2015-11-26 based on corrections and comments) Chair Slides ----- Transmission Control Protocol Specification draft-ietf-tcpm-rfc793bis Speaker: Chairs for authors ----- - Background - Changes since last meeting - New Questions for Working Group Karen Nielson: Keep the API in the new draft? Pasi Sarolahti: Defer to mailing-list. API got discussed earlier but no clear conclusion. Karen: Would be good to clarify why the API is or is not relevant. - Forward Plans TCP Extended Data Offset Option draft-ietf-tcpm-tcp-edo Speaker: Chairs for authors ----- - Status - Current issues - Issues... Yuchung Cheng: Saying, TSO driver must not do something is not realistic. It's not easy to change NIC's firmware. EDO is not going to be deployed Praveen Balasubramanian: TSO implementations, code could... Tom Herbert: There are variations in how TSO is implemented in different NICs, which is going to have an impact on EDO. Jana Iyengar: Addressing it as a MUST NOT is inadequate. Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters draft-ietf-tcpm-dctcp Speaker: Praveen Balasubramanian ----- - Next Steps Bob Briscoe: There is a machinery in DCTCP that still uses CWR. Sender sends, but receiver ignores. Thus, CWR is not necessary? Praveen: CWR is unchanged in the code, thus the reason why it is being sent. Bob: If it's unused, don't use that codepoint. Lars Eggert: Changing it in the draft is not gonna change the code. Bob: Asking if you can change it in the code. Pasi: We need one more review before LC. Lars: Changes are not substantial. Only a change in the calculation of alpha. LC should be done now. Yoshifumi Nishida: Are there any concerns in the room? Mirja Kuehlewind: Supports this, Bob has a review (yet to write and submit), we have enough, go ahead. Chair: Go to last call TCP Alternative Backoff with ECN (ABE) draft-khademi-alternativebackoff-ecn Speaker: Naeem Khademi ------------------ - I-D's scope - Status of the I-D Mirja Kuehlewind: Doesn't support to have normative language in the draft (thinks it is a mistake in the ECN draft). Hard to say what is right and wrong for congestion signal. Naeem: Why? Mirja: Because it is difficult to say what's right, what is wrong. Because, the state may change and thus the right answer might change David Black: As one of the authors of RFC 3168: I agree that encouraging Experimental for congestion control is a really good idea. 3168 was written for the broad internet, hence contains some very strict language that basically said don't do anything that would break things. We had people react to congestion if you CE-mark as if you're dropping a packet, we said: the only thing we know for certain is safe right now - this was a long time ago - was: react to it as you would react to a packet drop. I'm not opposed to interesting innovative things being done under the guise of experimentation, I wanna provide some history for why 3168 says what it does. Markku Kojo: Is there a reason why you are using cwnd and not flight-size, because if you are app-limited, flight-size is smaller than cwnd. Thus, flight-size has to be used in this case. 5681 says to use flight-size in the congestion-response. Naeem: I can't give any specific reason Markku: The modification that is needed is not quite as simple as you have proposed. Take it off line. Naeem: Consult with coauthors. Yoshifumi: An Experimental Draft cannot update a proposed standard. Naeem: Requests feedback on tcpm and iccrg lists regarding value for beta More Accurate ECN Feedback in TCP draft-kuehlewind-tcpm-accurate-ecn Speaker: Mirja Kuehlewind ----- - Background & Problem - History - Overview AccECN - AccECN Capa Negotiation - The ACE field Mirja: Add milestone and then ask for WG adoption Praveen Balasubramanian: DCTCP performs well without option Mirja: Provides number of marked packets, and option provides counter of marked bytes. Praveen: Introducing new options is always painful. Mirja: We do not require the option in the SYN, but in the SYN/ACK to test the path. And, option in the third ACK. Brian Trammel: Why not send CE first? (slide 8) Bob Briscoe: Your repeating the count of what will change most often Brian: Accepts rationale Karen: Why do we not go for proposed standard? Mirja: Because, it's a new option and we know there are problems with it. But, proposed standard could be fine as well. Yuchung: What about ACK-suppression? Mirja: If an ACK gets lost, it is OK Yuchung: You are saying more robust to ack loss Mirja: yes Bob: You must send an ACK every 6 times for CE markings. Mikael Abrahamsson: Is the code usable for experimenting? Mirja: It's not yet well tested. The big "issue" is that now it sends the option on each ack. future will change this. Karen: In SCTP there is something similar. Should we work on both in parallel? Chairs: How many people are interested in putting effort into this? (only two hands) Mirja: There is not much work left. Chairs: Why don't we wait another couple of IETFs Karen: Willing in reviewing it. Many people are not here, so let's not judge on the audience Gorry Fairhurst(jabber): I'll review this since I read the requirements document. Mirja: Not changing TCP behaviour, only the feedback mechanism. Like a hum on adding a milestone Lars: One of the pieces under TCP Prague. When this is laid out more it will be clear how this will be useful. Mirja: DCTCP is a usecase Lars: DCTCP doesn't need this, it is a new way to provide the same information. Not saying don't do it, just explaining why WG isn't as keen. Brian: I'll review it. Value to doing experimentation with this (HOPS hat). Supports bringing this in now. Tommy Pauly: Also review it. Interesting work. Chair: Hum for adoption. Adoption convincingly supported. Taking it to the mailing list. "Sharp Close": Elimination of TIME-WAIT state of TCP connections draft-kitamura-tcp-sharp-close Speaker: Hiroshi Kitamura ----- - For Next Steps Karen Nielsen: We have the same problem in Er. We have made TIME-WAIT configurable, and about 2s for the same reasons that you have outlined. Lars: There is a '99 SIGCOMM paper about faster closure. There are other things that can be done, let's assess this. Yoshi: If you use the linger-option, you send a RST and you eliminate TW on both sides. Karen: We did some analysis. I'll come back with more info on the list. TCB sharing: RFC 2140 vs. reality draft-welzl-tcpm-tcb-sharing Speaker: Safiqul Islam ----- Lars: "Cached" means cached and shared. Safiqul: Would like to have windows esp. windows and mac or corrections to linux and freebsd Lars: 2140 was informational, it was a research idea. And kind of similar to SPDY. Chairs: Status Safiqul: possible rfcbis document Lars: 2140 informational. CCR paper on this as well. Sharing of cwnd is interesting. Chair: Informational or other Safiqul: Discus with authors on how to proceed. Yuchung: Google has had caching/sharing turned off for a few years A-PAWS: Alternative Approach for PAWS draft-nishida-tcpm-apaws Speaker: Yoshifumi Nishida ----- Lars: Any option that gives back option-space is useful. Yuchung: Today Linux & Mac use TS by default. Using 10-12 bytes is annoying, but not a big deal. Will this incentivize Windows to use TS? Praveene: This would make it easier to support TS, but right now there is no incentive. Tim Shepherd: If we don't care that data gets corrupted, we don't need timestamps. We don't need to worry about seq-number if the connection does not wrap. I do not think we should ignore segments that are older than 2MSL. Because, there is no guarantee on the internet about 2MSL. Praveen: For things like ledbat, it is good to compute one-way-delay, and TS is useful there. Have you thought about adding an option to facilitate this? Lars: There was a paper that measured RTT's on the Internet at IMC --- found up to 180s. Increasing Maximum Window Size of TCP draft-nishida-tcpm-maxwin Speaker: Yoshifumi Nishida ----- Yuchung Cheng: Sure. But is there a need to do that? The current scale still works for the highest speed network I know. Yoshifumi: Google DC in Japan to Google DC in US Yuchung: OK Bob: Whatever you need today is irrelevant as speeds are increasing more and more. Doubled every 1.5 years. Christian Huitema: What we are doing here is to just double it. Following Bob's argument, at one point we need a 64-bit number. The RACK fast recovery draft-cheng-tcpm-rack Speaker: Yuchung Cheng ----- Christian: When getting an ACK, you do not know whether the ACK got received because of the retransmission or because of reordering? Yuchung: Good point. This is discussed in the draft. Timestamps allow to diff between retr. and duplicate/reordering. If no TS, we can infer this by using an RTT-heuristic Yuchung: Like to get community feedback on observed reordering Mirja: When you detect a loss, you also trigger congestion-event? Yuchung: Yes Yoshifiumi: What about pipe-size during recovery phase Yuchung: Our algorithm does not change the congestion-control. It just changes the trigger for loss-recovery. Yoshi: Isn't it more aggressive? Yuchung: [missed the answer] Anna Brunstrom: Do you have measurement results regarding the effect? Yuchung: Yes. I'll include more data in the draft We were able to improve loss-retransmits by 2 to 3 times compared to RTO. Jana: This is what is done in Quic. And it helps a lot. Karen: It's the natural evolution of the protocols. Similar mechanism in SCTP. PRR (RFC6937) and traffic policers No draft Speaker: Yuchung Cheng ----- Ethan Katz-Bassett: We looked at ?NDTD? data. Steady declines in policing. Yuchung: Still quite common Ethan: Yes Mirja: More explanation on "without detecting further losses" Yuchung: Only if the ACK does not indicate that a retransmission has been lost. Mirja: Does the loss of retransmission trigger a reduction of the congestion-window? Yuchung: Not in Linux Mirja: Maybe it should Yuchung: From an implementation point-of-view, it is really hard to do this. Mirja: Reduce ssthresh when you don't want to reduce cwnd? Yuchung: Good idea. Jana: ? loss coding problem ?? CUBIC fix in QUIC and Linux-TCP No draft Speaker: Jana Iyengar ----- Lars: We are looking for new authors for the cubic-draft - you can take the pen! Jana: Happy to look at the ID. Yuchung: Linux-bug was hidden, because Linux's cubic limits the increase to slow-start. Praveen: ?? Jana: Seen in youtube type sending Praveen: Slow start after idle? Yuchung/Jana (?): At Google, slow-start-after-idle is disabled (use pacing) - as most CDNs do. Chair: Does cubic draft have this? Jana: No Lars: We need someone that monitors netdev and updates the Cubic-draft. Mirja: What is the state of the document - how are we going to keep it in-sync with the Linux imlementation. Lars: It exists, updated once. How to maintain as linux moves forward. But better than now where there is no standard that describes linux Jana: Informational Karen: I thought cubic draft was going to describe cubic as an algorithm and not cubic the Linux implementation. Lars: Document could provide description of the best possible implementation. Tim Shepherd: Cubic by default also does hystart. Does this also describe Hystart? Lars: yes Tim: Suggest name change to cubic and hystart because they are two different algorithms. Deploying TCP Fast Open in the wild No draft Speaker: Christoph Paasch ----- Bob Briscoe: How often are you finding these problems? Christoph: Rarely, but fixed it with the vendor Mikael Abrahamsson: How do you define what is a network? Christoph: Client knows Tom Herbet: Changes client side or servers Christoph: Blacklisting is done on the client side. Each client has to do the probing. Brian: Can we see the black list? Christoph: We don't have the black list - on the client Brian: Can some results come to HOPS? Yuchung: linux netfilter doesn't check data in syn (old fixed linux bug), but some boxes running it. Bob: Conntrack bug. Surprised it is only 0.1% Andrew McGregor: Depends on how conntrack is configured. Although in netfilter everywhere, cases it is configured are probably relatively rare. Praveen: Is the blacklist permanent? Christoph: Yes at the moment, but it will be tuned as we gather data. Jana: 0.1% is not really low for TFO, but high!