TCPM meeting at IETF-83, Friday March 30, 0900 -- 1100 ------------------------------------------------------ Chairs: Michael Scharf Yoshifumi Nishida Pasi Sarolahti Note takers: Richard Scheffenegger Michael Welzl * Agenda bash & WG status (5 min) chairs No comments * TCPM Rechartering discussion (10 min) chairs Lars Eggert: the wording could be improved to make it super clear that e.g. only SCTP things that have something to do with things we do here fit in here. Agree in general, language about algorithms vs. protocols should be improved. Bob Briscoe: text implies that Michael S.: Agree about algorithm, text needs to be more explicit around that Matt Mathis: a few changes led to changes to the API as well. The application and upper layers must at least be mentioned somewhere. Michael S.: propose text, discuss on mailing list Lars: super mini suggestion. it should be "consensus of the approval of the working group..." in the last sentence. Michael S.: ok Bob: is there anything we ought to say in the charter about what "minor" means? what happens if it's not minor? Michael S.: that's not clear - if it's not minor, it needs a different WG. but how to define "minor" is hard. Wes George: the definition of minor is: whatever the AD doesn't squawk at. if you need a recharter or a new WG it's not minor. * TCP Fast Open (15 min) draft-ietf-tcpm-fastopen-00 Jerry Chu (slide 6) Wes George: perhaps there is a need for an additional i-d or updates to existing drafts to address this point (of changing IP addresses on certain NAT boxes). I'm also not certain this is a problem - move to IPv6, the problem goes away. Bob Briscoe: the problem doesn't go away because of hand-overs, you cannot guarantee having the same IP address Gorry Fairhurst: it oscillates between IP addresses, is that right? Jerry: why oscillate? Bob: I guess if you go back and forth... Andrew McGregor: Its wireless - not stable even if nothing moves Mirja Kuehlewind: Old connect in old cell, new connect in new cell, lot of effort Markku Kojo: in cellular the IP address does not change upon a handover Jerry: there's this host identifier stuff... we've been thinking hard: do we really need a cookie? But only a cookie can mitigate the problem. It's not safe to not use a cookie. Bob: IP address change may only be a problem between different operators, not within the same operator Piers O'Hanlon: can't you make this IP-address-independent by using an identifier on the cookie Matt: When using experimental options we have Chicken/Egg problem, danger that experimental option goes into the wild. Should write an ID to describe the lifecycle of the option. Missing discussion around lifecycle issus of experimential options. Gorry: It seems to be better to ask for a real option for this. seems to me it would be better to just specify this, we've been discussing this idea long enough, better to get something done. Matt: There are people who want this functionality right away on their cell phones. Such a document could be a good example of a first document describing this kind of thing. Need to write down that being incompatible doesn't break this particular one. * Increasing TCP's Initial Window (15 min) draft-ietf-tcpm-initcwnd-03 Jerry Chu Gorry: I like it, I think it will help a lot of things. However, I'm not happy with an experiment on the whole Internet unless we have a scheme that backs off if the IW10 is too much. Jerry: I personally agree that philosophy, but there are some reasons why people would not enable this, if they're into tuning. Jerry: the question is about system-wide parameters. Gorry: The application may be running somewhere else (e.g., P2P between two nodes on slow links). It may be fine, it may move. I don't like the idea of telling users to tune your stack depending on their network situation. My proposal is: if you see loss with this, then don't use it on the next connection. Jerry: that is like Joe's draft? Gorry: a bit, but I don't like planning beyond IW=10 for IW=20 etc. Randall Stewart: I think this is good. I get nervous when I think of web servers opening 60-70 connections, in particular in combination with the cookie. If you combine these two things your congestion control is completely disabled by this. Matt: I agree with a part of this. They will figure that problem out and fix this. Randall: is the Internet going to collapse in the meantime? Matt: it already is collapsing with buffer bloat. Fair share may not be 16kB Gorry: Evidence that this goes wrong. Drops packets when buffers overfill. Lars: I agree with what Gorry said earlier and partially with what Randy said. We should agree to do this, but also on when and how to do this. e.g. if I have a connection to one IP address, instead of the next connection going for IW10, that next connection could "borrow" from that IW. Gorry: if we get this right, the backoff mechanism wouldn't trigger very often Matt: (missed: something about removing the motivation for opening multiple connections) Lars: SPDY was the only proposal that advocates using only one connection over HTTP, so I like that direction (with future HTTP development) Jana Iyengar: when we send a burst of 10, it's going to be buffered somewhere or go through. If it hits a buffer, it's much more likely to hurt itself than anybody else. It only works because buffers are deep. What about buffer bloat? Jerry: the question is where the bug lies. TCP developers aren't to blame for buffer bloat. Jerry Chu: ready for last call? chairs: concerns have been raised, we think we need a new version before that. Lars: do people say we should just do IW10, or do we need some kind of safety mechanism added? We need to make those decisions quickly. Jerry: concern about the safety mechanism. We picked 10 to be safe, it's simpler, otherwise you wouldn't see an implementation. Michael Scharf (chair): the draft has a safety mechanism which operates on a slow timescale. The question is if we need something on a shorter timescale. Nandita Dukkipati: We've had this discussion in the past. My takeaway was, let's do something simple. And there is a safety mechanism, if you experience loss, you'll use less in the second RTT and that is maybe sufficient. Jana: I agree, the procedural document should probably be separate from this. Experiment is where IW=10 becomes an issue Piers: in the BSD kernel there is a cache that does these things anyway, it caches ssthresh, etc. Gorry: we need to do this on the list * IW10 in Low Bandwidth Environments (15 min) (related to draft-ietf-tcpm-initcwnd-03) Hagen Paul Pfeifer ?: did you do test with asymmetric bandwidths? Hagen: yes Jana: did you say that the queue length was infinite? How do you see drops? Hagen: there were no drops, just spurious timeouts. The initial RTO is 1 second. Mirja: you said that there's no negative impact but also no significant benefit in the other case. Hagen: sometimes, depends on RTO Jerry: no benefit when there's a really bad situation. if you're interested in more details we have published this in the Beijing IETF. * Survey of Security Hardening Methods for Transmission Control Protocol (TCP) Implementations (15 min) draft-ietf-tcpm-tcp-security-03 Fernando Gont Matt: I've spoken in the past on the mailing list in the draft and had very negative words about it. From a security perspective, undefined fields are an opportunity covert channels. From a protocol design perspective, these fields are opportunities to improve the protocol. We do not want to freeze TCP. Fernando: this has been changed in draft. Matt: it does that but in a way that makes it easy to read between the lines. The document has gotten better. Fernando: if there are any such instances remaining, that is not the intention. e.g. it says "if it is an unknown option, don't drop it because the protocol could not be extended" etc. Lars: Split to 3-4 new smaller, but standard track documents, but the total volume of the work hasn't changed. Fernando: volume has changed. Lars: This document has gotten shorter, but now we're growing the other documents. I'm still frightened that this is basically a too big item for the WG to take on. I don't think we have the cycles for this kind of work. I don't see us finishing this. Tim Shepard: introduction of the document seems completely wrong. at some point I realized that this is too long for me to read, I then did random sampling, checking about 10 times in it to see if there is something worth reading. I found nothing. Maybe there is value in this document, but given a statistical approach of looking at it, then if there is value, it cannot be much. Yes, there are many references, but I think the high level bits of my conclusion are pretty robust. I don't think this is worth the time of the group. Bob: if this is going anywhere, it would be useful to give security people something they could do. First you need to have a sort of alarm etc., only if that happens a lot, then you do something. So you need to have some intelligence or intrusion detection before you drop. Anantha Ramaiah: good document, but should be shortened. Adding robustness for TCP is very important. The problem is just the structure of the document, it needs some scope. Fernando: actually I think that you find lots of firewalls that drop things they shouldn't, and that document is a good chance to argue the other way around. But that kind of stuff is already there and deployed. Michael S.: This is very controversial document. Chairs suggest that Fernando works out a new document until the next IETF, that will be reviewed strictly, and then we decide if to drop or continue. If there are objections, say now. * Proportional Rate Reduction (5 min) draft-ietf-tcpm-proportional-rate-reduction-01 Matt Mathis Jana: I have read the document and think it's wonderful. Andrew McGregor: I support * Laminar TCP (15 min) draft-mathis-tcpm-tcp-laminar-00 Matt Mathis Anantha: I see a lot of similarities between this document and the previous security document. I don't know how you want to update 60 RFCs. I agree with you a little bit, but at the same time I think that the changes are very local. Matt: it's not clear that this document should really update 60 documents. The first round certainly has to be experimental. Really changing the standard is pretty far down the road. Lars: I think this is pretty cool, I'm amazed that this is even possible. But it's probably not a minor modification. We may actually need a new WG. Matt: if that's the proposal, I'd rather do it in ICCRG Gorry: I haven't read the draft but what I've seen is quite exciting. We have a draft in tsvwg which is suggesting some similar things. Randy: SCTP and DCCP also depend these 60 documents. You need to have something that covers all 3 major transport protocols, not just TCP. Matt: I suspect that some of the things SCTP does is already closer to this proposal. Randy: partially. I really think we need to have a separate WG spun out just to do this. ICCRG is not the right place because this is not research. You're really changing the standards. Wes George: I agree that this doesn't fit in ICCRG, because I want to see this move forward. We at IETF are not good in doing revolutionary stuff. I don't want to like to see a new WG as much as I'd like to see the existing WGs update their charters to incorporate this. Involve new people in existing WGs on this. There are lots of other places where stuff like this goes on. Jana: While I think it's true that SCTP's cc. is probably closest to Laminar, it's not yet there. It's half-way. About the issue of changing 60 RFCs, I think this is not yet the major change, it's much more of a significant change to the way of thinking about TCP congestion control. Matt: we haven't really checked through the 60 docs to check how many realistically need to be updated. Many of the documents are obsolete. Michael W.: This is not a research, does not belong to ICCRG. * NAT functional extension for address resource restricted environment (15 min) draft-naito-nat-resource-optimizing-extension-00 Kengo Naito Magnus Westerlund: you failed to open a TCP connection because you didn't get a port on the NAT? Kengo: you get a connection but TIME_WAIT prevents using the port again Senthil Sivakumar: Proposing CGE / CPE device? If you overload NAT ports, beaks RFC 4787. It can be done but it breaks applications Kengo: but implementations now do that Wes George: use IPv6 chairs: not clear whether this is really in scope of TCPM * TCP option space extension - a brief discussion (10 min) ftp://ftpeng.cisco.com/ananth/draft-ananth-tcpm-tcpopt.txt Anantha Ramaiah Lars: do we have a proposal that works? Anantha: Main problem is that middleboxes get confused Tim: this is an important topic. I'm optimistic. But we need to find an escape mechanism of some sort on a single SYN assert that you'd like to do something more than the server understands. I didn't see any new ideas that gave me hope in your draft. I found 80 unused bits in the SYN. I'm hoping that someone comes up with a good proposal. Randy: what imprisons TCP is the same thing that keeps SCTP etc from deployment: the NATs and middleboxes in the world drop things they don't like.