TCPM meeting at IETF-96 Berlin, Germany Monday, July 18, 10:00-12:30 Chairs: Michael Scharf Pasi Sarolahti Notes: Gorry Fairhurst Brian Trammell 1. Agenda discussed. 2. WG status For slides, see meeting proceedings. RFC793bis - Update by Wes later in the meeting EDO - Joe has new implementation work DCTCP - Update posted this morning - Please read and note any concerns (WGLC may come soon) Cubic - There is a pending update - Please read and note any concerns (WGLC may come soon) Acc ECN - Updated --------------- 3. Working Group Items 3.1 Wes Eddy (Chairs update for editor) - RFC793bis Draft: draft-ietf-tcpm-rfc793bis No questions. 3.2 Mark Allman (Chairs update for editor) - Moving forward draft-ietf-tcpm-rto-consider Draft: draft-ietf-tcpm-rto-consider - Slides prepared by the Chairs. Various topics raised on the list were presented - see slides. The chairs asked if the change of MUST to SHOULD in relation to RFC6298 needs to be marked in the IETF series as an UPDATE? Mirja Kühlewind: If this document applies to TCP, use of RFC6298 is a “MUST” for TCP. Pasi: Does this allow wider experimentation? Mirja (as AD): That depends on what it says in this document. Christian: The present algorithm in RFC6298 is a compromise between implementation and protocol. I think the “MUST” use requirement is a weird, this is based on what hardware was available 30 years ago. Pasi: The question remains. Pasi: Should the RTO considerations refer to RFC5405bis as a reference for UDP designers from this draft? David Black: I think the answer is “yes”. I think the ID in TCPM is a good document for design of mechanisms, and this should proceed here. However, the normative statements for using UDP belong in RFC5405.bis, and recommendations for UDP belong there or in TSVWG drafts. Pasi: OK. We should take this forward in that way, and finish this work here. David: I agree. RFC5405.bis has passed IETF last call. I do not want to be standing at a microphone queue in the Seoul still discussing the UDP Guidelines. David B: I had problems with the original text presented and then made suggestions to improve the text, as reflected in option 2. Lars Eggert: I support removal of the “Future implementation freedom” text on the slide. Gorry: I also think we need to remove this text. The ID should encourage people to publish drafts that document what they will do or have done. I do not like the idea of encouraging future changes that do not need to be documented in the RFC-series. David B: I do support removing this. Mirja: There will be another update, and I think choosing to use normative language to describe informational procedure. Pasi (as Chair): OK. We now have feedback for the editor. Lars: This is a TCPM WG item and Mark is a WG editor - so the Chairs will need to relay things to the editor to reflect the consensus. David (as TSVWG Chair): TSVWG plans to update the text. There will be a deadline to commenting on this topic. Michael (as Chair): The ID will be last-called in both TSVWG and TCPM. --------------- 4. Other Items 4.1 Yuchung Cheng - Updates of RACK Linux implementation Draft: draft-cheng-tcpm-rack Lars: What happens if you have a variation in the base RTT that is greater than reo_wnd? Some paths do have varying RTTs. It seems this would result in spurious retransmission? Yuchung: Yes, there can be cases of many losses. Jana: You could also measure variation of the RTT and use this to select a “reo_wnd” that is more like a maximum. Yuchung: There is a surprise benefit in reducing TSO fragmentation (fewer SACK merge events). Lars: Do you have stats on how many extra transmissions are commonly observed? Yuchung: This is around 0.5% Randall Stewart: We are also playing with RACK at Netflix using a BSD implantation, and also see similar benefits - and an additional benefit that RACK can recover from all loss patterns - previously TCP mechanisms had some patterns that were hard/impossible to recover. Praveen Balasubramanian: I think this is good work, we have implemented RACK in Windows. Lars: I would like to see more data because this is a core mechanism for TCP. Come and share results and experience with the IETF - either here in TCPM or in ICCRG. Christian: I think the actual intention is to replace the DupACK? Yuchung: Yes. Ingmar: I found the RACK spec easy to understand. A change in how we detect loss will impact design of the network: Current 3G stacks typically try to preserve ordering, this in sequence delivery requires mechanisms at layer 2. Yuchung: ?? Gorry: The present method of using DupACK serialises the protocol packets on the wire is very robust to very unusual paths, since it eliminates the impact of timing variations. If we do RACK, we need to keep in mind that TCP needs to be robust to the most unusual paths we encounter, and not design just for performance of the most common path. Robustness is important. Lars: Can we give a guidance on the reordering window that would be best? Jana: This moves from sequence number to space time. Praveen: Should we ever discard the min_rtt measured, e.g., after a timeout? What about path changes? Yuchung: We think the min_rtt is still a number that was measured, and only discard after over the last 5 minutes. Praveen: I think the rules for discarding the min_rtt should be in the draft. Praveen: What about when one TCP session shares multiple paths? Yuchung: Yes, this sometimes happen (e.g., under extreme load). Christian: Reordering window is a key parameter. How do you set the parameter? We need need guidance on choosing this parameter. Yuchung: Packets are reordered in a RTT. It is hard to judge whether we should set the window at 1/4 RTT or something. Christian: This is only vaguely related to the RTT , what if we have multiple paths used at the same time? Randall Stewart: We could make RACK reordering-adaptive. Yuchung: I tried, but I could not see the best algorithm, we need more work on this. Michael Scharf (WG Chair): What is the relation to Tail Loss Probe (TLP)? Yuchung: Both can be done at the same time, and this can simplify the implementation. Michael Scarf: Can we then also merge the documents? Yuchung: We could merge these in future. Christian: I do not know of issues when implementing both specs at the same time. Praveen: I think TLP can also be implemented just on its own. Andrew McGregor: I think the mechanisms are orthogonal. -: It can be more important to have simpler documents. Michael Scharf (as WG Chair): How many have people in the room have read the RACK ID ? (about 10) WG Chair: Do you think RACK should become a WG item? (about 20) WG Chair: How many people think the WG should not do work in this space? (0) WG Chair: Do you think we should immediately adopt this item? (10+) WG Chair: Do you think we should defer to see how TLP could integrate? (0) Pasi (as WG Chair): I think we look to an EXP publication, if we proceed. Jana: Does the header of an EXP ID need to list drafts it updates in the header? Gorry: I suggest we note which RFCs are updated in the text, but do not list list the update in the header, I think we need to wait until the experiment is over - only a PS should update other PS RFCs. ---------- 4.2 Praveen Balasubramanian - Transport advancements in the Windows networking stack David S: When you say “all outbound” TCP-Fast Open, do you mean all outbound connections using FO with TLS? Praveen: Yes. Bob Briscoe: What was the correlation between servers that did not accept a TCP-FO and did not do the correct thing? Praveen: There was no statistical evidence of problems. There were no more drops than for other SYN drops (e.g., drops die to under load.) Jana: I like the experimentation. Is there a link to the current API? I would love to be able to use a common API? and see I would love to see Fast Open logging data - that would be really interesting. Praveen: Currently the only error feedback is a single burst. Gorry: When you see IW10 has problems, have you considered caching the use of a lower IW, rather than just changing the cwnd for the session? This would avoid repeatedly probing with a larger IW for each session? Praveen: We are looking at options for keeping it between flows, but there also can be cases this can be very conservative. Praveen: What is the delayed ACK procedure in Linux? Neal Cardwell: Linux has been using 40ms for some time, it does try to determine if the flow is a bulk flow and adapt. Bob Briscoe: Under what cases does RACK not help? Praveen: For example, too small a RTT causes implementation challenges with timers. Ingemar: Do you need to infer the timestamp clock on the opposite side? Praveen: That is something we need to deal with. Ingemar: I also saw issues when IW<4 segments. Bob: The interesting thing is that Remy only changes the algorithm, if you change the protocol you can do even more. Lars: We did standardise on New-Reno, there are now multiple co-existing methods. Praveen: There are tradeoffs in the network. Ingemar: Throughout and delay can be tuned. Most LTE networks use AQM. Dave Täht: Answering these two questions would need beer to proceed. Michael: This discussion should be continued in ICCRG. Lars: Thank you to Praveen and others for providing the WG with experience with real implementations! --------- 4.3 Naeem Khademi - TCP Alternative Backoff with ECN (ABE) Draft: draft-khademi-tcpm-alternativebackoff-ecn Bob: I was thinking last night about this... Cubic is used as a justification for this, but this does this for a high bandwidth case. Roland Bless: I think there is value in this. If we have many flows sharing the bottleneck, you could then have many flows that use a bottleneck, so you can adjust beta - but that is hard to figure out in practice. Roland Bless: You can keep the utilisation high if you do this. David Black: The TSVWG draft seeks to remove the constraint to allow this experimentation. Pasi: ... Colin: There is also work in other IETF areas that also rely upon ECN. We should also consider other uses of ECN (e.g., UDP-based protocols) and we need to evaluate all of these together. Markku Kojo: I support doing work on the current draft in TCPM. Markku: I think the current form of relaxing this in TSVWG is dangerous, it would allow any form of update to ECN. David Black: I would like to see the TSVWG draft say that the IETF retains control of proposed uses. I think this is a good topic to take forward at the TSVWG meeting. WG Chair: How many have read? (10) WG Chair: Please hum if TCPM should allow work on this in TCPM (moderate hum for) WG Chair: Please hum if you think TCPM should not do this work now (no hum against) ------------- 4.4 Michael Welzl - TCP Control Block Interdependence (2140bis) Draft: draft-touch-tcpm-2140bis Jana: This is interesting. Do we have data to support this as a BCP? Michael W: We have data from BSD and Linux, but many of the params are not shared (only ssthresh). Praveen: We should probably include windows, we share PMTU and FO cookie. Yuchung: I think we should not do this. Linux experience suggests there can be negative implications with caching. Michael W: It depends on the use case, the draft does not always recommend caching. Yuchung: That is my point. There are a lot of caveats in how you use these parameters. Google Michael W: This is starting a discussion about all parameters, and identifying useful values. Yuchung: This documents the pros and cons of each. Pasi: This could be informational. Jana Yiengar: Is the recommendation to recommend best practices for caching. Saying something about how, why or why not - sounds useful. Michael: There is value in documenting the implementations, there may be opportunities to modernise the wording. You can make significant improvements as you edit the document. Pasi: Can you please add a section on key differences between the draft and the original RFC. Michael Scharf (WG Chair): We are not doing an adoption call at this time. Please continue to update. ------------- 4.5 Carles Gomez - TCP over Constrained-Node Networks Draft: draft-gomez-core-tcp-constrained-node-networks Lars: Is the local interface MTU not already setting the MSS? Carles: This is less than the minimum MTU for IPv6. Matt Mathis: We are missing a specification about the relationship between MTU and MSS. Michael S: We will probably see several topics that will generate questions. Brian Trammel: These are constrained nodes? Do they care about the additional energy costs of keep-alives? Carles: There may in some cases be no other choice. Lars: I think this is too much in one document. It mixes things that conflict with the existing TCP RFCs, highly optimised RTO with other simplified mechanisms. Saying not to use existing mechanisms is a big issue. Gorry: This is a complicated mix of things, trying to simplify complex mechanisms may not be a good way to proceed. For example, you say using a window of 1 and choosing ECN, that does not seem possible to work properly. Maybe it would be helpful to start with a really simple subset of TCP, and think separately about adding what you need. Carles: ECN is a recent addition. Gorry: It may be impossible to do correctly with only one packet per window. Colin: In general, we should avoid thinking about requiring not to do things, that prevents evolution. Lars: Have you thought about using TFTP to meet your (simple) goals? Carles: Will look at this. ------------- 4.6 Marcelo Bagnulo - Adding ECN to TCP control packets Draft: draft-bagnulo-tsvwg-generalized-ecn Brian: We need to still have mechanisms that allow us to differentiate paths that work, but if we make measurements harder, we may also eliminate options to probe to determine the path behaves as expected - that may prove an issue for Dave That: There are protocols that would be benefits for other protocols if you let excess packets be dropped. Marcello: You can also drop ECN-marked packets. Bob: In a normal regime you do not want to drop SYNs. Chairs: The document should be discussed on the mailing list. ------------ 5.1 Marcelo Bagnulo - Recommendations for increasing TCP performance in low RTT networks Draft: draft-bagnulo-tcpm-tcp-low-rtt No remaining time, please read this draft and send comments to the list. The WG meeting closed.