TCP Maintenance and Minor Extensions Working Group Meeting : IETF 82, Wednesday, November 16, 2011, 9:00-11:30 Chairs : David Borman Michael Scharf Minutes : Andrew McGregor Murari Sridharan ============================================================== In the meeting the chairs were represented by Yoshifumi Nishida , assisted by Matt Mathis . ============================================================== AGENDA A. Working Group Status B. Current WG Items C. Non WG Items ============================================================== A. Working Group Status ============================================================== WG Status Chairs (represented by Yoshifumi Nishida) 10 minutes Lars Eggert: Do we need another co-author for the 1323bis draft? Michael Scharf (Jabber): David promised to complete the two drafts soon. Lars: Dropping the work item for draft-tcpm-tcp-security is one option. Joe Touch: Do we know what needs to be done to finish this? Is there a shopping list of stuff to be done? If not, it seems clear it should be dropped; we can't do anything with it for now. B. Current WG Items ============================================================== Matt Mathis Proportional Rate Reduction for TCP draft-ietf-tcpm-proportional-rate-reduction 15min No questions Discussion about post script slides: 15.2% of retransmissions make no further progress. What? Why? Lars: I suspect transparent proxies, e. g., in 3G. Joe: Sounds like NAT state losses. It was raised in BEHAVE that from the inside (private), a NAT should be a router. From the outside (public) it must behave like a host. They should send RSTs without state. RFC 5382 makes no recommendation. It should instead have said MUST send RST. Lars: Almost nobody implements BEHAVE. Have you looked at the destination addresses and seen what is going on? Matt Mathis: We haven't looked at that, and I can't get into name calling yet. It seems likely that it is a NAT vendor, and the ISP that owns the box doesn't know yet. Piers O'Hanlan: How many retransmits per connection is this? Matt: Hard to say. Around 6 retransmissions, which contributes to the size of the number. C. Non WG Items ============================================================== H.K. Jerry Chu TCP Fast Open draft-cheng-tcpm-fastopen 15min Joe: Is this data on slide 4 related to the graph that was just posted on the mailing list? Jerry Chu: Yes. Joe: I looked at the graph and came to the opposite conclusion. I looked at the places where reductions could occur, and the ones that could not. Out of 58 connections, about 14 or 16 could be sped up, they came in 6 phases, of which only the first phase could be sped up. Out of a 4 second page load, you could save 200 ms, which doesn't seem to tally with the numbers on this slide. And 200ms seems to be a too large RTT. Joe: You should perform the same test with p-HTTP with flushing the cache, thus assuming that the connection stays open for all components of page. Then, you should compare. Jerry: We are comparing the benefit ON TOP of p-HTTP. Joe: Did you see persistent HTTP in the data? If there's a problem with persistence, fix that too. If you're modifying both ends TCP, you could also modify for improved persistence. TFO also requires that both client and server are changed. Matt: It would be useful to do apples-to-apples. Step 1 is to fix reasons that pervent p-HTTP from being deployed. We have persistence activated, but it tends not to get used. But, for experimental purposes, yes, we can try that. Jerry: We have no control of middlebox. Yoshifumi Nishida: Is this draft ready for WG adoption? => Broad support for adoption (ca. 12), none against. Michael (Jabber): What the WG thinks about the changed SYN semantics (acceptance of old SYN packets with data)? Joe: We had a lot of discussions on that already. Joe Touch Shared Use of Experimental TCP Options draft-touch-tcpm-experimental-options 15min Jerry: Why is this not a standards track document, e. g., BCP, instead of informational? Matt: There used to be documents called implementer's agreements, it's really about implementers agreeing not to step on each other's toes. Matt: Padding with constant data could be at any offset. There's a lower failure probability if the offset is the same, but it works even without that. Thus, it's more about saying people making experimental options should pad them with constant data, and check that data. Matt: The problem with the existing process is that for provisionally deployed options, there's no way to recall them. This requires a separate document. Joe: There's no way to do that, the current situation seems to be that you can't know if a recall has been successful. Jerry: We have an immediate use for this, in any case, for fast open. Tero Kivinen: We should allocate a new experimental option for this, and register a smaller nonce with IANA, first come first served. No documentation required. Allocate a code point for it then we can make it mandatory and part of a standard draft. Brian Trammell: I think it's a cool idea. New number or structure in magic area would be good. Zero offset matters, because otherwise there's a fairly high probability of collisions. The draft should be more specific than Unix time. Tim Shepard: I think Tero has it right, it's better to allocate one new option, followed by one or two bytes of registered code points. This means rarely used options can just use this space, effectively creating a three byte extended option space. The four extra bytes might run us out of TCP option space rather than codepoint space, which means option combinations with this proposal may not be possible. Matt: I think we should do both, meaning that the current experimental options should be done by Joe's proposal, and that we should also get two new experimental options. The recommended use for the former is unstructured const data and other with structured nonce; padding doesn't have to be at the same place. Rather than register, the use should be declared on the TCPM list. Joe: We don't need to create a new solution. The problem with list assignment is finding the assignments. First-come-first-served at IANA is easier. Tim: Do both, i. e., require announcement on the list when registering with IANA. Joe: I want this to be a WG item, happy to take all this to the list. Lars: What would make me ever migrate to a normal option? I would need to check both cases. Joe: Makes it smaller. Lars: Effectively we're making a TCP long option number option, which is Tero's proposal. Joe: A new option codepoint would require standard track document. Matt: I completely agree with Lars. That would lead to a lifecycle document for options. You have to expect code supports 2 version of option field. Code should have a calendar to deprecate options. Yoshifumi: Is this ready for WG adoption? => Broad support for adoption (ca. 12), none against. The question whether to allocate a new codepoint is postponed. Joe Touch Automating the Initial Window in TCP draft-touch-tcpm-automatic-iw 15min Lars: Question for clarification Joe: The alghorithm picks an IW such that 95% do not have losses. Lars: There are boxes that run through the whole port space in less than the MSL... 1000 are low. Joe: Don't comment on numbers yet. Tim: There are going to be some boxes that never run up to the IW, and shouldn't turn it up because they have never tested. So you shouldn't count connections that never reached IW. Ilpo Jaervinen: If you have pathological reordering, you need to understand the impact of false positives. Andrew McGregor: A lot of us have machines that go everywhere ... what about them? For mobile devices, you could lose horribly if you arrive on a new network. Lars: Maybe you can start from scratch as your IP address changes. Joe: There are devices that change IP addresses very frequently. Mirja Kuehlewind: More generally, what should we do with IW at all? A long lived connection has little benefit. I don't see where the benefit is for auto tuning IW. Joe: If most people do something like IW=10, then we're recognising that there can be benefit. And the same value is used for restart. This allows automating the learning process, to avoid re-standardising. Mirja: I don't believe there's one value that works for all connections. Joe: Sure, and this is the mechanism that allows you to learn this. Igor Gashinsky: I think this is great work. We tend to disagree with Jerry's number, we get 7 or 16 depending on the subnet, there is no universal number, and therefore this is vital. We should do something like this per subnet. Tim: Something adaptive is better than a constant. It is hard to pick the constant. A shorter timescale is probably better. Joe: The purpose of this document is to specify numbers for an experiment, and the granularity is part of the experiment. Tim: I don't think it makes sense to be a WG item yet, I think there might be better solutions. I encourage to proceed, research, write drafts; make WG item later. Jerry: IW=10 doesn't fit all situations, and I like this but have reservation: Mobile devices often don't stay up that long, and so this requires persistence and results in complexity. Joe: You can always start from 10 and don't do anything. Jerry: If most devices don't stay up long enough to adapt, the whole thing becomes moot. Joe: Persistency can be solved. Lars: Partially agreeing with Tim, I'd like us to think more about the nature of the mechanism before adopting it. We need to make sure we're conservative about adjusting upward, but adaptive about reducing it. Mobile devices matter, but surely they don't send so much? Joe: Actually does matter for clients. If it becomes a WG item, we can argue about the algorithm. Lars: If we adopt, it means we think there should be such a thing, but it might turn out too complex. But I want to keep discussing. Joe: Hence experimental. Matt: I think all these answers are wrong, but I don't know the right answer. There are classes of end systems that are shipped to naïve users. In data centers, servers run by professional who understand it. One size fits all for both the communities is broken. So, for data centers, the question is how do you test the current config, and for unmanaged devices, are we creating a legacy that will bite. I don't know how to make this work as a single algorithm. Joe: Could do a call-home to the vendor, reporting stats on losses. Yoshifumi: Is this ready for WG adoption? => No support for adoption, but interest in continued discussion. Based on feedback, Joe announced to withdraw the draft. Mirja Kuehlewind Accurate ECN Feedback in TCP draft-kuehlewind-conex-accurate-ecn draft-kuehlewind-tcpm-accurate-ecn-option 15min Lars: The last I heard about the ECN nonce was about 3 years ago, and then it was very quiet. Is the ECN nonce still relevant? It was experimental, and I haven't seen much use. Can we reclaim it? Mirja: You want some kind of check if you rely on congestion notification for congestion control. Richard Scheffenegger: The input is supposed to be more accurate than in regular ECN, which means some basic safety is important. Lars: I mean the RFC that defines the use of the ECN nonce bit. I'm trying to clarify the usage of the bit. Matt: Combatibility with a standard that never launched is not so important. ECN code is widely deployed but turned off, whereas there isn't any cose for the nonce. Matt: Also, I think a real counter, in other words an option encoding, is much better than three bits, because three bits can miss entire events. Could think about putting the counter in the padding for certain options, SACK for example. The outcome is better. The version with 3 counters too large/heavy. Richard: There are still unused flag bits in the TCP header, we could stuff it in there. Mirja: I have to disagree, I don't think that works. Yoshifumi: Is there interest in this work? => About 7 are interested. Suggestion to resubmit as TCPM document. Richard Scheffenegger Additional negotiation in the TCP Timestamp Option field during the TCP handshake draft-scheffenegger-tcpm-timestamp-negotiation 15min Joe: Will the mitigation technique break RTT estimation? Richard: Hopefully not, but that's not guaranteed. I'm not very much in favour of this. Yoshifumi: Have you thought of using a new option instead of timestamp option? Richard: This is intended to be backward compatible. Tim: It is intended to deployable at one end only. Richard: False positive rates were so low as to be negligible. Yoshifumi: Is this ready for WG adoption? => No support for adoption, but there is significant interest (ca. 10) to continue the discussion. Tim: What is the conclusion? Yoshifumi: We need more feedback, discuss on the mailing list. Per Hurtig TCP and SCTP RTO Restart draft-hurtig-tcpm-rtorestart 15min Richard: This interacts with my draft. I'm all for reducing RTO as far as possible, but I'd like to check out the interaction. Joe: One thing that bothers me is, does anyone care? We should not make TCP more complicated when we don't know if it will matter. Matt: Yes, it matters to us (Google). Mirja: Do we need an IETF document? The Linux guys can do whatever they want anyway. Per Hurtig: It would be nice to have something written. Matt: I second that. Yoshifumi: This is not TCP-specific. Joe: This needs to be coordination with SCTP. Lars: Matt, do you care about it for SCTP? It should get more review here. Yoshifumi: Is this ready for WG adoption? => Around 6 participants are interested, which is not sufficient for adoption. Discussion should continue on mailing list.