TCPM meeting, IETF-87, Berlin, Germany, Tuesday, July 30, 09:00 - 11:30 --------------------------------------------------------------------------- Chairs: Michael Scharf Yoshifumi Nishida Pasi Sarolahti Note takers: Michael Welzl Gorry Fairhurst WG status Chairs draft-ietf-tcpm-1323bis-14 Richard Scheffenegger -------------------------- Slide 8: Pasi: This is about PAWS and receiver behaviour when there is no TS in arriving packet (e.g., middlebox modifies it) Mirja Kuehlewind: why drop packet? (without timestamp) Richard: Maybe it's a delayed packet from an earlier session, that's the basic point Mitch Gusat: If it's from an old session it should be rejected Bob Briscoe: Another strategy regarding space: only use timestamp if we have space for it Richard: Is it a guarantee? Then you have to drop the packet. If it is just best effort (you can basically end up with a corrupt stream), then it's not clear. Bob: It should be a SHOULD. Implementor should be able to decide. Mirja: I believe it's a clear should, because there are cases where you should not do it. Stuart Cheshire: Is there evidence of middleboxes doing that? Richard: This can happen if a middlebox starts stripping timestamps subsequently in the session (e.g. path changes). Chairs: What's the opinion about this change? Bob: What's Richard's opinion? Richard: Undecided. Michael Tuexen: So you're considering a path change. Do you have an example where that happens, a middlebox having enough state to let the packet through, but not enough state to keep the options. Mirja: It can happen. In most cases it wouldn't. Richard: this would effectively make the PAWS mechanism best-effort. Yuchung Cheng: Could lead to a lightweight burst of ACKs between sender and receiver. Richard: The two red words go together. Proposal is to change both or none. Randall Stewart: I've seen this behavior. Mirja: You should specify this correctly, it should be a SHOULD. To put a MUST so that people implement it isn't an argument for putting a MUST there. Bob: If you put a SHOULD and SHOULD NOT you should explain why you should or should not do it. Chairs: Show of hands. Result: 4 MUST, 10 SHOULD. Chairs: Mark Allman promised to re-read. If everything looks good after that we could go to WGLC. Stuart: I want to echo what Bob said, if the text says SHOULD / SHOULD NOT there should be an explanation about why you would or would not. draft-ietf-tcpm-fastopen-04 Jerry Chu -------------------------- Gorry Fairhurst: so you got rid of the cookie for some cases? Jerry: It's still there in the draft, it's a MUST Bob: Slide starting with "Warning of semantic change…": we need to make it clear to people which application we're talking about. It won't be the browser but the javascript application running on the browser that uses this. It's not per-application, but per-socket. "Applications should not use TFO unless.." => here the application is Javascript, not the Browser. Michael T: slide starting "New Appendix: socket API appendix": maybe you want to have a socket option on the client that enables fast open for that socket, and then you just do sendto and it's used. Jerry: ok Chairs: The draft has been around for some time, yet based on the discussion it seems another update is needed. Then we hope we're close to WGLC. draft-ietf-tcpm-newcwv-02 Rafaello Secchi ------------------------------------------------------ Yuchung: What's the difference between idle connection and restarting connection. If you cut down from a cwnd of 100 you will see a burst of 50, so we should allow IW50, as the rationale the same. Rafaello: The difference is that the network between has been used before. Yuchung: Example. I have a connection that runs for 1 minute. Then I stop and start a new one, which has to start with IW10. Here we stop the connection and start again and it can have 50. Rafaello: It's not exactly the same as removing all the state and starting a new connection. Yuchung: I get that you're validating that the window is okay, but then you're sending a line rate of 50, which is almost certainly going to create loss. Jana Iyengar: Difference between new and connection that went idle is that you hope to have information in the old connection that you should be able to use. e.g. for pacing. Without pacing, you just have a large burst, so I agree with Yuchung. Gorry: If the burst is bigger than IW then we have to think about if this is okay. Making pacing work effectively is another problem. Randall: In FreeBSD they had a host cache for years. The old cwnd and MTU are stored. maxburst of 4 seems to work really well, Sun has been having it for years. Chairs: based on the discussion it seems we're not ready to decide between Experimental or Standards Track right now. There was also discussion on the mailing list, which was good, but we should try to address the concerns raised. Would appreciate getting a solution that is broadly agreed upon, and then we could go for Standards Track. Jana: I didn't see numbers about what buffer sizes were in your experiments. Line cut, to be taken offline. draft-ietf-tcpm-rtorestart-00 (no new draft) Anna Brunstrom ------------------------------------------------------ Yuchung: I like the idea and also tried it. What we see is an immediate jump of spurious retransmissions. I think the problem is Linux' aggressive RTO. I can send you a trace from a browser talking to a Linux server. The client opens a lot of connections and that creates a delay spike. That causes TCP to slow start and retransmit. So I like this idea but maybe with the Linux implementation you need to change the minimum RTO. Anna: Please send us the traces. Alexander Zimmermann: It's a problem of Linux, not the draft. Yuchung: Yes I like the idea, but when you try this you see problems. We saw a LOT more spurious retransmits ... Linux has a low default RTO that may be too low for this to work well. minRTO may need to be changed, and see if spurious RTO is a real issue. Alexander: Yes but it's the problem of Linux not following the RFC, not a problem of the draft. Randall: FreeBSD does not follow the RFCs either Chairs: I see a lot of potential for experimentation here. It would be good to see a draft update and some realistic numbers. draft-ietf-tcpm-accecn-reqs-02 Mirja Kuehlewind ------------------------------------------------------ Chairs: looking for volunteers to review. Not just Bob. Volunteers to review: Bob, Michael Welzl, Gorry Gorry: CE is remarked? Seemed to be a misunderstanding. Chairs: Would be good to have some mailing list discussion. Let's also see what the outcome of reviews is, then we see if we're ready for WGLC. draft-zimmermann-tcpm-tcp-rfc4614bis-02 Alexander Zimmermann ------------------------------------------------------ Chairs: it is already been out for some point and got a bunch of feedback. We'd like to check if the WG is willing to adopt the document. How many have read it? (About 7 people.) If you think it should be adopted, raise your hand: (pretty much the same, maybe 1-2 more.) Reviewer volunteers? Richard, Yuchung, Jana It seems we should adopt it. We will probably confirm on the mailing list that it is adopted. draft-dukkipati-tcpm-tcp-loss-probe-01 (no new draft) Yuchung Cheng ------------------------------------------------------ Bob: If you have an RTO you need to have a more conservative behavior than otherwise. you need to have some distinction there. Yuchung: Instead of setting to ssthresh you set to half ssthresh? Bob: Whatever number, but proportionate to how serious the problem is. Yuchung: We can experiment with the idea. Chairs: relationship between this and the next draft on the agenda? We seem to have more than one solution for tail loss. Are we going to have one or more? Yuchung: The XOR packet (next presentation) could be the loss probe. Chairs: let's decide that we do this and we also do FEC, then we have two solutions that somehow overlap, as you just noted. Yuchung: Nothing against one solution, I'm totally for simplifying loss recovery and go for the best one, I just hope the WG likes the idea. Mirja: How often do you have tail losses? Yuchung: I don't have the exact number in my head but definitely over 50%, I remember the number is close to maybe 70. Mirja: How many are from the first IW burst? Yuchung: 30%. Mirja: Maybe we should rethink the IW. Richard: loss probe and FEC address two different problems and are different solutions for different environments and assumptions. I think they can't be combined, at a high level targeting the same stuff but having different requirements. Jana: Would be interesting to see how many losses happen during idle times, not just IW. I think you're losing information here when you're dropping the ACK clock. I think something more aggressive can be done. It's harder to correct losses when this happens, but we need to step out of being exactly precise in these situations and allow for a bit of fuzziness. Yuchung: You need to write a draft. Jana: Yes that's possible. Finally we should think about TCP modifications for latency-sensitive applications. Randall: There is correlation between IW10 and this problem. Whether it's from idle or IW, this large burst can cause that problem. If you add the maxburst functionality here then things could be better. It would be interesting to see how much is IW, how much is from idle apps. Yuchung: Working on data analysis, to find relationship between burst size and loss rate. Andrew McGregor: It doesn't matter what the IW is, there will be a large number of connections launching, tail loss is a fix that's necessary. The front ends to web server farms have always been prone to TLP. ... It may be a function of buffer size. Randall: If you have a maxburst of 4 you'll find that the number of tail drops will be much less. Mirja: Because it worked in your tests doesn't mean it works for all kinds of apps. We need to have more data to see if it is a general problem. Yuchung: It's already in Linux. Mirja: That's my concern. Randall: Should be sysctrl Yuchung: It is Randall: off by default? Yuchung: on by default Randall: not good Karen Nielsen (Ericsson): we support this work Stuart: Assume server's sending to many clients, buffers are full. If you lose one of the last packets, that's when retransmits don't work .. it may be that the larger the burst is, the higher the risk is higher. Jana: at the beginning of the connection you're limiting it for an RTT (?) Chairs: I hear that tail loss probe is a relevant problem. Question: would this be another opportunity for getting a solution that has some broader support. Would be a perfect chance for the WG to come up with a new draft, joint solution, but I'm not sure if we are there yet. Not sure how to get there, but then we could think about proposed standard. Michael T: I think it may be important to work also for SCTP Karen: Great if it's also for SCTP, but we are very happy if there's at least a solution for TCP, that would already be a big improvement. draft-flach-tcpm-fec-00 Tobias Flach ------------------------------------------------------ Mirja: Why are you re-using the sequence number, not using a new one? Tobias: Because then you would have a sequence hole. Re-using it causes some issues as well, we can talk about this later. Michio Honda: Why do you need TCP-level changes, I think your stuff could be entirely done in application stuff when using e.g. Minion. Secondly, some intrusion detection systems (middleboxes) need to see correct sequence numbers. Tobias: out-of-order TCP or something like that? Seems to be a valid solution. We thought our solution would be pretty easy to deploy. Michio: but why put that all in TCP? Tobias: but then we could also do the whole TCP in user space. Jana: You are changing the TCP protocol. Michio's point was that you don't have to do that. Tobias: Yes you can do this on the application layer. Alan Ford: We've been around this with MPTCP. You can't trust sequence numbers at all. Whether this is the right solution to the problem is very much an open problem. Tobias: if we do it in TCP we have the advantage of having all the information that TCP already has. Mirja: This is quite a big change to TCP. Would be better at a higher layer. Chairs: Not sure if the outcome of these comments is still the same protocol that you suggest. Thanks for presenting, but we look forward to a more elaborate solution. draft-gont-tcpm-tcp-seq-validation-00 (no new draft) Fernando Gont ------------------------------------------------------ Chair: We look for feedback from implementors, how stacks fixes this problem. Michael S: This updates RFC 793 - we are interested in feedback ... This problem is known for years Fernando: The self-connect is a corner case Andrew McGregor: "It is fine to .. Open BSD . … Solaris, But who really cares? Michael S: In closed-source stacks we cant not check, it would be good to get feedback. Michael T: The other stacks could be checked using wireshark and packetdrill? Randall: Telling about a bug about ignoring FIN in FreeBSD Yuchung: Packet Drill is a perfect tool for checking these cases Alexander: How big is the document. Could it be an Errata? Michael: This is beyond an errata. Who is willing to review this? - reviewers: Karen Nielsen, Yuchung, Kevin Lahey ...Reviewers should look at document and post thoughts to the list before adoption. draft-kuehlewind-tcpm-ecn-fallback-00 Brian Trammell ------------------------------------------------------ Bob: where was the CE removed? Brian: we don't know if it was along the path or at the receiver. Chairs: Short on time; interesting work, good discussion on the mailing list, I suggest to continue discussion there. draft-kuehlewind-tcpm-accurate-ecn-02 Richard Scheffenegger ------------------------------------------------------ Slide 4: didn't show correctly, but it's a copy of what is in the draft Chairs: good idea to review both the requirements and this together. Bob: If this does go through, would we need the IANA registry for the urgent pointer in a separate draft or can this draft request such a change? Chairs: this is a totally separate discussion Fernando Gont: ?? Chairs: almost out of time. Next presentations were only "teaser talks" about what this is all about. Slides are available. PRR effects Mirja Kuehlewind ------------------------------------------------------ Yuchung: is it an implementation problem? Answer: Yes. There is a bug in Linux auto-buffer-tuning. Yuchung: Should we do something about burst (maxburst or something)? Yes, too. Dealing with sequence-number randomizing firewalls Christoph Paasch ------------------------------------------------------ (applause) Chairs: are you planning to make a draft? Christoph: yes, but running out of time Jana: This is fantastic. Minion (talk in tsvarea) could solve things like this. -------- End of meeting (67 names on blue sheets)