IETF TCP Maintenance & Minor Extensions (TCPM) Working Group Minutes from IETF 77 (Anaheim, California) Tuesday, March 23, 2010 1300 - 1500 ================================= WG status updates (David Borman) Slides are similar to recent status note sent on TCPM mailing list - tcp-security draft meeting Wednesday to identify those things that need discussion and others that are non-controversial which we can start quickly with. Lars may be able to organize a conference bridge. Or we could ask secretariat to do webex. dborman will ask ML. Q: Who go to session in morning and will help go through? A: A handful. - tcpm-persist draft : Dave suggests adopting as WG item and last call it to get comments. Lars: Not an exciting document, says something that is already said in RFCs. Good to clarify it if it is unclear, so don't object to it. Hum- Anyone thing we should not adopt this doc? (silence) Hum- OK? (hums) Will do this on the mailing list. Lars Eggert: One thing to note is the AD handover later today. A new IESG is coming in. They will look at DISCUSS positions of predecessors, and decide if they want to carry forward or re-review. Anything clear by end of day is gone and won't be looked at. So, clear any DISCUSS you can before the end of the day! ================================ Alexander Zimmermann TCP-LCD "long connectivity disruptions" Authors think this document is done, want to initiate a WGLC Mark Handley: Haven't read doc, but skimmed. Does this work on SYNs as well as regular packets? The concern is that if you do, and have a continuous rate of new connections, and no backoff, you could end up with a mess (incoming connections unbounded). Alexander: I think we do it with SYNs too. Chairs will issue WGLC in next couple of weeks. Ther are some lanugage fixes, and think about SYN stuff. ================================ SACK-Entry Status http://www.ietf.org/id/draft-ietf-tcpm-sack-recovery-entry-01.txt Markku Kojo This is an alternative algorithm to trigger fast retransmissions using SACK. Authors think it is "basically done", but planning to merge with RFC 3517. Jamshid: Have you talked about the case where a misordered packet comes early, and can cause an RTO? Markku: Yes, that's covered. Lars: bis of 3517 is not a work item. It is in scope, but I'm just worried about the timeline Markku: will discuss with 3517 authors. Matt Mathis: Consider thinking about optimizations if know the one segment after hole is up to snd_nxt, that is, there is no more data coming. This is a different optimization though. ================================ Middlebox Discovery http://tools.ietf.org/html/draft-knutsen-tcpm-middlebox-discovery-03.txt Jamshid Mahdavi In-band discovery of middleboxes needs a TCP option, trying to do exactly once, rather than many different times. Bluecoat has been doing this since 2007. On the mailing list, TCPM decided no interest, so this has been submitted to IESG as an individual submission. Lars: actually it's sitting with me. I talked to friends from Cisco that have similar products, talked with reverbed / similar products, talked with Citrix. A number of TCP option numbers are in use that haven't been requested/assigned via IANA. Trying to get them together on a call, enough interest to define a common option number format that new products can use. Interoperability/management gains with officially assigned number. Seems to be interest. Other vendors are reviewing the spec. It goes in the right direction, reviewing comments. May be something with other vendors just doing it, or ask TCPM to take it back, depending on outcome of private telechat. Anantha Ramiah: talked with Jamshid. generic option format is OK, but needs some minor tweaks to accomodate our option format. We can discuss offline to converge. I think this is the right direction. Joe Touch: If we had a kind everyone could use and format specficied, that would be nice. A kind that is opaque, and has vendor-specific info, should not be take up by TCPM. I'm nervous about having things in there that could affect things in arbitrary ways. We need to know: - formats - how used - how affects tcp state machine. Lars: point taken. don't think current draft ... it is not a vendor option. discussion is how is being used by vendors. this is unusual option, not e2e tcp stack option. motivation for doing: update IANA registry to marke currently used option numbers as taken. w/o proper assignments. new products should use IETF alloc number. can't ignore people using this. process hasn't been followed if desire to do right thing eventally, appreciate that. Andrew Knutsen: we tried to be good and use experimental number. so won't work for us. lars: mentioned the experimental number. had original... draft-bonica-experimental-optins ship with exp number... heard that that has become poisoned,(and dropped) so have to assign new exp option number. but it's been rasonable for firewall vendor to drop things that should not leave enterprise. Anantha: IANA request. said "on hold" then things changed and finally, dropped. so we didn't do really bad things :D Lars: cisco tried to get alloc, and IANA dropped ball (back to presentation) Known problems: ACK storm: when two connections that thought they were talking to each other (and therefore are not in synch) talk to each other on failure, then infinite ack storm. are mitigations, but.. A middlebox is an aggregator. so other problems are amplified. =============================== Reducing the Initial RTO http://tools.ietf.org/html/draft-paxson-tcpm-rfc2988bis-00 Jerry Chu Anantha: Question about recommendation to not use 1st measurement. Thinks justification for changing this should be explained in the draft. Gorry: Did you consider ECN? It also has a case where there may be a loss that is not congestion related; don't slam down IW in this case. Alexander Zimmerman: Do you plan to reduce the minimum RTO also? Jerry: they are separate issues. Alexander: Introduce a short discussion of this in the document? Jerry: Promised Mark and Vern not to side track into other stuff; it is a separate effort Alexander: The reader might ask this question why this is not also being reduced? Lars: The draft should explain why this is a separate issue. Jerry: Will revise the draft, and mention separate research paper Markku: Effect on slow links? 128kbps with 10 IW will have a RTT of longer than 1 sec. Jerry: We recognize that 2.5% have initial RTT of more than 1 sec. Does 10 IW make this worse? Gorry: The problem is that affects a smal number of people very hard; satellite community. Joe Touch: Important to keep in mind that HTTP is not the only use of TCP. 5% for you might be 90% for someone else. Jerry: Harm is at most spurious transmit of a few SYN packets. Lars: Several proposals all being evaluated separately, but they will be combined so they need to be evaluated together. Combinations might have unintended effects. ================================ Increasing the Initial CWND http://www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt Jerry Chu 1.5 hrs in ICCRG discussing this topic this morning. Discussion and hashing of concerns. Want discussion on next steps. Joe Touch: You talked about average size of the page. But it is the first page that matters. Do you have statistics on that? Jerry: Will try to get that number for you. Joe: that would be more useful thatn what you show. assume non-brain- damaged world. first one javascript. a lot of them have flash as well Jamshid Mahdavi: Last thing... congestion collapse is unlikely. Congestion control is out of protocol and in hands of the user. Clicking "reload" implies more data going out. The user doesn't have builtin exponential backoff, in fact, perhaps the opposite. Use resets to measure reloads? Jamshid: but in your tests, didn't get to congestion collapse. If you get to the point where snowball started, users may drive it. Yoshifumi Nishida: How about congenstion window after idle period? A: We are open to suggestions on this. How much HTTP persistent connection use? Jerry: Would like to measure but don't have the data Nishida: In HTTP1.1 can reuse. Jerry: Don't know how much it is used. Joe Touch: I'm reluctant to take this on as a WG item given that we don't know what we are going to. What's the benefit vs. what's the impact? Have some unanswered questions that the answer to which determine whether we should do this. We need more information. What's the impact of 5%? and what's the target number, if it's 6. 10 packets or 10K? Jerry: willing to limit to 10 packets. Joe: what's the benefit vs impact. have a couple of unanswered questions... hesitate to say, yes doing it, and roll around and come back with 5 or 6. need more info. Jerry: We really need volunteers to help! Want WG to work on this to get more help getting data. one advantage of WG doc is visibility. "Google has limited resoruces" [laughter], could use help. Zhen Cao: How this work relate to 3G and wireless networks? A: Tried to mine data to separate 3G. Have mobile networks -- seem to benefit more because of the larger RTT. Anantha Ramaiah: Comes across as an aggressive proposal. But we should do something about this. Need a table or column that talks about each proposal and what the problem is. Have we evaluated these other proposals? A: We have evaluated a lot of other proposals. Some require router support; out of the question for near term. Others are even more aggressive or require pacing. Q: Better to put these in crisp form in the document. BIC or QS with router support, how far could we get? Readers will need 100 days to review the draft to pull out all of these references. Jerry: Assure this is one of the most conservative of the proposals. A: 15% of traffic uses IW of 4 or higher. Q: Can we make this a config parameter? A: Person from Africa concerned about this this morning. Can mitigate this by configuring laptops with advertised receive window much lower. Joe Touch: Your concern is that there is no way to negotiate; there is a way which is using the receive window. Q: Can we get this in a gradual manner somehow? Q: Another question: You said fast retransmit? What about early retransmit? if early retransmit is there don't need it. small benefit. Wes: Two more presentations. Before we finish... WG showing a lot of interest. ICCRG showed a lot of interest. Will discuss this more. Don't think the WG is ready to decide today whether to take this on. Jerry: Would like to have the WG adopt this as a work item. Lars: Actual work is minimal. Argument is where the work is. My take away from this is that there is a lot of interest here. Does the working group want to spend a lot of the time in the meetings and mailing list on figuring out if we should do this? I think they do. David Borman: Census of the room. Do you want to continue discussing this topic within the context of the TCPM working group? Tim Shepard: Wouldn't ICCRG be a better place since it is quite researchy? Jerry: I disagree Tim: There is a research question here which needs to be answered. It is a hard question which will take several meeting cycles before I can figure out what I think. Dave: How many people were at ICCRG? Most people raised hand. How many people here say we should continue discussing somewhere? Most raised hand. Final question: Here or ICCRG? speaker: regardless will be overlap. ICCRG tends to look long term Jerry: Prefer here, want this audience involved. Joe Touch: Don't have a suggestion about how to achieve this. Is it safe to do? That is what this WG is about. Because this is just a change of a parameter, and not a new algorithm it makes more sense here instead of ICCRG. Lars: Like the way the meeting was set up with ICCRG first and tcpm second. Wes should coordinate with himself to do this again in the next few cycles. Dave: Do people feel it works well to hahve the discussion in two parts. Most raised hands. Will cut off discussion to get to remaining talks. Matt Mathis: There are globally several billion people whose window is at most a few packets. Perhaps a separate problem to think about providing good service into those areas. Dave: Moving forward since Wes is on both WG and I'm on this one, we'll discuss with Jerry what should go on in both WG. Will try to plan better next time. Tim Shepard: I object to repetition of the content. Could have a joint meeting. Lachlan Andrew: Suggest TMRG WG. A: not a modeling problem ============================= TCP AO NAT http://tools.ietf.org/search/draft-touch-tcp-ao-nat-01 Joe Touch Brian Wais: Comment related to way forward. If there are two sides, one side doing NAT and the other isn't, can they detect that? Does it need to be described more? Can both sides know if they are behind a NAT? Adds uncertainty to interoperability. Joe: Don't turn the option on if you don't want to work behind a NAT, but otherwise you should turn this on. If you believe what you are doing could be behind a NAT, turn it on. Brian: Peer doesn't know what the other side thinks. If default will be behind NAT, this lowers the entropy Joe: Both sides need to be willing to say they will be willing to work with the lower entropy. This is experimental because we don't know if that will be useful or not. Brian: put that discussion in the document Eric Rescorla: I don't have a problem with experimental. It isn't an entropy issue, but something else with sharing of keys. Joe: Can you give text? Eric: Yes. Anantha: Really want to know the need for this document. BGP and LDP are only users of MD5. Want to know use case. No one with BGP has talked about this. There's been a request from another working group; this information (use case) should go into the document Joe: Is it going to be a WG document or not? It sounds experimental either way. Wes: We have to poll mailing list too. ================================= TCP AO Rekeying http://tools.ietf.org/id/draft-duan-tcpm-tcp-ao-rekeying-00.txt Terry (Hongyan) Wang, Duan Shili, or Yinxing Wei Eric Rescorla: Unfortunately this mechanism won't work. Not important for the sender to change his key, the receiver must disable his old key. This doesn't do anything useful as far as I can tell. When I discover key is compromised, I will call you to cut off the old key, and as soon as we both know, we will start using the new key. Dont' see why it's helpful for sender to tell receiver. Speaker: but we want to chagne the key on the fly. it's what existing mech does. Joe: no it doesnt. The existing mechanism says when reciver is ready to get key, and doesn't drop things on floor while changing keys. specific that protocol not intended to change key. that is a key management protocol, but out of band according to doc. If you find out key is compromised, last thing want to do is to signal with that key that it's bad. You want to coordinate w/other end out of band. Speaker: why not? Joe: specific intent, only to have you not drop things when key on one side and not the other side. that's the purpose of mechanism. not designed ot deprecate keys. Speaker: The current mechanism allows the sender and receiver to control the incoming key, can't change the outgoing key. Joe Touch: Confusion. The existing mechanism does not change the key. Tells you when the receiver is ready to change the key but doesn't change it. There is nothing in the protocol that can tell the other end that a key has been compromised You have to tell the receiver to change the key but you don't do that in the protocol AO. The purpose of the handshake is to make it so that both guys on both ends don't need to hit CR at the same time. The protocol tells you what it's okay to start using, but there is nothing in the protocol that says when to stop using a key; this is by design. Eric and Joe: Let's take this offline Eric will sit down and walk through scenario with authors after meeting Joe Touch: short announcement: TCP AO has cleared all discusses.