TCPM WG Meeting Meeting : IETF88, Monday Nov 4th, 2013, 9:00-11:30 Location : Vancouver, Regency A Chairs : Pasi Sarolahti Michael Sharf Yoshifumi Nishida AD : Martin Stiemerling URL : http://tools.ietf.org/wg/tcpm/ Note Taker: Richard Scheffenegger, David Ros -------------------------------------------------------------------------------------------- 1: Chair Slide Pasi: TFO draft. Do we need new option number or using ex-id? Yuchung Cheng: We are going to continue supporting use of RFC6994 experimental ID for at least another 5 years. Pasi: How many people support IANA code point? (support more than 10, oppose 0) Martin Stiemerling: Can you foresee if TFO will be just an experiment or will it still be there in 10 years? That will decide whether we should get code or not. Stuart Cheshire: I'm optimistic about TFO for widely deployment, more than an experiment in the long run. Experiments can be dangerous for leaking out of fault implementations, compatibility issue. Let's get a official final ID. Gorry Fairhurst: Wasn't the point of experimental IDs to be able to run long term experiments? Gorry: We just need to decide as a group if this is going to be ok to be used as an experiment and eventually go to stds track. If it's not safe, we declare it's experiment now for checking deployment issues and so on. Martin: Let's take this to the list. If there's another implementation supports non ex-ID, we can think about IANA code point. -------------------------------------------------------------------------------------------- 2: TCP Roadmap - Pasi on behalf of Alex Zimmermann Jana Iyengar: I agree it's difficult to decouple congestion control and loss recovery, but splitting is valuable. It's important for folks that come to TCP. We might need to point out they are tightly coupled in the draft, but it's still valuable separation. -------------------------------------------------------------------------------------------- 3: Updating TCP to support Rate-Limited Traffic Jana: One problem is cwnd as it is means little in the absence of ack clock. The hard question is: pacing; my answer is Yes. Having some kind of pacing is invaluable. In the absent of pacing, it will cause burst and loss, then cutting down cwnd, which is incorrect. Randall Stewart: What is maxburst in your definition? Why it doesn't work? Gorry: it's severe rate shaping, before ack clock starts again. Jana: Isn't it possible to say we should use pacing? Yoshi: Are you suggesting pointing to some drafts? Jana: No. It should be implementation decisions. Pasi: It could be some kind of appendix for the draft. Brian: We can continue this discussion as there should be some evidence for this. Gorry: We have some results. Pasi: Do you plan to publish them? it'll make easy to finalize the draft. Gorry: Yes. Karen Nielsen: 5 minutes to halve cwnd. Isn't it contradict to RFC5681? Gorry: This draft will override RFC5681 on the point. A question might be how we handle pacing in the draft. Jana: We can do pacing. We can point to existing work, but don't need to exactly specify what kind of pacing is needed. Gorry: Does it affect whether we should go experimental or PS? Pasi: It's too early to discuss it. -------------------------------------------------------------------------------------------- 4: RTO Restart -- Anna Brunstrom Michael Tuexen: In your implementation, can this be set per connection / socket? Anna: Yes. Michael: Do you have a section in the doc explaining the socket option? Anna: Not yet. But, yes. we can do it. Yuchung: RTO is good idea. Maybe we can simplify the rule. As a tcp implementor, I don't want to check 3 rules every time. I think it's extra complication. Anna: It's safety cushion, not only for spurious RTO, but for actual losses. Stuart Cheshire: Having a simple single rule make sense. Brian: Do you have some data this is an issue? Yuchung: We have a problem in linux implementation. But, it's a problem for linux, not for RTO. Yoshi: If we remove the rules, it might increase the risks. Michael Welz: How about leaving as it is? It also states the rule can be removed when it proceed from experimental to PS. Jana: Why are we doing experiments? Pasi: We don't have concrete data yet. Anna: Wondering we should do experiments with minrto 1 sec or smaller value. Stuart: Just data point. macos was using 1 sec for a while, it's changed to 200ms recently. Yuchung: We should find a good way not to complicate the logic for this. Matt Mathis: The point is entire RTO architecture needs to be revisited completely. Don't apply another bandaid as it will add another complexity. Make it as simple as possible. -------------------------------------------------------------------------------------------- 5: More Accurate ECN Problem Statement -- Richard Scheffenegger Richard: open issue: naming. Many people dislike the name: more accurate feedback Michael Welz: more detailed? I can live with as it is, though. Andrew McGregor: more accurate is a perfectly reasonable name. -------------------------------------------------------------------------------------------- 6: ECN Path Probing and Fallback -- Brian Trammell Bob Briscoe: About guidelines for fallback for options, it's worth having a draft of just about ecn. But, you might need to put a context for general fallback. Matt: There are some paths which put some garbage in ect / ecn bits. Brian: We have some data. I also think some operators might use these bits from themselves as well. Andrew: Mid-stream fallback might be good to save the day. because of routing changes, etc. Bob: fallback shouldn't be in the ecn part - turn off all options at once. Stuart: It's important to have these mechanisms, don't have to be over the top with this. As ecn gets used, broken things get fixed. Matt: Suppose if we can measure at scale where these problems are, what to do with that info? Jim Getty: When steve ?? has done his study, just by telling people that their nets are broken, a large fraction of the Internet got fixed. -------------------------------------------------------------------------------------------- 7: RFC 793-bis -- Wesley Eddy Alexander Zimmermann: Do you want to obsolete 1122? Wes: That's more than just TCP. If everyone get together one day, maybe.. Matt: extreme danger from mission creep, eg silly window syndrome. delayed ack strategy has not been reviewed. it spiral out of control easily. precise this is only a subset of 793. Bob: Is this the right time to do it? This effort is going to take 1-2 years and several experimental changes going on TCP at the moments. Some of them might be PS during this. Matt: TCP algorithms fall in certain two categories, necessary machinery and heuristics / estimators and other stuff. Some estimators are described in separated drafts. 793bis should focus on stuff you have to do in order to exchange the packets, also what estimators should be done. Jana: Second to Matt. Also, need interoperability between separated drafts. Gorry: Some extensions coming, would be a good time to have a "base" against which to compare. Yuchung: It's quite useful, people try to implement tcp, identify the fundamental ones, critical ones, optimization. -------------------------------------------------------------------------------------------- 8: A-PAWS: Alternative Approach for PAWS -- Yoshi Nishida Matt: About PAWS logic, things get worse. If someone inserts forged packet with large TS, the rest of received packets will be discarded. Yoshi: Right. That's well-known attack against PAWS. Matt: I had long running conversation with Dave Borman about relaxing TS conditions allowing late timestamp negotiation. It might be trivial for existing implementations to accept late timestamp. You can encourage this first and then think about something like you proposed. Another way you can do this is if one end is doing timestamp and the other end doesn't, all you need to do is limit the data rate under 200Mbps. David: The biggest issue of PAWS vs RTT is that PAWS assumes TS in every packet, and if you want to use TS for RTO measurement on only some packets, it'll cause issues for PAWS. That's why late negotiation of TS means sending them in every packet after that. The big challenge is backwards compatibility Yuchung: I think TS might be useful for spurious timeout. But, I like this idea. TS is taking too much space. Brian: TS is useful for passive observation. There is trade off for removing TS. Yuchung: You mentioned 3 possibility for signalling. Which one do you prefer? Yoshi: Second one. Yuchung: I also prefer that one, too. It might be less problematic for middlebox. Yoshi: My little concern is if we have an option in DATA which has not been seen in SYN, some strange middleboxes might discard it. -------------------------------------------------------------------------------------------- 9: TSO + fair-queuing + pacing: three is a charm -- Yuchung Cheng Matt: The 2nd burst, it adjusts to bottleneck speed. It got to be right even though it uses old RTT estimation. Yuchung: Right. But, latter it got to be wrong. Jana: You are tracking full queue. Entire queueing delay. Jim: Putting these bursts into the network is really killing low latency apps. Andrew: Was the stretch ack something of a signal, that you found the end of the queue? Shahid Akhtar: With aqm you have additional buffer capability, if aqm is deployed properly. such problem would be much less. Also, you have not paced the whole burst of data, have you? Yuchung: There are many ways to send cwnd in an RTT. I'm trying to make smaller burst. Matt: ECN does not help within an RTT. Shahid: My comment was about AQM, not ECN Karen: Are you changing ssthresh after idle? Yuchung: No. We don't touch cwnd or ssthresh. Gorry: How can we do this quicker to decide which one we should recommend? Jim: Ship the code. Another point is to provide inventive to be more gentle to the network. -------------------------------------------------------------------------------------------- 10: Sequence number validation -- Fernando Gont Fernando: TCP MUST support self-connect might be strong. Change to SHOULD? David Borman: As an author, agree. Matt: bgp is prone to self connecting. There are some cases where true async simultaneous opens need to be supported. Fernando: If we can handle simultaneous open properly, we don't need to ban self connecting. Matt: About ZWP. deadlock condition to avoid, honor the window field is announced, process control info. Alexander: If we adopt this draft then we can incorporate it directly into 793bis, no? Fernando: Better to get this done before, then RFC793bis would pick it up. Yoshi: This doc should be stds track, so we need to be careful. Matt: It might be properly to justify special handling of a RFC. Document the code which hasn't described yet. It's a corner case, it's not an experimental, everyone uses it. Not invent new function. Pasi: The document hasn't updated recently. We can wait one more meeting for WG adoption. Karen: I think the draft has not covered all the cases yet. Martin: We might not have to wait until next meeting. We can discuss this on the ML. Pasi: Let's get more feedbacks on the list.