From tcpm-bounces@ietf.org Wed Jan 02 14:07:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA8wF-000072-Mb; Wed, 02 Jan 2008 14:07:39 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JA8wE-00006x-TX for tcpm-confirm+ok@megatron.ietf.org; Wed, 02 Jan 2008 14:07:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA8wE-00006p-0E for tcpm@ietf.org; Wed, 02 Jan 2008 14:07:38 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JA8wB-00081s-Bp for tcpm@ietf.org; Wed, 02 Jan 2008 14:07:37 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id m02J7XQx018330 for ; Wed, 2 Jan 2008 11:07:33 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 9BD2713B43CE for ; Wed, 2 Jan 2008 14:07:27 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 547C93263F1 for ; Wed, 2 Jan 2008 14:06:37 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: And We Danced MIME-Version: 1.0 Date: Wed, 02 Jan 2008 14:06:37 -0500 Message-Id: <20080102190637.547C93263F1@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 312bb437839230b5894c6b1686dbca1d Subject: [tcpm] Matthew J Zekauskas: TCPM minutes, IETF70, edited version X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1496189814==" Errors-To: tcpm-bounces@ietf.org --===============1496189814== Content-Type: multipart/signed; boundary="==_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --==_bOundary Content-Type: multipart/mixed; boundary="=_bOundary" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Matt sent these to us, but then noted he should have copied the list. Please send corrections soon. The final version is due Friday, I believe. allman --=_bOundary Content-Type: message/rfc822; charset=us-ascii Content-Disposition: attachment; filename=10781 Content-Description: forwarded message Replied: Wed, 02 Jan 2008 13:59:59 -0500 Replied: "Matthew J Zekauskas " Return-Path: matt@internet2.edu Delivery-Date: Wed Jan 2 12:56:45 2008 Return-Path: X-Original-To: mallman@localhost Delivered-To: mallman@localhost.icir.org Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 4B42713B3E88 for ; Wed, 2 Jan 2008 12:56:45 -0500 (EST) Received: from mailhost.icsi.berkeley.edu [192.150.186.11] by guns.icir.org with IMAP (fetchmail-6.3.8) for (single-drop); Wed, 02 Jan 2008 12:56:45 -0500 (EST) Received: from pork.ICSI.Berkeley.EDU (pork [192.150.186.19]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m02HuBfY029945 for ; Wed, 2 Jan 2008 09:56:11 -0800 (PST) Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id m02HuAWA016880 for ; Wed, 2 Jan 2008 09:56:10 -0800 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id BA7B047C6D; Wed, 2 Jan 2008 12:56:08 -0500 (EST) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04615-08; Wed, 2 Jan 2008 12:56:08 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 0FCED47C32; Wed, 2 Jan 2008 12:56:08 -0500 (EST) Message-ID: <477BD036.5070208@internet2.edu> Date: Wed, 02 Jan 2008 12:56:06 -0500 From: Matthew J Zekauskas User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Mark Allman , Ted Faber Cc: Matt Zekauskas , Joe Touch Subject: TCPM minutes, IETF70, edited version X-Enigmail-Version: 0.95.5 Content-Type: multipart/mixed; boundary="------------020407040304070003060209" X-Virus-Scanned: by mail.internet2.edu virus scanner X-ClamAV: OK X-SpamProbe: GOOD 0.0000097 e09de7c0aedab0143727a18e4ad60490 X-mallman-sequence: mallman This is a multi-part message in MIME format. --------------020407040304070003060209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Here's a version of the TCPM minutes I think is suitable for posting, and getting general comments... I've attached it as text. Joe: the audio cut out on the discussion that begins "There was a question about the use of option types" -- I'm not sure fully caught the gist of the discussion, so you might want to review it. Actually, I'll duplicate it here: There was a question about the use of option types. Joe said we could use a single option type, which the security association would encode (if you didn't have the right algorithm, you could not verify the stream). The reason for multiple option types is that it is clear when we change the MAC; it's really mostly for the human beings, so that they note we are switching to something completely different. Sandy noted that it's also easier for humans to write the implementation. Joe said that it wasn't strictly necessary, though. We are not going to use the MD5 hash as a viable algorithm for TCP-AUTH. Thus, the hash would never generate a result that would collide with something else. Thanks, --Matt --------------020407040304070003060209 Content-Type: text/plain; name="tcpm-minutes-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tcpm-minutes-02.txt" TCP Maintenance and Minor Extensions WG (TCPM) Tuesday, 2007-12-04, 17:40-19:50, Salon 2 IETF-70, Vancouver, BC, CA =============================================== This session was "guest chaired" by David Borman and Lars Eggert. The chairs, Mark Allman and Ted Faber, listened to audio and were on the Jabber session. Matt Zekauskas acted as scribe. AGENDA: 1. WG Status + Agenda bashing (10min) 2. UTO scraps (10min) 3. ECN-SYN WGLC (5-10min) 4. Advancing F-RTO (10min) 5. Acknowledgment Congestion Control (10min) 6. TCP Authentication Option 1. WG Status + Agenda bashing (10min) (see slides) Lars opened up the meeting. There are two working group last calls underway: 2581bis and ECN-SYN, which run until 21-Dec-2007. Please comment. Tcpsecure has been delayed waiting for an applicability statement by the authors for discussion in the working group. The statement should indicate which mechanisms that the document proposes are suggested to be implemented by TCP (or which TCP implementations should consider implementing the proposed remedies). The TCP-AUTH design team has finished. They have come up with an initial proposal to obsolete TCP-MD5. The team has been running for 6 to 9 months; the working group now takes over. (This is the subject of the last agenda item.) The draft is pretty solid. There are a few remaining issues, but nothing large. We expect to move it quickly through the working group. Work has been started outside TCPM for algorithms and keying components. There will be a discussion in the security area group (SAAG) later this week. 2. UTO scraps (10min) draft-ietf-tcpm-tcp-uto-08.txt -- Lars Eggert There were no slides for this item, as Lars just wanted to call attention to the current state. This draft is in working group last call. There has been a revision posted that Fernando and Lars believe addresses all comments. If you commented, please check and see if you agree. If there are no further comments we will end WGLC. Magnus will be acting as AD for this draft, since Lars is an author. 3. ECN-SYN WGLC (5-10min) draft-ietf-tcpm-ecnsyn-03.txt -- Sally Floyd This draft, too, is in WGLC. See Sally's slides for a summary. One issue that was left open for a year was how to respond when a SYN/ACK is marked with ECN. Should we decrement the congestion window immediately or wait one RTT. They finally did some simulations, which was reported on at the last IETF. The current version addressed issues in raised in the meeting. There was also some general editing. There is one open question from WGLC comments. This was raised by Bob Briscoe (who showed up while this point was being made during this meeting). In Section 4, there is a subsection on backwards compatibility. Old (current) implementations (Linux, Windows (which is not enabled by default), Mac OSX (again not enabled by default)) ignore the ECN mark, which is what the current standards say. The problem is if the originator, who sends the SYN, doesn't understand ECN marked SYN/ACK, with a new responder -- and the SYN/ACK is marked in the network. Does the originator ignore the marking or tell the other end point. Current implementations will ignore. A new implementation will "do the right thing". The draft did not add negotiating capability... this is a transient backwards compatibility problem. The authors felt it was not so terrible; few are using it now, and if the sender doesn't hear about it; the sender will hear eventually on data. This seemed a "ok to live with" problem. Bob disagreed during WGLC. What do you do? One could use one of 4 reserved flags left in the TCP header. The flag would be only meaningful in SYN. [option 2 on slide] One could use an ECN-SYN option, but Sally did not think that would be a good idea. So, Sally would be happy going with the reserved flag (since it is only meaningful in SYN, and could be reused later) or ignore [option 1 on slide]. What did the group think? During Sally's explanation, Bob arrived, and commented that he would generally be happy with 1 (ignoring the problem), but felt we should better understand the problem before deciding. He could see problems with short flows. He was not as happy with using one of the reserved flags for this transient condition. Gorry Fairhurst asked Bob to clarify the bad situation -- is it when the whole transaction is just 4 packets? Sally replied first, saying yes, that's that's the bad situation, if servers are old and marking the SYNs, and there are lots of short transactions. This could be unfair with respect to others that did not use the ECN marking. If the endpoints that use ECN have all their packets get through, and those that don't have their SYN/ACK packets dropped, and thus timeout. Bob stated that a quick back of the envelope calculation showed that something like 70% of objects are served in one initial window. If the SYN/ACK is ECN marked and the receiver does not understand, then the sender never responds to congestion, and this is bad if there are a large number of flows. Mark Allman commented that the cost to solving the problem is too high. Sally remarked that she didn't think it warranted study for another year. David Borman noted that if you choose option two (an additional TCP flag) you are stuck with it forever. If you ignore the problem, it goes away once the transition is over. Unless severe problems crop up, thinks ignoring the problem is the right way to go. Sally commented that it is easier to upgrade web servers than users, and web servers that could be problem. Bob disagreed, in that the upgraded web server with lots of stupid old clients is where the problem comes up (since it's marking the SYN/ACK). Sally agreed, and said one factor in favor is that the old behavior is not enabled by default. If this comes out after a large release that enables it, then we might have a problem. Lars stated that he's leaving it to the real chairs to declare consensus: please discuss on the list. 4. Advancing F-RTO (10min) draft-ietf-tcpm-rfc4138bis-01.txt draft-kojo-tcpm-frto-eval-01.txt Markku Kojo presented the case for advancing F-RTO to proposed standard from experimental. See slides for background. The revised draft added back enhanced SACK, which was removed in -00, because the authors discovered that most implementations do use it. There is also a clarification of multiple timeout behavior. The main question to this group: is it ready to advance? The authors think there are strong arguments for advancing the specification; there is a wide base of independent interoperable implementations. Lars noted F-RTO has been experimental for a long time; there is a desire to move it to proposed standard. There are lots of implementations. He wanted to get a sense of the room if people supported advancing the draft. Sally noted that she has not followed it in great deal lately, but it seemed reasonable to her. Lars said his personal take was that there is a very strong show of support for this, given the number of implementations that use it by default. In his opinion it has already passed the bar for full standard, and it should be easy to go forward. Mark Allman thought personally it should have gone to proposed standard to begin with. Ted agreed. Please comment on the list. 5. Acknowledgment Congestion Control (10min) draft-floyd-tcpm-ackcc-02.txt --Sally Floyd. Sally presented acknowledgment congestion control, which is something she has been working on. It is "mostly specified"; there have not yet been any simulations. The question here is if it looked like a reasonable item for the working group to take on, targeted for experimental. There is one slide on what's there; basically if there are lots of lost ACK packets, use a higher ACK ratio. The sender uses byte counting and rate-based pacing. There are lots of changes from the last revision. The use of SACK will change from REQUIRED to SHOULD, most likely. The big possible complication is what happens if TCP skips sending some ACK packets, or a middle-box suppresses some of them. There are many proposed mechanisms, but it is not clear if any have been implemented. the problem is that if ACKS are skipped, the sender doesn't know if they were dropped or not sent. What can we do? 1. receiver could say, I will not skip ACKs if using ACKCC 2. receiver could use a TCP flag to tell the sender that it is sending aggregated ACKs. Sally noted that she was not asking for a flag today. Simulations and other evaluation will start in January. Sally asked if there were any comments... did the group feel if this was baked enough for the group to take on as an experimental specification? And if so, what kind of experimental -- how cautious should we be in the advice to implementors paragraph in the abstract. That really would have to wait for the evaluation. Lars asked who had read -- a couple, one of which was the co-author. Gorry asked if he could ask a question without reading -- how does this draft relate to RFC 3449 from PILC, relating to asymmetry. Sally said that she thought she looked at it (a document by Hari Balakrishnan over lunch; that document cited a bunch of proposals and related work. This document could be thought of as a successor to that one, and cites it. Hari had his own proposal that wasn't so much highlighted by that draft/FRC; it was presented in an earlier paper. In that proposal, all ACKs were ECN capable, and the sender and the sender would detect the loss of an ACK packet because it was ECN marked; it wasn't trying to detect dropped ACK packets. The proposal in this document is more general and robust than that one. Gorry said he was thinking more about the case in 3449 where middleboxes were considered. (There was some confusion if Gorry and Sally were talking about the same document or not; I believe Gorry thought so.) What happens if they reduce ACK rates? Sally didn't know off-hand, but it was one of the things that Hari's draft talked about (using middleboxes to reduce ACK frequency); she thought this draft's technique should be much better. Mark Allman commented that there was work in TCPSAT on this issue as well. Over the next few weeks Sally wants to hear on the mailing list if this draft should become a working group document. 6. TCPM Authentication Option draft-ietf-tcpm-tcp-auth-opt-00.txt --Joe Touch Joe Touch explained the input, a bit of process, and the results of the design team looking at TCP MD5 replacement options. As input were the candidate drafts for updating TCP MD5, and a draft from Steven Bellovin on the security requirements for a TCP MD5 replacement. The output is the current TCPM I-D. As part of the work, however, the group updated and augmented Bellovin's requirement document. The new list is summarized and addressed in the TCPM I-D. One question for the group would be should we move forward with two documents (the TCP Authentication Option document, and a requirements document) or just one. Joe also summarized the key decisions of the team (see slides): * Use a new option type, as it is both safer and easier. A "Key ID" is available for use during long-running connections to easily allow rekeying. It is optional, and intended to be used for the short period where there could be key overlap. * Do not directly support NATs, as they do what this option is designed to detect. If you must use a NAT, tunnel TCP over another transport protocol -- which is what IPsec does. * It is optional to say if TCP Options are authenticated. There are various boxes that munge them, and you may want to detect this (it is again in some sense the attack that TCP AO is designed to detect). However, there may be cases where it is desirable to disable them. This is another place where the group needs to make a recommendation on how to go forward. * 8 bits of key space should be more than enough to support all the keys a single connection needs at a given time. * The draft does not specify which algorithms should be used. That's for the security area, which has the expertise, to help us with. We just want two that are mandatory to implement, so there is backup if one is cracked. * Authenticate before TCP processing. The temptation is to be able to drop a packet early. However, it is possible that any packet you process might update a TCP action -- like reseting a timer or duplicate acknowledgment processing... so you need to check the validity before processing. * The draft is agnostic with respect to key management. There should be some external key management solution. * You cannot start a connection with TCP-MD5 and then switch to something else. The existing TCP-MD5 specification does not allow it. However, the new TCP AO system could include support for MD5 for backward compatibility. [The draft currently recommends this.] The group decided to start with draft-touch-tcp-simple-auth and modify that, since it required the least amount of changes to match the requirements. It was updated to reflect the key decisions above, and address Steve Bellovin's issues. It has a TCP Security Association Database (TSAD) like SAD in IKE. Joe then went on to show a summary of the proposed algorithm, including some packet headers (see slides). There were some things the design team deliberately left out. * In-band key negotiation. The TCP header space is not big enough during the initial three way handshake. * Replay protection. TCP provides that in the transport layer. Between sessions, don't re-use the key; this is an additional requirement. Use IPsec if you want to maintain keys. * Key synchronization. You don't want to deal with packet reordering or anything else, so the KeyID was introduced to allow you to choose the right key during rollover. Paul Hoffman asked a question about re-use of keys. He remembers a discussion, perhaps in Dallas, where a desired use case is that people use passwords. Here you couldn't use the same password twice? Joe replied that in that case, the password would not be the sole input to the session key. This is part of key management; even with manual keying, you don't re-use per-session keys. Paul asked that in the case of a password, you would not just use something read over the phone; Joe replied again that there are techniques to generate a good session key, and he thinks we can do that. What do you lose if you do allow reuse? You are encouraging use for long periods; you could have an attacker take some material from an old connection and put it in a new one. Paul understood that it was "bad hygiene". Joe said that non-re-use is a SHOULD in the current document; they were thinking of allowing explicit overrides for some cases. Paul said he was worried that it's not necessarily clear when the session changes. Joe noted that if you have a TCP session, an endpoint can go away and return, and TCP would continue to accept data with the same key. In any case where the connection closes or aborts or restarts, the connection should have gone into time-wait, and it should be noticeable, and yes that's when you would use a new key. If that is not clear in the document, it could be improved. Ted commented on Jabber that the term session is misleading. Joe means TCP connection lifetime which is well defined. There was a comment that replay was the only issue; any of the new MACs is strong enough to run for a long time. So, the next step is to get feedback from TCPM. Section 1.3 has the open questions list. Please ignore for now errors in the table of contents and numerous typos. In addition, there is a joint discussion this week in SAAG on key management and algorithms for TCP-AO. Please participate there. Sandy Murphy said that there was at least one point in the document where it states that key re-use MUST be prohibited. Given the several comments here, and the comments in the design team on key re-use, Sandy expected this was an area that needs some attention by the working group. If there is replay possibilities between the same source and destination, one of the ports should change. Joe noted that after time wait, TCP can re-use ports, however. One of the most dangerous attacks has to do with injected SYN packets; if it is accepted, it will abort the connection. Lars noted that the algorithms will be discussed in the Security area (SAAG) on Thursday. It would be good to get input from SAAG on keying -- understand if the document is going in the right direction, or is completely wrong. Please read and comment. Lars called for a two part question for the room -- to get a feel for the room, not deciding anything. Hum if you think that modulo some fixes and clarification this document is what eventually will be put forward as a replacement for TCP MD5. [high-moderate hum] If you don't think this is the right base, and would like something else [no discernible hum]. Lars felt that this was a strong indication that this document is a TCP MD5 replacement candidate. Paul asked for clarification on what SAAG would do regarding helping with key management and MACs. Joe said that the design team felt that there was little expertise here, and we should request input from where the expertise was -- SAAG. There didn't seem to be a particular working group that fit, so considering it in SAAG and TCPM seems to be the right choice. As long as two authentication algorithms are recommended, that would be fine. We would also like them to be reasonably fast. A question was relayed from Jabber: Ananth asked why does the document specify that it obsoletes 2385, but it still allows co-existence with 2385? Ted Faber stated that he thought it would obsolete 2385; Ananth clarified that it allows MD5 to continue to exist, though. The document is intended to be backward compatible. Sandy asked if it is an "obsoletion" if we are proposing that the two might work at the same time? The RFC editor allows only a small subset of verbs. "Obsolete" is the only one that fits. It is not updating, and it is not deprecating. Paul noted that "obsoleting" means deprecating the old document immediately. Joe noted that it should be deprecated for a number of security reason. Paul clarified that it means deprecating on the day the new document is published. Paul thought that this is similar to a discussion he had about SMIME; we shouldn't say obsolete. The right thing to do is not obsolete the document, but have a separate document to deprecate or make historic or obsolete TCP MD5. When that one passes, TCP MD5 will fall off the acceptable stack. Lars felt that Paul was right with respect to the verbs. Paul said that when something says deprecate, it means "change status to obsolete". Joe said that the design team intended to make the old version obsolete, but not completely prohibit to support legacy code. Tero Kivinen thought we should look at IPSEC as an example. IKE2 obsoleted IKE1, yet most everyone continues to use IKE1. There are even RFCs out after IKE1 was obsoleted, supporting and adding stuff to IKE1. The working group should get a better indication of what the names mean, and indicate which one we would like to use. There was a question about the use of option types. Joe said we could use a single option type, which the security association would encode (if you didn't have the right algorithm, you could not verify the stream). The reason for multiple option types is that it is clear when we change the MAC; it's really mostly for the human beings, so that they note we are switching to something completely different. Sandy noted that it's also easier for humans to write the implementation. Joe said that it wasn't strictly necessary, though. We are not going to use the MD5 hash as a viable algorithm for TCP-AUTH. Thus, the hash would never generate a result that would collide with something else. Lars noted that TCPM probably doesn't have strongest feelings about the continued use of MD5; it is the security folks that should have the most input with respect to what should happen with MD5. We should take their input and go along with that. Lars then went back to fact that the document currently contains two parts; the TCP-AUTH protocol, and the requirements that are an extension of Steve Bellovin's document. Should this be one document or two? There was a general feeling that we should do whatever makes the document come out faster. Gregory Lebovitz recommended two documents. Brian Weis felt that two documents would be both faster and clearer in the end. Joe argued for one, feeling that there was less for people to go read. Mark Allman felt that we should have one document unless there was a compelling reason for two, and they are somewhat combined right now. Gregory was not opposed to one document, but felt both would move faster than one. There was a short discussion on list of requirements. We could change the requirement that we MUST single key. There are a few more things along the same lines in the document; the design team made some decisions, but if the working group wanted to change them, it could do so. Gregory said that he hasn't read the latest on the requirements, but were all of Ron Bonica's concerns with BGP addressed? Joe said those requirements are for keying, not authentication. The keying issues will be considered in SAAG or a spinoff; but it is a real concern -- how fast can you generate keys. With that, Lars closed the meeting. --------------020407040304070003060209-- --=_bOundary-- --==_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHe+C9WyrrWs4yIs4RAhYeAJ9yMN2+miugGPyZg/mBsiQM7BNkQwCfeQbH EN/xJ3/rfcqBtj+yHn6O2FY= =A+fy -----END PGP SIGNATURE----- --==_bOundary-- --===============1496189814== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1496189814==-- From tcpm-bounces@ietf.org Thu Jan 03 16:06:07 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAXGJ-0001l5-J0; Thu, 03 Jan 2008 16:05:59 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JAXGI-0001et-In for tcpm-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 16:05:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAXGI-0001cB-5j for tcpm@ietf.org; Thu, 03 Jan 2008 16:05:58 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAXGH-0008Lr-Co for tcpm@ietf.org; Thu, 03 Jan 2008 16:05:58 -0500 X-IronPort-AV: E=Sophos;i="4.24,240,1196668800"; d="scan'208";a="30024081" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 03 Jan 2008 13:05:56 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m03L5ucU004188; Thu, 3 Jan 2008 13:05:56 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m03L5qHC018047; Thu, 3 Jan 2008 21:05:56 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Jan 2008 13:05:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Jan 2008 13:05:52 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC58047D6091@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP secure Thread-Index: AchOTGxU+YLeyjV5T12k8IIaALueMA== From: "Anantha Ramaiah (ananth)" To: "TCP Maintenance and Minor Extensions WG" X-OriginalArrivalTime: 03 Jan 2008 21:05:55.0815 (UTC) FILETIME=[6E7BD770:01C84E4C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2938; t=1199394356; x=1200258356; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20TCP=20secure=20 |Sender:=20; bh=zGTkWjLuLsQ5z4c7iSENK/Erq4zueyTaDsVUrmmQCzY=; b=RkJPz+HoxLawpAMrlvZkRQhM6u16PaJKvoWT/f1dkuDlvD6CdXM3cyxIzX Z+8piNB9446eVcTZ6stKKU78LbvCquYIUo/ojlIqT/CggTW9Mra2m+nofONZ SI2CKlDv3p; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Ted Faber , mallman@icir.org Subject: [tcpm] TCP secure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Greetings, =20 The following note pertains to the TCP secure document and the hope is to get this to WGLC once the pending issues are resolved. Summary =3D=3D=3D=3D=3D=3D=3D After the presentation in the Chicago IETF and the follow up discussions on the mailing list w.r.t the strength of the mitigations, the outcome of which was to have an applicability statement and then go about getting consensus on the strength of each individual mitigation. To quote Mark Allman : It seems to me that this discussion is really divergent because there is no applicability statement in the document, per Lars' comment. I wonder if you guys could go off and generate such a statement and then we could re-visit this question. I think that would factor things into a question of "where" this is applicable and then how strongly we want to advocate these mitigations within that context. Is that reasonable? There was a discussion in which some folks mentioned how the AS should be structured. We have attempted to capture this and what follows is the sample AS. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D APPLICABILITY STATEMENT The mitigations presented in this document talks about some known in-window attacks and the solutions to the same. The mitigations suggested in this draft SHOULD (RECOMMENDED) be implemented in devices where the TCP connections are most vulnerable to the attacks described in this document. Some examples of such TCP connections are the ones that tend to be long-lived where the connection end points can be determined, in cases where no auxiliary anti-spoofing protection mechanisms like TCP MD5 can be deployed. TCP secure MAY (OPTIONAL) be implemented in other cases.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D It would be nicer if folks can comment on the=20 A) AS and suggest any modifications. B) choose the strength of each mitigation WITH reasoning. My vote=20 =3D=3D=3D=3D=3D=3D=3D Since AS covers the main concern, my vote would go for all MUST's or SHOULD's. Reason for picking MUST's or SHOULD's :=20 With AS in place, the document has given enough leeway for implementers to pick and chose whether one wants to implement TCP secure or not. These mitigations are important since it increases TCP's robustness to various attacks described in the document. Hence I would color them as MUST's or SHOULD's. Thanks, Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jan 04 09:01:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAn6v-0005G3-FQ; Fri, 04 Jan 2008 09:01:21 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JAn6t-0005Fw-Qb for tcpm-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 09:01:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAn6t-0005Fo-Gw for tcpm@ietf.org; Fri, 04 Jan 2008 09:01:19 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAn6q-0002a8-Im for tcpm@ietf.org; Fri, 04 Jan 2008 09:01:19 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id m04E1CvL028626; Fri, 4 Jan 2008 06:01:13 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 3A88C13C4502; Fri, 4 Jan 2008 09:01:07 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B80A7328DFE; Fri, 4 Jan 2008 09:00:11 -0500 (EST) To: Sally Floyd From: Mark Allman Subject: Re: [tcpm] Re: draft-ietf-tcpm-ecnsyn-03.txt backwards compatibility In-Reply-To: <9ee77c9bed4cf392d49f6aeff4774470@mac.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: And We Danced MIME-Version: 1.0 Date: Fri, 04 Jan 2008 09:00:11 -0500 Message-Id: <20080104140011.B80A7328DFE@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Aleksandar Kuzmanovic , "K. K. Ramakrishnan" , Amit Mondal , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0034605731==" Errors-To: tcpm-bounces@ietf.org --===============0034605731== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- Bob raised a point about a case where a CE mark can be masked in the ECN-SYN scheme that is under WGLC. Sally's summary is appended below. It seems from the discussion in Vancouver and the silence on the list that there is not much consensus to change the document's current state (which is approach (1) below---i.e., do nothing). If folks have a different opinion on this question they need to speak up quite fast as it seems this document is ready to forward. Thanks! allman (tcpm co-chair) > To Bob and the working group: > > The discussion with Bob Briscoe concerns the following paragraph in > the ECN/SYN draft: > > The discussion with Bob Briscoe concerns the following paragraph in > Section 4 of the ECN/SYN draft: > > Backwards compatibility: > In order for TCP node B to send a SYN/ACK packet as ECN-Capable, node > B must have received an ECN-setup SYN packet from node A. However, > it is possible that node A supports ECN, but either ignores the CE > codepoint on received SYN/ACK packets, or ignores SYN/ACK packets > with the ECT or CE codepoint set. If the TCP initiator ignores the > CE codepoint on received SYN/ACK packets, this would mean that the > TCP responder would not respond to this congestion indication. > However, this seems to us an acceptable cost to pay in the > incremental deployment of ECN-Capability for TCP's SYN/ACK packets. > It would mean that the responder would not reduce the initial > congestion window from two, three, or four segments down to one > segment, as it should. However, the TCP end nodes would still > respond correctly to any subsequent CE indications on data packets > later on in the connection. Thus, to be explicit, when a TCP > connection includes an initiator that supports ECN but *does not* > support ECN-Capability for SYN/ACK packets, in combination with a > responder that *does* support ECN-Capabililty for SYN/ACK packets, it > is quite possible that the ECN-Capable SYN/ACK packets will be marked > rather than dropped in the network, and that the responder will not > learn about the ECN mark on the SYN/ACK packet. > > There are three choices: > > (1) Leave it as it is, and accept it that sometimes, as a cost of > incemental deployment, a SYN/ACK packet would be ECN-marked, and the > originator, with an older TCP implementation (ECN-capable, but not > understanding ECN-marked SYN/ACK packets), would ignore the ECN mark > on the SYN/ACK packet. > > (I don't know what the Microsoft, Max OS X, and Linux ECN > implementations > do about ECN-marked SYN/ACK packets, but I would assume that they > ignore the ECN marks on SYN/ACK packets...) > > (2) Use one of the four remaining TCP header flags. On a SYN packet, > the flag would mean ECN-SYN ("I want to use ECN, and I understand > ECN-marked SYN/ACK packets"). On a packet other than a SYN packet, > the TCP flag could be used for something else. The responder already > has to look at the TCP header flags to learn that the originator > is ECN-capable, so looking at one more flag should not be a problem. > > (3) Use a two-byte ECN-SYN TCP option on SYN packets, meaning "I > understand ECN-marked SYN/ACK packets." There is at most 40 bytes > for TCP options, and other options that might be carried by SYN > packets include Sack Permitted (2 bytes), MSS (4 bytes), Window > Scale (3 bytes), Timestamp (10 bytes). > > > The downside of (1) is that during congestion, SYN-ACK packets > could be ECN-marked rather than dropped, and the TCP response > might never find out about the ECN-mark on the SYN-ACK packet. > This could happen if the TCP originator uses an old ECN-Capable > TCP implementation that doesn't response to ECN marks on > incoming SYN/ACK packets, and the congested link has ECN enabled. > > The downside of (2) and (3) is that the TCP flag or TCP option > would have to be used in perpetuity, long after all ECN-capable > TCP implementations were updated to respond to incoming ECN-marked > SYN/ACK packets. This would be a drag for (3), but less of a drag > for (2) - the cost of using one of the four remaining header flags > might be an acceptable cost. > > > So would the working group like us to use a TCP header flag for this, > or not? > > This is scheduled for a 5-minute slot at TCMP on Tuesday, so we > can discuss it then. > > - Sally > http://www.icir.org/floyd/ > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHfjvrWyrrWs4yIs4RAsQ9AKCSo3izLU7ezdS64dGcZLyiW6SDtgCdFczt JCmKRHFlR6962/cJr1JsOp8= =ZUcb -----END PGP SIGNATURE----- --=_bOundary-- --===============0034605731== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0034605731==-- From tcpm-bounces@ietf.org Fri Jan 04 13:04:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAquO-0001Du-S4; Fri, 04 Jan 2008 13:04:40 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JAquN-0001DF-L0 for tcpm-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 13:04:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAquN-0001CK-16 for tcpm@ietf.org; Fri, 04 Jan 2008 13:04:39 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAquK-0000Ww-M7 for tcpm@ietf.org; Fri, 04 Jan 2008 13:04:39 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jan 2008 18:04:35 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jan 2008 18:04:35 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1199469874302; Fri, 4 Jan 2008 18:04:34 +0000 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m04I4O2L008832; Fri, 4 Jan 2008 18:04:32 GMT Message-Id: <200801041804.m04I4O2L008832@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 04 Jan 2008 18:04:15 +0000 To: mallman@icir.org From: Bob Briscoe Subject: Re: [tcpm] Re: draft-ietf-tcpm-ecnsyn-03.txt backwards compatibility In-Reply-To: <20080104140011.B80A7328DFE@lawyers.icir.org> References: <9ee77c9bed4cf392d49f6aeff4774470@mac.com> <20080104140011.B80A7328DFE@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 04 Jan 2008 18:04:35.0277 (UTC) FILETIME=[43973FD0:01C84EFC] X-Spam-Score: -1.0 (-) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: Aleksandar Kuzmanovic , "K. K. Ramakrishnan" , Amit Mondal , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark, 'Do nothing' would be a relatively safe option if we assume most legacy ECN in TCPs used as clients will be updated to ECN+ before: a) they interact with those legacy implementations of ECN already out there on servers and b) before ECN is widely deployed on routers. The largest implementation-base of legacy ECN is currently in Windows Vista which has ECN turned off by default. I assume the population of other implementations in TCPs used as clients is small. I've noted a general lack of concern/interest here about standardising a congestion control that doesn't respond to congestion in a set of circumstances that might happen or might not. I assume this is because of the glacial deployment of ECN so far. If the world turns out differently to the above assumptions, we will have to think of a plan B pretty snappish. But I'm not going to hold this up further, as ECN+ is generally a good idea, and the other alternatives for incremental deployment are cumbersome. Bob At 14:00 04/01/2008, Mark Allman wrote: >Folks- > >Bob raised a point about a case where a CE mark can be masked in the >ECN-SYN scheme that is under WGLC. Sally's summary is appended below. >It seems from the discussion in Vancouver and the silence on the list >that there is not much consensus to change the document's current state >(which is approach (1) below---i.e., do nothing). If folks have a >different opinion on this question they need to speak up quite fast as >it seems this document is ready to forward. > >Thanks! > >allman >(tcpm co-chair) > > > > > > To Bob and the working group: > > > > The discussion with Bob Briscoe concerns the following paragraph in > > the ECN/SYN draft: > > > > The discussion with Bob Briscoe concerns the following paragraph in > > Section 4 of the ECN/SYN draft: > > > > Backwards compatibility: > > In order for TCP node B to send a SYN/ACK packet as ECN-Capable, node > > B must have received an ECN-setup SYN packet from node A. However, > > it is possible that node A supports ECN, but either ignores the CE > > codepoint on received SYN/ACK packets, or ignores SYN/ACK packets > > with the ECT or CE codepoint set. If the TCP initiator ignores the > > CE codepoint on received SYN/ACK packets, this would mean that the > > TCP responder would not respond to this congestion indication. > > However, this seems to us an acceptable cost to pay in the > > incremental deployment of ECN-Capability for TCP's SYN/ACK packets. > > It would mean that the responder would not reduce the initial > > congestion window from two, three, or four segments down to one > > segment, as it should. However, the TCP end nodes would still > > respond correctly to any subsequent CE indications on data packets > > later on in the connection. Thus, to be explicit, when a TCP > > connection includes an initiator that supports ECN but *does not* > > support ECN-Capability for SYN/ACK packets, in combination with a > > responder that *does* support ECN-Capabililty for SYN/ACK packets, it > > is quite possible that the ECN-Capable SYN/ACK packets will be marked > > rather than dropped in the network, and that the responder will not > > learn about the ECN mark on the SYN/ACK packet. > > > > There are three choices: > > > > (1) Leave it as it is, and accept it that sometimes, as a cost of > > incemental deployment, a SYN/ACK packet would be ECN-marked, and the > > originator, with an older TCP implementation (ECN-capable, but not > > understanding ECN-marked SYN/ACK packets), would ignore the ECN mark > > on the SYN/ACK packet. > > > > (I don't know what the Microsoft, Max OS X, and Linux ECN > > implementations > > do about ECN-marked SYN/ACK packets, but I would assume that they > > ignore the ECN marks on SYN/ACK packets...) > > > > (2) Use one of the four remaining TCP header flags. On a SYN packet, > > the flag would mean ECN-SYN ("I want to use ECN, and I understand > > ECN-marked SYN/ACK packets"). On a packet other than a SYN packet, > > the TCP flag could be used for something else. The responder already > > has to look at the TCP header flags to learn that the originator > > is ECN-capable, so looking at one more flag should not be a problem. > > > > (3) Use a two-byte ECN-SYN TCP option on SYN packets, meaning "I > > understand ECN-marked SYN/ACK packets." There is at most 40 bytes > > for TCP options, and other options that might be carried by SYN > > packets include Sack Permitted (2 bytes), MSS (4 bytes), Window > > Scale (3 bytes), Timestamp (10 bytes). > > > > > > The downside of (1) is that during congestion, SYN-ACK packets > > could be ECN-marked rather than dropped, and the TCP response > > might never find out about the ECN-mark on the SYN-ACK packet. > > This could happen if the TCP originator uses an old ECN-Capable > > TCP implementation that doesn't response to ECN marks on > > incoming SYN/ACK packets, and the congested link has ECN enabled. > > > > The downside of (2) and (3) is that the TCP flag or TCP option > > would have to be used in perpetuity, long after all ECN-capable > > TCP implementations were updated to respond to incoming ECN-marked > > SYN/ACK packets. This would be a drag for (3), but less of a drag > > for (2) - the cost of using one of the four remaining header flags > > might be an acceptable cost. > > > > > > So would the working group like us to use a TCP header flag for this, > > or not? > > > > This is scheduled for a 5-minute slot at TCMP on Tuesday, so we > > can discuss it then. > > > > - Sally > > http://www.icir.org/floyd/ > > > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www1.ietf.org/mailman/listinfo/tcpm > > > > ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jan 04 13:13:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAr3I-0000IB-O5; Fri, 04 Jan 2008 13:13:52 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JAr3H-0000I0-EA for tcpm-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 13:13:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAr3H-0000Hr-4H for tcpm@ietf.org; Fri, 04 Jan 2008 13:13:51 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAr3E-0000gz-UP for tcpm@ietf.org; Fri, 04 Jan 2008 13:13:51 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jan 2008 18:13:48 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jan 2008 18:13:47 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1199470425800; Fri, 4 Jan 2008 18:13:45 +0000 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m04IDQCG008957; Fri, 4 Jan 2008 18:13:28 GMT Message-Id: <200801041813.m04IDQCG008957@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 04 Jan 2008 18:13:38 +0000 To: mallman@icir.org From: Bob Briscoe Subject: Fwd: Re: [tcpm] Re: draft-ietf-tcpm-ecnsyn-03.txt backwards compatibility Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 04 Jan 2008 18:13:47.0918 (UTC) FILETIME=[8CFD92E0:01C84EFD] X-Spam-Score: -1.0 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Aleksandar Kuzmanovic , "K. K. Ramakrishnan" , Amit Mondal , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark, The draft talks of itself as "a modification to RFC 3168". Will ECN+ be marked as "UPDATES RFC3168" in the RFC index? At least that will help ensure anyone who implements based on the RFC index will not have a choice between RFC3168 and ECN+ Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jan 04 13:30:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JArJ2-0000nf-Jr; Fri, 04 Jan 2008 13:30:08 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JArJ0-0000na-Qe for tcpm-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 13:30:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JArJ0-0000nS-GG for tcpm@ietf.org; Fri, 04 Jan 2008 13:30:06 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JArJ0-0005aa-0V for tcpm@ietf.org; Fri, 04 Jan 2008 13:30:06 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id m04ITxkF006252; Fri, 4 Jan 2008 10:29:59 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id C937713C58D8; Fri, 4 Jan 2008 13:29:53 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1D38B329395; Fri, 4 Jan 2008 13:28:58 -0500 (EST) To: Bob Briscoe From: Mark Allman Subject: Re: Fwd: Re: [tcpm] Re: draft-ietf-tcpm-ecnsyn-03.txt backwards compatibility In-Reply-To: <200801041813.m04IDQCG008957@bagheera.jungle.bt.co.uk> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: And We Danced MIME-Version: 1.0 Date: Fri, 04 Jan 2008 13:28:58 -0500 Message-Id: <20080104182858.1D38B329395@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Aleksandar Kuzmanovic , "K. K. Ramakrishnan" , Amit Mondal , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0810612598==" Errors-To: tcpm-bounces@ietf.org --===============0810612598== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > The draft talks of itself as "a modification to RFC 3168". Will ECN+ > be marked as "UPDATES RFC3168" in the RFC index? > > At least that will help ensure anyone who implements based on the > RFC index will not have a choice between RFC3168 and ECN+ Without having considered this for more than a few seconds, I think it is reasonable to think this will be labeled as an 'update' to RFC3168. If someone thinks that would be somehow bogus, please speak up. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHfnrpWyrrWs4yIs4RAgzZAKCLUfYOj7wzSahXXnuLXxnTQ00m3QCgiafw dvJaVMUILU8+Kb9TSUOuwcY= =UZmt -----END PGP SIGNATURE----- --=_bOundary-- --===============0810612598== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0810612598==-- From tcpm-bounces@ietf.org Fri Jan 04 13:47:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JArZu-0002cF-5v; Fri, 04 Jan 2008 13:47:34 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JArZt-0002c8-Mr for tcpm-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 13:47:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JArZt-0002c0-CJ for tcpm@ietf.org; Fri, 04 Jan 2008 13:47:33 -0500 Received: from smtpoutm.mac.com ([17.148.16.76]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JArZs-00061H-WE for tcpm@ietf.org; Fri, 04 Jan 2008 13:47:33 -0500 Received: from mac.com (asmtp005-s [10.150.69.68]) by smtpoutm.mac.com (Xserve/smtpout013/MantshX 4.0) with ESMTP id m04IlLZI018612; Fri, 4 Jan 2008 10:47:21 -0800 (PST) Received: from [192.150.186.176] (laptop176.icsi.berkeley.edu [192.150.186.176]) (authenticated bits=0) by mac.com (Xserve/asmtp005/MantshX 4.0) with ESMTP id m04IlJ5Y000444; Fri, 4 Jan 2008 10:47:19 -0800 (PST) In-Reply-To: <20080104182858.1D38B329395@lawyers.icir.org> References: <20080104182858.1D38B329395@lawyers.icir.org> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7e9fe8691b7c4216c020a4bc62b0d9c5@mac.com> Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [tcpm] Re: draft-ietf-tcpm-ecnsyn-03.txt backwards compatibility Date: Fri, 4 Jan 2008 10:47:19 -0800 To: mallman@icir.org X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Aleksandar Kuzmanovic , "K. K. Ramakrishnan" , Amit Mondal , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org >> The draft talks of itself as "a modification to RFC 3168". Will ECN+ >> be marked as "UPDATES RFC3168" in the RFC index? >> >> At least that will help ensure anyone who implements based on the >> RFC index will not have a choice between RFC3168 and ECN+ > > Without having considered this for more than a few seconds, I think it > is reasonable to think this will be labeled as an 'update' to RFC3168. > If someone thinks that would be somehow bogus, please speak up. Our intention was for this to be labeled as an update to RFC 3168. Thanks, - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jan 04 14:51:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAsZN-0007KV-Dm; Fri, 04 Jan 2008 14:51:05 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JAsZL-00074i-V0 for tcpm-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 14:51:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAsZL-00073R-H9 for tcpm@ietf.org; Fri, 04 Jan 2008 14:51:03 -0500 Received: from smtpoutm.mac.com ([17.148.16.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAsZJ-00030k-7D for tcpm@ietf.org; Fri, 04 Jan 2008 14:51:03 -0500 Received: from mac.com (asmtp001-s [10.150.69.64]) by smtpoutm.mac.com (Xserve/smtpout004/MantshX 4.0) with ESMTP id m04JooNj028514; Fri, 4 Jan 2008 11:50:55 -0800 (PST) Received: from [192.150.186.176] (laptop176.icsi.berkeley.edu [192.150.186.176]) (authenticated bits=0) by mac.com (Xserve/asmtp001/MantshX 4.0) with ESMTP id m04Jol8c013801; Fri, 4 Jan 2008 11:50:47 -0800 (PST) In-Reply-To: <200801041804.m04I4O2L008832@bagheera.jungle.bt.co.uk> References: <9ee77c9bed4cf392d49f6aeff4774470@mac.com> <20080104140011.B80A7328DFE@lawyers.icir.org> <200801041804.m04I4O2L008832@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [tcpm] Re: draft-ietf-tcpm-ecnsyn-03.txt backwards compatibility Date: Fri, 4 Jan 2008 11:50:45 -0800 To: Bob Briscoe X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: tcpm@ietf.org, Aleksandar Kuzmanovic , "K. K. Ramakrishnan" , Amit Mondal , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Bob - ... > I've noted a general lack of concern/interest here about standardising > a congestion control that doesn't respond to congestion in a set of > circumstances that might happen or might not. I assume this is because > of the glacial deployment of ECN so far. > > If the world turns out differently to the above assumptions, we will > have to think of a plan B pretty snappish. > > But I'm not going to hold this up further, as ECN+ is generally a good > idea, and the other alternatives for incremental deployment are > cumbersome. I think it is safe not to use a flag for ECN-Capable SYN/ACK packets, but I wouldn't have any problems with using a flag either. The revised text for draft-ietf-tcpm-ecnsyn is attached below. - Sally http://www.icir.org/floyd/ Backwards compatibility: In order for TCP node B to send a SYN/ACK packet as ECN-Capable, node B must have received an ECN-setup SYN packet from node A. However, it is possible that node A supports ECN, but either ignores the CE codepoint on received SYN/ACK packets, or ignores SYN/ACK packets with the ECT or CE codepoint set. If the TCP initiator ignores the CE codepoint on received SYN/ACK packets, this would mean that the TCP responder would not respond to this congestion indication. However, this seems to us an acceptable cost to pay in the incremental deployment of ECN-Capability for TCP's SYN/ACK packets. It would mean that the responder would not reduce the initial congestion window from two, three, or four segments down to one segment, as it should. However, the TCP end nodes would still respond correctly to any subsequent CE indications on data packets later on in the connection. Figure 3 shows an interchange with the SYN/ACK packet ECN-marked, but with the ECN mark ignored by the TCP originator. --------------------------------------------------------------- TCP Node A Router TCP Node B ---------- ------ ---------- ECN-setup SYN packet ---> ECN-setup SYN packet ---> <--- ECN-setup SYN/ACK, ECT <--- Sets CE on SYN/ACK <--- ECN-setup SYN/ACK, CE Data/ACK, No ECN-Echo ---> Data/ACK ---> <--- Data (up to four packets), CWR --------------------------------------------------------------- Figure 2: SYN exchange with the SYN/ACK packet marked, but with the ECN mark ignored by the TCP initiator. Thus, to be explicit, when a TCP connection includes an initiator that supports ECN but *does not* support ECN-Capability for SYN/ACK packets, in combination with a responder that *does* support ECN- Capabililty for SYN/ACK packets, it is possible that the ECN-Capable SYN/ACK packets will be marked rather than dropped in the network, and that the responder will not learn about the ECN mark on the SYN/ACK packet. This would not be a problem in a scenario with mostly long-lived TCP connections, but it would be more problematic in a scenario where all TCP connections consisted of four data packets, and the TCP responder was ready to send its data packets immediately after the SYN/ACK exchange. Of course, with *severe* congestion, the SYN/ACK packets would likely be dropped rather than ECN-marked at the congested router, preventing the TCP responder from adding to the congestion by sending its initial window of four data packets. It is also possible that in some older TCP implementation, the initiator would ignore arriving SYN/ACK packets that had the ECT or CE codepoint set. This would result in a delay in connection set-up for that TCP connection, with the initiator re-sending the SYN packet after a retransmit timeout. We are not aware of any TCP implementations with this behavior. One possibility for coping with problems of backwards compatibility would be for TCP initiators to use a TCP flag that means "I understand ECN-Capable SYN/ACK packets". If this document were to standardize the use of such an "ECN-SYN" flag, then the TCP responder would only send a SYN/ACK packet as ECN-capable if the incoming SYN packet had the "ECN-SYN" flag set. An ECN-SYN flag would prevent the backwards compatibility problems described in the paragraphs above. One drawback to the use of an ECN-SYN flag is that it would use one of the four remaining reserved bits in the TCP header, for a transient backwards compatibility problem. This drawback is limited by the fact that the "ECN-SYN" flag would be defined only for use with ECN-setup SYN packets; that bit in the TCP header could be defined to have other uses for other kinds of TCP packets. Factors in deciding not to use an ECN-SYN flag include the following: (1) The limited installed base: At the time that this document was written, the TCP implementations in Microsoft Vista and Mac OS X included ECN, but ECN was not enabled by default [SBT07]. Thus, there was not a large deployed base of ECN-Capable TCP implementations. This limits the scope of any backwards compatibility problems. (2) Limits to the scope of the problem: The backwards compatibility problem would not be serious enough to cause congestion collapse; with severe congestion, the buffer at the congested router will overflow, and the congested router will drop rather than ECN-mark arriving SYN packets. Some active queue management mechanisms might switch from packet-marking to packet-dropping in times of high congestion before buffer overflow, as recommended in Section 19.1 of RFC 3168. This helps to prevent congestion collapse problems with the use of ECN. (3) Detection of and response to backwards-compatibility problems: A TCP responder such as a web server can't differentiate between a SYN/ACK packet that is not ECN-marked in the network, and a SYN/ACK packet that is ECN-marked, but where the ECN mark is ignored by the TCP initiator. However, a TCP responder *can* detect if a SYN/ACK packet is sent as ECN-capable and not reported as ECN-marked, but data packets are dropped or marked from the initial window of data. We will call this scenario "initial-window-congestion". If a web server frequently experienced initial-window congestion (without SYN/ACK congestion), then the web server *might* be experiencing backwards compatibility problems with ECN-Capable SYN/ACK packets, and could respond by not sending SYN/ACK packets as ECN-Capable. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Jan 05 19:12:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBJ7c-0003mo-4n; Sat, 05 Jan 2008 19:12:12 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JBJ7a-0003cr-1l for tcpm-confirm+ok@megatron.ietf.org; Sat, 05 Jan 2008 19:12:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBJ7Z-0003Wn-Lq for tcpm@ietf.org; Sat, 05 Jan 2008 19:12:09 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBJ7Y-0001wB-CO for tcpm@ietf.org; Sat, 05 Jan 2008 19:12:09 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Jan 2008 00:12:07 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Jan 2008 00:12:06 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1199578326395; Sun, 6 Jan 2008 00:12:06 +0000 Received: from mut.jungle.bt.co.uk ([10.73.192.121]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m060Bc8e031128; Sun, 6 Jan 2008 00:12:02 GMT Message-Id: <200801060012.m060Bc8e031128@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 06 Jan 2008 00:11:51 +0000 To: Sally Floyd From: Bob Briscoe Subject: Re: [tcpm] Re: draft-ietf-tcpm-ecnsyn-03.txt backwards compatibility In-Reply-To: References: <9ee77c9bed4cf392d49f6aeff4774470@mac.com> <20080104140011.B80A7328DFE@lawyers.icir.org> <200801041804.m04I4O2L008832@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 06 Jan 2008 00:12:06.0870 (UTC) FILETIME=[C5C70F60:01C84FF8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: tcpm@ietf.org, Aleksandar Kuzmanovic , "K. K. Ramakrishnan" , Amit Mondal , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Sally, The new text outlines the issues well (I've suggested some minor changes inline - all in the para below Fig 2). But I'm not a great fan of writing long complicated text in standards track documents that describes a problem, when it's sort of hinting that implementers don't actually need to do anything about it. One way round this would be to move this text about incremental deployment to an appendix. Point (3) is a good one that I hadn't thought of. Here's strawman text for a solution that could be put in the body. I've used the terms 'TCP clients' and 'TCP servers' for machines used mostly as initiators or responders respectively: /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ "There is a potential incremental deployment problem in circumstances we believe will be unlikely, described in (Appendix X). In monitoring the deployment of ECN and ECN+, if significant numbers of queues have ECN turned on and if we find that large numbers of TCP clients still have legacy ECN enabled while significant numbers of TCP servers have upgraded to ECN+, the management application described below could be deployed on ECN+ servers, particularly if most of the flows served fit within an initial window. The management application could monitor the average fraction of ACKs with ECE set in response to: 1. a SYN/ACK 2. the segments in the initial window. If the former fraction was significantly lower than the latter, the management application could switch ECN+ back to ECN, perhaps requiring manual intervention rather than automatic switching. Once the community deemed that the deployment situation had become safer for ECN+, server administrators could switch ECN+ back on, either leaving the managment application running, or eventually removing the management application. Therefore, all ECN+ TCP implementations SHOULD provide the following management interfaces, in order to ease installation of such a management application after the TCP has been upgraded to ECN+: o An interface to turn ECN+ on or off; o An interface to read a count of only those ACKs with ECE set that were responses to SYN/ACKs." /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ I said this is strawman text, because I'm not sure I even support it myself. I'm just trying to work through the minimum implementers would need to do about incremental deployment other than 'nothing'. The alternative of doing absolutely nothing about incremental deployment right now is still possible. The above required management interfaces can be added by upgrading the kernel any time. I just figured the above might be worthwhile to ease installation of a little monitoring application, so at least sysadmins can simply test whether there is a problem if they choose to. [BTW, there are cases where the approach in (3) wouldn't work (e.g. if SYN/ACKs had a significantly lower probability of ECN marking than data packets). But I really don't think we should start down that rat-hole in this I-D - it would be like describing a pimple on a spot on a flea.] A little more inline... At 19:50 04/01/2008, Sally Floyd wrote: >Bob - > >... >>I've noted a general lack of concern/interest here about >>standardising a congestion control that doesn't respond to >>congestion in a set of circumstances that might happen or might >>not. I assume this is because of the glacial deployment of ECN so far. >> >>If the world turns out differently to the above assumptions, we >>will have to think of a plan B pretty snappish. >> >>But I'm not going to hold this up further, as ECN+ is generally a >>good idea, and the other alternatives for incremental deployment >>are cumbersome. > >I think it is safe not to use a flag for ECN-Capable SYN/ACK packets, >but I wouldn't have any problems with using a flag either. > >The revised text for draft-ietf-tcpm-ecnsyn is attached below. > >- Sally >http://www.icir.org/floyd/ > > > Backwards compatibility: \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > Figure 2: SYN exchange with the SYN/ACK packet marked, > but with the ECN mark ignored by the TCP initiator. > > Thus, to be explicit, when a TCP connection includes an initiator > that supports ECN but *does not* support ECN-Capability for SYN/ACK > packets, in combination with a responder that *does* support ECN- > Capabililty for SYN/ACK packets, it is possible that the ECN-Capable > SYN/ACK packets will be marked rather than dropped in the network, > and that the responder will not learn about the ECN mark on the > SYN/ACK packet. This would not be a problem s/ in a scenario with/ with machines serving / > mostly long-lived TCP connections, but it would be more problematic s/in a scenario where all /with an ECN+ TCP responder where most / >TCP connections consisted of at most >four data > packets, and the TCP responder was ready to send its data packets > immediately after the SYN/ACK exchange. If correctly responding ECN-capable traffic shared a bottleneck with traffic from such an ECN+ machine, its rate would be continually beaten down by the ECN+ machine's reduced congestion response. >Of course, with *severe* > congestion, the SYN/ACK packets would likely be dropped rather than > ECN-marked at the congested router, preventing the TCP responder from > adding to the congestion by sending its initial window of four data > packets. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Cheers Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jan 08 00:22:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC6uQ-0000qG-Bu; Tue, 08 Jan 2008 00:21:54 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JC6uO-0000qB-Lk for tcpm-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 00:21:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC6uO-0000oR-8z for tcpm@ietf.org; Tue, 08 Jan 2008 00:21:52 -0500 Received: from smtpoutm.mac.com ([17.148.16.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC6uN-0008BV-4K for tcpm@ietf.org; Tue, 08 Jan 2008 00:21:52 -0500 Received: from mac.com (asmtp004-s [10.150.69.67]) by smtpoutm.mac.com (Xserve/smtpout004/MantshX 4.0) with ESMTP id m085LiKu020956; Mon, 7 Jan 2008 21:21:44 -0800 (PST) Received: from [192.168.1.101] (adsl-70-132-0-53.dsl.snfc21.sbcglobal.net [70.132.0.53]) (authenticated bits=0) by mac.com (Xserve/asmtp004/MantshX 4.0) with ESMTP id m085Lf9l020696; Mon, 7 Jan 2008 21:21:41 -0800 (PST) In-Reply-To: <200801060012.m060Bc8e031128@bagheera.jungle.bt.co.uk> References: <9ee77c9bed4cf392d49f6aeff4774470@mac.com> <20080104140011.B80A7328DFE@lawyers.icir.org> <200801041804.m04I4O2L008832@bagheera.jungle.bt.co.uk> <200801060012.m060Bc8e031128@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1bb51f3f2858e4828998faf9afb6a745@mac.com> Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [tcpm] Re: draft-ietf-tcpm-ecnsyn-03.txt backwards compatibility Date: Mon, 7 Jan 2008 21:21:40 -0800 To: Bob Briscoe X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: tcpm@ietf.org, Aleksandar Kuzmanovic , "K. K. Ramakrishnan" , Amit Mondal , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Bob - > The new text outlines the issues well (I've suggested some minor > changes inline - all in the para below Fig 2). > > But I'm not a great fan of writing long complicated text in standards > track documents that describes a problem, when it's sort of hinting > that implementers don't actually need to do anything about it. One way > round this would be to move this text about incremental deployment to > an appendix. Yep, I will do that. > > Point (3) is a good one that I hadn't thought of. > > Here's strawman text for a solution that could be put in the body. > I've used the terms 'TCP clients' and 'TCP servers' for machines used > mostly as initiators or responders respectively: > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > \/\ > "There is a potential incremental deployment problem in circumstances > we believe will be unlikely, described in (Appendix X). In monitoring > the deployment of ECN and ECN+, if significant numbers of queues have > ECN turned on and if we find that large numbers of TCP clients still > have legacy ECN enabled while significant numbers of TCP servers have > upgraded to ECN+, the management application described below could be > deployed on ECN+ servers, particularly if most of the flows served fit > within an initial window. > > The management application could monitor the average fraction of ACKs > with ECE set in response to: > 1. a SYN/ACK > 2. the segments in the initial window. > If the former fraction was significantly lower than the latter, the > management application could switch ECN+ back to ECN, perhaps > requiring manual intervention rather than automatic switching. > > Once the community deemed that the deployment situation had become > safer for ECN+, server administrators could switch ECN+ back on, > either leaving the managment application running, or eventually > removing the management application. > > Therefore, all ECN+ TCP implementations SHOULD provide the following > management interfaces, in order to ease installation of such a > management application after the TCP has been upgraded to ECN+: > o An interface to turn ECN+ on or off; > o An interface to read a count of only those ACKs with ECE set > that were responses to SYN/ACKs." > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > \/\ > > I said this is strawman text, because I'm not sure I even support it > myself. I'm just trying to work through the minimum implementers would > need to do about incremental deployment other than 'nothing'. I am inclined to leave that out, for now. Unless others have other opinions. But I did add a moderated version as follows: "The TCP implementation using ECN-Capable SYN/ACK packets SHOULD include a management interface to allow the use of ECN to be turned off for SYN/ACK packets. This is to deal with possible backwards compatibility problems such as those discussed in Appendix B." > The alternative of doing absolutely nothing about incremental > deployment right now is still possible. The above required management > interfaces can be added by upgrading the kernel any time. I just > figured the above might be worthwhile to ease installation of a little > monitoring application, so at least sysadmins can simply test whether > there is a problem if they choose to. > > [BTW, there are cases where the approach in (3) wouldn't work (e.g. if > SYN/ACKs had a significantly lower probability of ECN marking than > data packets). But I really don't think we should start down that > rat-hole in this I-D - it would be like describing a pimple on a spot > on a flea.] > > A little more inline... > > At 19:50 04/01/2008, Sally Floyd wrote: >> Bob - >> >> ... >>> I've noted a general lack of concern/interest here about >>> standardising a congestion control that doesn't respond to >>> congestion in a set of circumstances that might happen or might not. >>> I assume this is because of the glacial deployment of ECN so far. >>> >>> If the world turns out differently to the above assumptions, we will >>> have to think of a plan B pretty snappish. >>> >>> But I'm not going to hold this up further, as ECN+ is generally a >>> good idea, and the other alternatives for incremental deployment are >>> cumbersome. >> >> I think it is safe not to use a flag for ECN-Capable SYN/ACK packets, >> but I wouldn't have any problems with using a flag either. >> >> The revised text for draft-ietf-tcpm-ecnsyn is attached below. >> >> - Sally >> http://www.icir.org/floyd/ >> >> >> Backwards compatibility: > > \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > \/ > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > \/\ > >> Figure 2: SYN exchange with the SYN/ACK packet marked, >> but with the ECN mark ignored by the TCP initiator. >> >> Thus, to be explicit, when a TCP connection includes an initiator >> that supports ECN but *does not* support ECN-Capability for SYN/ACK >> packets, in combination with a responder that *does* support ECN- >> Capabililty for SYN/ACK packets, it is possible that the >> ECN-Capable >> SYN/ACK packets will be marked rather than dropped in the network, >> and that the responder will not learn about the ECN mark on the >> SYN/ACK packet. This would not be a problem > > s/ in a scenario with/ with machines serving / I changed "scenario" to "environment" >> mostly long-lived TCP connections, but it would be more problematic > > s/in a scenario where all /with an ECN+ TCP responder where most / I changed "scenario" to "environment" here also, and changed "all" to "much". >> TCP connections consisted of > > at most I left it as it. If all TCP connections used an initial window of one data packet, or had only one data packet to send, for example, then ECN+ wouldn't have as large backwards compatibility problems. (That is, the congestion control situation would be pretty bad with or without backwards compatibility problems with ECN+.) >> four data >> packets, and the TCP responder was ready to send its data packets >> immediately after the SYN/ACK exchange. > > If correctly responding ECN-capable traffic shared a bottleneck with > traffic from such an ECN+ machine, its rate would be continually > beaten down by the ECN+ machine's reduced congestion response. Yep. >> Of course, with *severe* >> congestion, the SYN/ACK packets would likely be dropped rather than >> ECN-marked at the congested router, preventing the TCP responder >> from >> adding to the congestion by sending its initial window of four data >> packets. > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > \/\ - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jan 08 11:15:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCH6X-0002q7-RF; Tue, 08 Jan 2008 11:15:05 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JCH6W-0002py-Ev for tcpm-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 11:15:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCH6V-0002pq-Uf; Tue, 08 Jan 2008 11:15:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCH6V-0002ww-Dd; Tue, 08 Jan 2008 11:15:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 3102B26E7E; Tue, 8 Jan 2008 16:15:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JCH6V-0006Vm-3D; Tue, 08 Jan 2008 11:15:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 08 Jan 2008 11:15:03 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-09.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Improving TCP's Robustness to Blind In-Window Attacks Author(s) : A. Ramaiah, et al. Filename : draft-ietf-tcpm-tcpsecure-09.txt Pages : 26 Date : 2008-1-8 TCP has historically been considered protected against spoofed off- path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32 bit sequence number(s). A combination of increasing window sizes and applications using longer term connections (e.g. H-323 or Border Gateway Protocol [RFC4271]) have left modern TCP implementations more vulnerable to these types of spoofed packet injection attacks. Many of these long term TCP applications tend to have predictable IP addresses and ports which makes it far easier for the 4-tuple to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a RST, SYN or DATA segment into a TCP connection by systematically guessing the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to either abort or possibly cause data corruption. This document specifies small modifications to the way TCP handles inbound segments that can reduce the chances of a successful attack. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcpsecure-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcpsecure-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-1-8103037.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcpsecure-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcpsecure-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-1-8103037.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Tue Jan 08 11:37:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCHSJ-0000wL-LH; Tue, 08 Jan 2008 11:37:35 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JCHSI-0000sr-C0 for tcpm-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 11:37:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCHSI-0000sd-29 for tcpm@ietf.org; Tue, 08 Jan 2008 11:37:34 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCHSH-0003gH-EH for tcpm@ietf.org; Tue, 08 Jan 2008 11:37:34 -0500 X-IronPort-AV: E=Sophos;i="4.24,258,1196668800"; d="scan'208";a="10520105" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 08 Jan 2008 08:37:32 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m08GbWh5014568; Tue, 8 Jan 2008 08:37:32 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m08GbRFU000267; Tue, 8 Jan 2008 16:37:27 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 08:37:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Jan 2008 08:37:20 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5804830AB1@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP secure Thread-Index: AchOTGxU+YLeyjV5T12k8IIaALueMADx7/xA From: "Anantha Ramaiah (ananth)" To: "TCP Maintenance and Minor Extensions WG" X-OriginalArrivalTime: 08 Jan 2008 16:37:25.0681 (UTC) FILETIME=[C0293A10:01C85214] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3900; t=1199810252; x=1200674252; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20TCP=20secure=20 |Sender:=20; bh=QujEnMlX/UT9knyFgqMlmW9QZeMIrVG3d2lOHy3zrgs=; b=eNWJLS/JaSL8mdf7qXBVwnl3TI7Oa9g0KQD6vyyLAaR138nJgmsfwFU3sU T2a6E2MV8mPgstml9ruy9Tb3edIkIAnwG8D01s/iasxujOhRsNhZvbxN1C9z c1x+FH6uaO; Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Ted Faber , mallman@icir.org Subject: [tcpm] RE: TCP secure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org More latest developments on this. Since the draft was expiring on Jan 9th, I had to post a new version to renew the draft which should show up in the usual places very soon. This version has :- - The Applicability statement in place (section 1.1)=20 - Alfred Hoenes had some editorial comments on the previous version, incorporated them. You can use the AS in the draft as a reference for discussions pertaining to the same. Thanks, Anantha > -----Original Message----- > From: Anantha Ramaiah (ananth)=20 > Sent: Thursday, January 03, 2008 1:06 PM > To: TCP Maintenance and Minor Extensions WG > Cc: 'mallman@icir.org'; Ted Faber > Subject: TCP secure=20 >=20 > Greetings, > =20 > The following note pertains to the TCP secure document and=20 > the hope is to get this to WGLC once the pending issues are resolved. >=20 > Summary > =3D=3D=3D=3D=3D=3D=3D >=20 > After the presentation in the Chicago IETF and the follow up=20 > discussions on the mailing list w.r.t the strength of the=20 > mitigations, the outcome of which was to have an=20 > applicability statement and then go about getting consensus=20 > on the strength of each individual mitigation. To quote Mark Allman : >=20 > >=20 > It seems to me that this discussion is really divergent=20 > because there > is no applicability statement in the document, per Lars' comment. I > wonder if you guys could go off and generate such a=20 > statement and then > we could re-visit this question. I think that would factor things > into a question of "where" this is applicable and then how=20 > strongly we > want to advocate these mitigations within that context. Is that > reasonable? >=20 > >=20 > There was a discussion in which some folks mentioned how the=20 > AS should be structured. We have attempted to capture this=20 > and what follows is the sample AS. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > APPLICABILITY STATEMENT >=20 > The mitigations presented in this document talks about some=20 > known in-window attacks and the solutions to the same. The=20 > mitigations suggested in this draft SHOULD (RECOMMENDED) be=20 > implemented in devices where the TCP connections are most=20 > vulnerable to the attacks described in this document. Some=20 > examples of such TCP connections are the ones that tend to be=20 > long-lived where the connection end points can be determined,=20 > in cases where no auxiliary anti-spoofing protection=20 > mechanisms like TCP MD5 can be deployed. TCP secure MAY=20 > (OPTIONAL) be implemented in other cases.=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >=20 > It would be nicer if folks can comment on the=20 >=20 > A) AS and suggest any modifications. >=20 > B) choose the strength of each mitigation WITH reasoning. >=20 >=20 > My vote > =3D=3D=3D=3D=3D=3D=3D >=20 > Since AS covers the main concern, my vote would go for all=20 > MUST's or SHOULD's. >=20 > Reason for picking MUST's or SHOULD's :=20 >=20 > With AS in place, the document has given enough leeway for=20 > implementers to pick and chose whether one wants to implement=20 > TCP secure or not. These mitigations are important since it=20 > increases TCP's robustness to various attacks described in=20 > the document. Hence I would color them as MUST's or SHOULD's. >=20 > Thanks, > Anantha >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jan 08 13:57:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCJdK-0002BD-Pd; Tue, 08 Jan 2008 13:57:06 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JCJdJ-0001wU-0k for tcpm-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 13:57:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCJdI-0001vi-MX for tcpm@ietf.org; Tue, 08 Jan 2008 13:57:04 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCJdI-0002Qp-8e for tcpm@ietf.org; Tue, 08 Jan 2008 13:57:04 -0500 Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m08IuVGY000006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 8 Jan 2008 10:56:32 -0800 (PST) Received: (from faber@localhost) by zod.isi.edu (8.14.2/8.14.2/Submit) id m08IuVJM064392 for tcpm@ietf.org; Tue, 8 Jan 2008 10:56:31 -0800 (PST) (envelope-from faber) Date: Tue, 8 Jan 2008 10:56:31 -0800 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] WGLC: 2581bis Message-ID: <20080108185631.GC17262@zod.isi.edu> References: <20071127004720.GD3385@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20071127004720.GD3385@hut.isi.edu> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@zod.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0075286547==" Errors-To: tcpm-bounces@ietf.org --===============0075286547== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1SQmhf2mF2YjsYvc" Content-Disposition: inline --1SQmhf2mF2YjsYvc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 26, 2007 at 04:47:20PM -0800, Ted Faber wrote: > Mark and I would like to start a WGLC for the revision of 2581 from > Proposed Standard to Draft Standard. >=20 > As you know, this is a central document in TCP and the revision pretty > much just recognized that and adds an implementation report. The > implementation report notes that basically all TCPs support the > algorithms in the document interoperably. We believe this is ready for > publication. >=20 > Other than the addition of the report, changes to the document from the > published Proposed Standard are minimal. >=20 > Please read and let us know if you agree or disagree and why. This will > be a long WGLC to accomodate for the IETF meeting next week and the > holiday season. The WGLC will end 21 Dec 2007. This WGLC has ended with a few substantive outstanding comments that are being processed by the authors and the commenters. =20 More information as those are resolved. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --1SQmhf2mF2YjsYvc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHg8ddaUz3f+Zf+XsRAvSxAKCahHk5RIrvUJj7DOLpWwdeJwL58QCeLoew GXT4r8KWoDFyEbvp66b7cKI= =gQoW -----END PGP SIGNATURE----- --1SQmhf2mF2YjsYvc-- --===============0075286547== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0075286547==-- From tcpm-bounces@ietf.org Tue Jan 08 19:08:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCOU6-0000nv-49; Tue, 08 Jan 2008 19:07:54 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JCOU4-0000Rq-Gl for tcpm-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 19:07:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCOU3-0000Ri-Lt for tcpm@ietf.org; Tue, 08 Jan 2008 19:07:51 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCOU2-0002jn-LU for tcpm@ietf.org; Tue, 08 Jan 2008 19:07:51 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jan 2008 00:07:47 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jan 2008 00:07:47 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1199837266705; Wed, 9 Jan 2008 00:07:46 +0000 Received: from mut.jungle.bt.co.uk ([10.73.176.65]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m09079NU032330; Wed, 9 Jan 2008 00:07:28 GMT Message-Id: <200801090007.m09079NU032330@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 09 Jan 2008 00:06:47 +0000 To: Sally Floyd From: Bob Briscoe Subject: Re: [tcpm] Re: draft-ietf-tcpm-ecnsyn-03.txt backwards compatibility In-Reply-To: <1bb51f3f2858e4828998faf9afb6a745@mac.com> References: <9ee77c9bed4cf392d49f6aeff4774470@mac.com> <20080104140011.B80A7328DFE@lawyers.icir.org> <200801041804.m04I4O2L008832@bagheera.jungle.bt.co.uk> <200801060012.m060Bc8e031128@bagheera.jungle.bt.co.uk> <1bb51f3f2858e4828998faf9afb6a745@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 09 Jan 2008 00:07:47.0213 (UTC) FILETIME=[AA3FCBD0:01C85253] X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: tcpm@ietf.org, Aleksandar Kuzmanovic , "K. K. Ramakrishnan" , Amit Mondal , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Sally, I'll accept all your responses... Except, I probably didn't explain well why I didn't like: "This would not be a problem in an environment with mostly long-lived TCP connections..." This is ambiguous as to whether it means the competing flows are long lived or the ECN+ server's flows are long lived. The problem is short flows from the ECN+server. The problem hits both short and long competing flows. Bob At 05:21 08/01/2008, Sally Floyd wrote: >Bob - > >>The new text outlines the issues well (I've suggested some minor >>changes inline - all in the para below Fig 2). >> >>But I'm not a great fan of writing long complicated text in standards >>track documents that describes a problem, when it's sort of hinting >>that implementers don't actually need to do anything about it. One way >>round this would be to move this text about incremental deployment to >>an appendix. > >Yep, I will do that. >> >>Point (3) is a good one that I hadn't thought of. >> >>Here's strawman text for a solution that could be put in the body. >>I've used the terms 'TCP clients' and 'TCP servers' for machines used >>mostly as initiators or responders respectively: >> >>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ \/\ >>"There is a potential incremental deployment problem in circumstances >>we believe will be unlikely, described in (Appendix X). In monitoring >>the deployment of ECN and ECN+, if significant numbers of queues have >>ECN turned on and if we find that large numbers of TCP clients still >>have legacy ECN enabled while significant numbers of TCP servers have >>upgraded to ECN+, the management application described below could be >>deployed on ECN+ servers, particularly if most of the flows served fit >>within an initial window. >> >>The management application could monitor the average fraction of ACKs >>with ECE set in response to: >> 1. a SYN/ACK >> 2. the segments in the initial window. >>If the former fraction was significantly lower than the latter, the >>management application could switch ECN+ back to ECN, perhaps >>requiring manual intervention rather than automatic switching. >> >>Once the community deemed that the deployment situation had become >>safer for ECN+, server administrators could switch ECN+ back on, >>either leaving the managment application running, or eventually >>removing the management application. >> >>Therefore, all ECN+ TCP implementations SHOULD provide the following >>management interfaces, in order to ease installation of such a >>management application after the TCP has been upgraded to ECN+: >> o An interface to turn ECN+ on or off; >> o An interface to read a count of only those ACKs with ECE set >>that were responses to SYN/ACKs." >>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ \/\ >> >>I said this is strawman text, because I'm not sure I even support it >>myself. I'm just trying to work through the minimum implementers would >>need to do about incremental deployment other than 'nothing'. > >I am inclined to leave that out, for now. >Unless others have other opinions. > >But I did add a moderated version as follows: > >"The TCP implementation using ECN-Capable SYN/ACK packets SHOULD >include a management interface to allow the use of ECN to be turned >off for SYN/ACK packets. This is to deal with possible backwards >compatibility problems such as those discussed in Appendix B." > >>The alternative of doing absolutely nothing about incremental >>deployment right now is still possible. The above required management >>interfaces can be added by upgrading the kernel any time. I just >>figured the above might be worthwhile to ease installation of a little >>monitoring application, so at least sysadmins can simply test whether >>there is a problem if they choose to. >> >>[BTW, there are cases where the approach in (3) wouldn't work (e.g. if >>SYN/ACKs had a significantly lower probability of ECN marking than >>data packets). But I really don't think we should start down that >>rat-hole in this I-D - it would be like describing a pimple on a spot >>on a flea.] >> >>A little more inline... >> >>At 19:50 04/01/2008, Sally Floyd wrote: >>>Bob - >>> >>>... >>>>I've noted a general lack of concern/interest here about >>>>standardising a congestion control that doesn't respond to >>>>congestion in a set of circumstances that might happen or might not. >>>>I assume this is because of the glacial deployment of ECN so far. >>>> >>>>If the world turns out differently to the above assumptions, we will >>>>have to think of a plan B pretty snappish. >>>> >>>>But I'm not going to hold this up further, as ECN+ is generally a >>>>good idea, and the other alternatives for incremental deployment are >>>>cumbersome. >>> >>>I think it is safe not to use a flag for ECN-Capable SYN/ACK packets, >>>but I wouldn't have any problems with using a flag either. >>> >>>The revised text for draft-ietf-tcpm-ecnsyn is attached below. >>> >>>- Sally >>>http://www.icir.org/floyd/ >>> >>> >>> Backwards compatibility: >> >>\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ \/ >> >>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ \/\ >> >>> Figure 2: SYN exchange with the SYN/ACK packet marked, >>> but with the ECN mark ignored by the TCP initiator. >>> >>> Thus, to be explicit, when a TCP connection includes an initiator >>> that supports ECN but *does not* support ECN-Capability for SYN/ACK >>> packets, in combination with a responder that *does* support ECN- >>> Capabililty for SYN/ACK packets, it is possible that the >>>ECN-Capable >>> SYN/ACK packets will be marked rather than dropped in the network, >>> and that the responder will not learn about the ECN mark on the >>> SYN/ACK packet. This would not be a problem >> >>s/ in a scenario with/ with machines serving / > >I changed "scenario" to "environment" > >>> mostly long-lived TCP connections, but it would be more problematic >> >>s/in a scenario where all /with an ECN+ TCP responder where most / > >I changed "scenario" to "environment" here also, and changed >"all" to "much". > >>>TCP connections consisted of >> >>at most > >I left it as it. If all TCP connections used an initial window of >one data packet, or had only one data packet to send, for example, >then ECN+ wouldn't have as large backwards compatibility problems. >(That is, the congestion control situation would be pretty bad with >or without backwards compatibility problems with ECN+.) > >>>four data >>> packets, and the TCP responder was ready to send its data packets >>> immediately after the SYN/ACK exchange. >> >>If correctly responding ECN-capable traffic shared a bottleneck with >>traffic from such an ECN+ machine, its rate would be continually >>beaten down by the ECN+ machine's reduced congestion response. > >Yep. > >>>Of course, with *severe* >>> congestion, the SYN/ACK packets would likely be dropped rather than >>> ECN-marked at the congested router, preventing the TCP responder >>>from >>> adding to the congestion by sending its initial window of four data >>> packets. >> >>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ \/\ > >- Sally >http://www.icir.org/floyd/ ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jan 08 19:50:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCP9E-0002Zl-Qc; Tue, 08 Jan 2008 19:50:24 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JCP9E-0002Zg-7M for tcpm-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 19:50:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCP9D-0002YZ-PL for tcpm@ietf.org; Tue, 08 Jan 2008 19:50:23 -0500 Received: from smtpoutm.mac.com ([17.148.16.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCP9C-0003LV-OD for tcpm@ietf.org; Tue, 08 Jan 2008 19:50:23 -0500 Received: from mac.com (asmtp004-s [10.150.69.67]) by smtpoutm.mac.com (Xserve/smtpout007/MantshX 4.0) with ESMTP id m090oBvs000831; Tue, 8 Jan 2008 16:50:16 -0800 (PST) Received: from [192.168.1.101] (adsl-70-132-0-53.dsl.snfc21.sbcglobal.net [70.132.0.53]) (authenticated bits=0) by mac.com (Xserve/asmtp004/MantshX 4.0) with ESMTP id m090o8tl005023; Tue, 8 Jan 2008 16:50:08 -0800 (PST) In-Reply-To: <200801090007.m09079NU032330@bagheera.jungle.bt.co.uk> References: <9ee77c9bed4cf392d49f6aeff4774470@mac.com> <20080104140011.B80A7328DFE@lawyers.icir.org> <200801041804.m04I4O2L008832@bagheera.jungle.bt.co.uk> <200801060012.m060Bc8e031128@bagheera.jungle.bt.co.uk> <1bb51f3f2858e4828998faf9afb6a745@mac.com> <200801090007.m09079NU032330@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [tcpm] Re: draft-ietf-tcpm-ecnsyn-03.txt backwards compatibility Date: Tue, 8 Jan 2008 16:50:07 -0800 To: Bob Briscoe X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: tcpm@ietf.org, Aleksandar Kuzmanovic , "K. K. Ramakrishnan" , Amit Mondal , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Bob - > I'll accept all your responses... > > Except, I probably didn't explain well why I didn't like: > "This would not be a problem in an environment with mostly long-lived > TCP connections..." > > This is ambiguous as to whether it means the competing flows are long > lived or the ECN+ server's flows are long lived. The problem is short > flows from the ECN+server. The problem hits both short and long > competing flows. Great, I will add a clarification. Mark, is it time for me to submit the revised internet-draft? - Sally > At 05:21 08/01/2008, Sally Floyd wrote: >> Bob - >> >>> The new text outlines the issues well (I've suggested some minor >>> changes inline - all in the para below Fig 2). >>> >>> But I'm not a great fan of writing long complicated text in standards >>> track documents that describes a problem, when it's sort of hinting >>> that implementers don't actually need to do anything about it. One >>> way >>> round this would be to move this text about incremental deployment to >>> an appendix. >> >> Yep, I will do that. >>> >>> Point (3) is a good one that I hadn't thought of. >>> >>> Here's strawman text for a solution that could be put in the body. >>> I've used the terms 'TCP clients' and 'TCP servers' for machines used >>> mostly as initiators or responders respectively: >>> >>> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ >>> \/ \/\ >>> "There is a potential incremental deployment problem in circumstances >>> we believe will be unlikely, described in (Appendix X). In monitoring >>> the deployment of ECN and ECN+, if significant numbers of queues have >>> ECN turned on and if we find that large numbers of TCP clients still >>> have legacy ECN enabled while significant numbers of TCP servers have >>> upgraded to ECN+, the management application described below could be >>> deployed on ECN+ servers, particularly if most of the flows served >>> fit >>> within an initial window. >>> >>> The management application could monitor the average fraction of ACKs >>> with ECE set in response to: >>> 1. a SYN/ACK >>> 2. the segments in the initial window. >>> If the former fraction was significantly lower than the latter, the >>> management application could switch ECN+ back to ECN, perhaps >>> requiring manual intervention rather than automatic switching. >>> >>> Once the community deemed that the deployment situation had become >>> safer for ECN+, server administrators could switch ECN+ back on, >>> either leaving the managment application running, or eventually >>> removing the management application. >>> >>> Therefore, all ECN+ TCP implementations SHOULD provide the following >>> management interfaces, in order to ease installation of such a >>> management application after the TCP has been upgraded to ECN+: >>> o An interface to turn ECN+ on or off; >>> o An interface to read a count of only those ACKs with ECE >>> set >>> that were responses to SYN/ACKs." >>> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ >>> \/ \/\ >>> >>> I said this is strawman text, because I'm not sure I even support it >>> myself. I'm just trying to work through the minimum implementers >>> would >>> need to do about incremental deployment other than 'nothing'. >> >> I am inclined to leave that out, for now. >> Unless others have other opinions. >> >> But I did add a moderated version as follows: >> >> "The TCP implementation using ECN-Capable SYN/ACK packets SHOULD >> include a management interface to allow the use of ECN to be turned >> off for SYN/ACK packets. This is to deal with possible backwards >> compatibility problems such as those discussed in Appendix B." >> >>> The alternative of doing absolutely nothing about incremental >>> deployment right now is still possible. The above required management >>> interfaces can be added by upgrading the kernel any time. I just >>> figured the above might be worthwhile to ease installation of a >>> little >>> monitoring application, so at least sysadmins can simply test whether >>> there is a problem if they choose to. >>> >>> [BTW, there are cases where the approach in (3) wouldn't work (e.g. >>> if >>> SYN/ACKs had a significantly lower probability of ECN marking than >>> data packets). But I really don't think we should start down that >>> rat-hole in this I-D - it would be like describing a pimple on a spot >>> on a flea.] >>> >>> A little more inline... >>> >>> At 19:50 04/01/2008, Sally Floyd wrote: >>>> Bob - >>>> >>>> ... >>>>> I've noted a general lack of concern/interest here about >>>>> standardising a congestion control that doesn't respond to >>>>> congestion in a set of circumstances that might happen or might >>>>> not. >>>>> I assume this is because of the glacial deployment of ECN so far. >>>>> >>>>> If the world turns out differently to the above assumptions, we >>>>> will >>>>> have to think of a plan B pretty snappish. >>>>> >>>>> But I'm not going to hold this up further, as ECN+ is generally a >>>>> good idea, and the other alternatives for incremental deployment >>>>> are >>>>> cumbersome. >>>> >>>> I think it is safe not to use a flag for ECN-Capable SYN/ACK >>>> packets, >>>> but I wouldn't have any problems with using a flag either. >>>> >>>> The revised text for draft-ietf-tcpm-ecnsyn is attached below. >>>> >>>> - Sally >>>> http://www.icir.org/floyd/ >>>> >>>> >>>> Backwards compatibility: >>> >>> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ >>> \/ \/ >>> >>> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ >>> \/ \/\ >>> >>>> Figure 2: SYN exchange with the SYN/ACK packet marked, >>>> but with the ECN mark ignored by the TCP initiator. >>>> >>>> Thus, to be explicit, when a TCP connection includes an initiator >>>> that supports ECN but *does not* support ECN-Capability for >>>> SYN/ACK >>>> packets, in combination with a responder that *does* support ECN- >>>> Capabililty for SYN/ACK packets, it is possible that the >>>> ECN-Capable >>>> SYN/ACK packets will be marked rather than dropped in the >>>> network, >>>> and that the responder will not learn about the ECN mark on the >>>> SYN/ACK packet. This would not be a problem >>> >>> s/ in a scenario with/ with machines serving / >> >> I changed "scenario" to "environment" >> >>>> mostly long-lived TCP connections, but it would be more >>>> problematic >>> >>> s/in a scenario where all /with an ECN+ TCP responder where most / >> >> I changed "scenario" to "environment" here also, and changed >> "all" to "much". >> >>>> TCP connections consisted of >>> >>> at most >> >> I left it as it. If all TCP connections used an initial window of >> one data packet, or had only one data packet to send, for example, >> then ECN+ wouldn't have as large backwards compatibility problems. >> (That is, the congestion control situation would be pretty bad with >> or without backwards compatibility problems with ECN+.) >> >>>> four data >>>> packets, and the TCP responder was ready to send its data packets >>>> immediately after the SYN/ACK exchange. >>> >>> If correctly responding ECN-capable traffic shared a bottleneck with >>> traffic from such an ECN+ machine, its rate would be continually >>> beaten down by the ECN+ machine's reduced congestion response. >> >> Yep. >> >>>> Of course, with *severe* >>>> congestion, the SYN/ACK packets would likely be dropped rather >>>> than >>>> ECN-marked at the congested router, preventing the TCP responder >>>> from >>>> adding to the congestion by sending its initial window of four >>>> data >>>> packets. >>> >>> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ >>> \/ \/\ >> >> - Sally >> http://www.icir.org/floyd/ > > _______________________________________________________________________ > _____ > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 > - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jan 08 20:36:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCPs1-0002aH-ED; Tue, 08 Jan 2008 20:36:41 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JCPs0-0002ZU-Kc for tcpm-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 20:36:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCPs0-0002YT-95 for tcpm@ietf.org; Tue, 08 Jan 2008 20:36:40 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCPrz-0003zu-QN for tcpm@ietf.org; Tue, 08 Jan 2008 20:36:40 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id m091aXPo009124; Tue, 8 Jan 2008 17:36:34 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 162A613E8F98; Tue, 8 Jan 2008 20:36:28 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D06BD32F2AC; Tue, 8 Jan 2008 20:34:36 -0500 (EST) To: Sally Floyd From: Mark Allman Subject: Re: [tcpm] Re: draft-ietf-tcpm-ecnsyn-03.txt backwards compatibility In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Centerfield MIME-Version: 1.0 Date: Tue, 08 Jan 2008 20:34:36 -0500 Message-Id: <20080109013436.D06BD32F2AC@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tcpm@ietf.org, Aleksandar Kuzmanovic , Amit Mondal , "K. K. Ramakrishnan" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1269517656==" Errors-To: tcpm-bounces@ietf.org --===============1269517656== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Mark, is it time for me to submit the revised internet-draft? Yep---that sounds like the right thing to do. Thanks! allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHhCSsWyrrWs4yIs4RAgJxAJ4+5DPnkzEyYS9Aqm7SmQplhjvdMwCdGkuA cNRm2OLWr/L1JDz/sevazR4= =S34u -----END PGP SIGNATURE----- --=_bOundary-- --===============1269517656== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1269517656==-- From tcpm-bounces@ietf.org Tue Jan 08 21:30:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCQhg-0001QX-IY; Tue, 08 Jan 2008 21:30:04 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JCQhf-0001QO-88 for tcpm-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 21:30:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCQhe-0001QG-U8; Tue, 08 Jan 2008 21:30:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCQhe-0005wg-Fp; Tue, 08 Jan 2008 21:30:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 5E5FF26E65; Wed, 9 Jan 2008 02:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JCQhe-0006NA-9Y; Tue, 08 Jan 2008 21:30:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 08 Jan 2008 21:30:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-ecnsyn-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets Author(s) : S. Floyd, I. Property Filename : draft-ietf-tcpm-ecnsyn-04.txt Pages : 26 Date : 2008-01-08 This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 only specifies setting an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmit timeout, this document specifies the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmit timeout for a connection that has not yet started placing a load on the network. The sender of the SYN/ACK packet must respond to a report of an ECN-marked SYN/ACK packet by reducing its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. This document is intended to update RFC 3168. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-ecnsyn-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-ecnsyn-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-ecnsyn-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-08212201.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-ecnsyn-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-ecnsyn-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-08212201.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Tue Jan 08 23:41:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCSkB-00063g-Ig; Tue, 08 Jan 2008 23:40:47 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JCSk9-00063a-Up for tcpm-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 23:40:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCSk9-00063S-Kr for tcpm@ietf.org; Tue, 08 Jan 2008 23:40:45 -0500 Received: from smtpoutm.mac.com ([17.148.16.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCSk7-0007HL-DX for tcpm@ietf.org; Tue, 08 Jan 2008 23:40:45 -0500 Received: from mac.com (asmtp002-s [10.150.69.65]) by smtpoutm.mac.com (Xserve/smtpout017/MantshX 4.0) with ESMTP id m094eW6P025080; Tue, 8 Jan 2008 20:40:32 -0800 (PST) Received: from [192.168.1.101] (adsl-70-132-0-53.dsl.snfc21.sbcglobal.net [70.132.0.53]) (authenticated bits=0) by mac.com (Xserve/asmtp002/MantshX 4.0) with ESMTP id m094eU3I016347; Tue, 8 Jan 2008 20:40:30 -0800 (PST) In-Reply-To: <20080109013436.D06BD32F2AC@lawyers.icir.org> References: <20080109013436.D06BD32F2AC@lawyers.icir.org> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <27fa302bfe7047223845594c72c07097@mac.com> Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [tcpm] Re: draft-ietf-tcpm-ecnsyn-03.txt backwards compatibility Date: Tue, 8 Jan 2008 20:40:28 -0800 To: mallman@icir.org X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Aleksandar Kuzmanovic , "K. K. Ramakrishnan" , Amit Mondal , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org >> Mark, is it time for me to submit the revised internet-draft? > > Yep---that sounds like the right thing to do. Done. It is at: http://tools.ietf.org/html/draft-ietf-tcpm-ecnsyn-04 - Sally http://www.icir.org/floyd/ The diffs: NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION. Changes from draft-ietf-tcpm-ecnsyn-03: * General editing. This includes using the terms "initiator" and "responder" for the two ends of the TCP connection. Feedback from Alfred Hoenes. * Added some text to the backwards compatibility discussion, now in Appendix B, about the pros and cons of using a TCP flag for the TCP initiator to signal that it understands ECN-Capable SYN/ACK packets. The consensus at this time is not to use such a flag. Also added a recommendation that TCP implementations include a management interface to turn off the use of ECN for SYN/ACK packets. From email from Bob Briscoe. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 10 21:09:22 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD9Kd-0001zz-Bu; Thu, 10 Jan 2008 21:09:15 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JD9Kc-0001zt-9l for tcpm-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 21:09:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD9Kb-0001zl-Vw for tcpm@ietf.org; Thu, 10 Jan 2008 21:09:13 -0500 Received: from gateway.tr-sys.de ([213.178.172.147] helo=WOTAN.TR-Sys.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JD9Ka-0003Ti-Qd for tcpm@ietf.org; Thu, 10 Jan 2008 21:09:13 -0500 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA267747295; Fri, 11 Jan 2008 03:08:15 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id DAA11330; Fri, 11 Jan 2008 03:08:10 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200801110208.DAA11330@TR-Sys.de> Subject: Re: [tcpm] RE: TCP secure To: ananth@cisco.com, rrs@cisco.com, mdalal@cisco.com Date: Fri, 11 Jan 2008 03:08:10 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hello all, I generally agree with the recent changes performed for draft-ietf-tcpm-tcpsecure-09, yet in the newly added AS (Section 1.1), the language should be improved based on the rationale below. a) "The mitigations presented in" and "talks about" almost mean the same, but even worse, combined in the first line, the sentence does not parse. Because "The mitigations" re-occurs in the next line, I suggest to drop the first occurrence. b) "Solutions to .. [attacks]" does not seem to be very meaningful. I therefore also suggest to replace "the solutions to the same" by "suitable defenses against these". Hopefully, this will increase the clarity, and add to the readability of the text. c) "... devices where the TCP connections are most vulnerable ..." pretends to not admit the co-existence with less vulnerable TCP connections and the temporal variation over all the story. I suggest to talk about "... devices that regularly have to maintain TCP connections of the kind most vulnerable ...". d) I also suggest to delete the subsequent "Some", because the following explanation only details *one* specific kind of TCP connections particularly vulnerable. e) In the middle of the original paragraph, I suggest adding an "and" to make the syntax and semantics of the sentence unambiguous. Taking that into account, I recommend changing: OLD: | The mitigations presented in this document talks about some known in- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ~~~~~~~~~~~ | window attacks and the solutions to the same. The mitigations ^^^^^^^^^^^^^^^^^^^^^^^^^ suggested in this draft SHOULD be implemented in devices where the vvvvv ^^^^^^^^^^ TCP connections are most vulnerable to the attacks described in this document. Some examples of such TCP connections are the ones that ^^^^^ | tend to be long-lived where the connection end points can be ^ determined, in cases where no auxiliary anti-spoofing protection mechanisms like TCP MD5 [RFC2385] can be deployed. These mitigations MAY be implemented in other cases. NEW: | This document talks about some known in-window attacks and suitable | defenses against these. The mitigations suggested in this draft | SHOULD be implemented in devices that regularly need to maintain TCP | connections of the kind most vulnerable to the attacks described in | this document. Examples of such TCP connections are the ones that | tend to be long-lived and where the connection end points can be determined, in cases where no auxiliary anti-spoofing protection mechanisms like TCP MD5 [RFC2385] can be deployed. These mitigations MAY be implemented in other cases. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 10 22:29:51 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDAaa-0003pm-V5; Thu, 10 Jan 2008 22:29:48 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JDAaa-0003ph-Bn for tcpm-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 22:29:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDAaa-0003pZ-29 for tcpm@ietf.org; Thu, 10 Jan 2008 22:29:48 -0500 Received: from usfws1.systemmetrics.com ([66.135.227.114] helo=vbn.0059755.lodgenet.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDAaY-0004Pf-La for tcpm@ietf.org; Thu, 10 Jan 2008 22:29:48 -0500 Received: from [10.2.5.165] (helo=[10.2.5.165]) by vbn.0059755.lodgenet.net with esmtp (Exim 3.34 #1) id 1JDAaQ-0000Gn-00; Thu, 10 Jan 2008 17:29:38 -1000 Message-ID: <4786E29B.7060608@isi.edu> Date: Thu, 10 Jan 2008 19:29:31 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Alfred_=3F?= Subject: Re: [tcpm] RE: TCP secure References: <200801110208.DAA11330@TR-Sys.de> In-Reply-To: <200801110208.DAA11330@TR-Sys.de> X-Enigmail-Version: 0.95.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tcpm@ietf.org, rrs@cisco.com, mdalal@cisco.com, ananth@cisco.com X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1040780268==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1040780268== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE376EABCAAE2A4D2D747EADB" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE376EABCAAE2A4D2D747EADB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable The references continue to be out of date. 1. antispoof has been an RFC (4953) since July. 2. TCP-MD5 has a replacement (TCP-AO) that was discussed in Nov in=20 Vancouver; that I-D should be noted, esp. where TCP-MD5 is discussed as=20 an alternate solution. Joe --------------enigE376EABCAAE2A4D2D747EADB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHhuKbE5f5cImnZrsRAtgVAJ4sgCUQl0veBF+RY+sa8T09oyIKfwCg1GQr QOX9OiUuGNXdYACbg6dkKjk= =aShH -----END PGP SIGNATURE----- --------------enigE376EABCAAE2A4D2D747EADB-- --===============1040780268== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1040780268==-- From tcpm-bounces@ietf.org Fri Jan 11 01:55:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDDnA-0001e3-Ii; Fri, 11 Jan 2008 01:55:00 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JDDn9-0001dy-5c for tcpm-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 01:54:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDDn8-0001dp-P2 for tcpm@ietf.org; Fri, 11 Jan 2008 01:54:58 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDDn8-0007Y5-DN for tcpm@ietf.org; Fri, 11 Jan 2008 01:54:58 -0500 X-IronPort-AV: E=Sophos;i="4.24,270,1196668800"; d="scan'208";a="34052033" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 10 Jan 2008 22:54:57 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m0B6svN1006426; Thu, 10 Jan 2008 22:54:57 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0B6svcV029319; Fri, 11 Jan 2008 06:54:57 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 22:54:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] RE: TCP secure Date: Thu, 10 Jan 2008 22:54:51 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5804880620@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4786E29B.7060608@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] RE: TCP secure Thread-Index: AchUAjcVrenfrRJ5SJ6oxu+uhF+GAQAGCqvQ References: <200801110208.DAA11330@TR-Sys.de> <4786E29B.7060608@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" , "Alfred ?" X-OriginalArrivalTime: 11 Jan 2008 06:54:57.0122 (UTC) FILETIME=[E06F9420:01C8541E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1136; t=1200034497; x=1200898497; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20RE=3A=20TCP=20secure |Sender:=20; bh=k2GwtJGABCK155FGql3T6Fg24g0gHOPjZyMAJr92zCg=; b=EmL4bLj1lWTxwxgA3zXtQ5X48BWVJnlv5tH6sHbu80YsgHKsChfYyvbyWK l8HoDqq+Rx1gJ65Fg8UuNmO9pizRYq9wiGIAkUUO4W/qBUKgT03GHEIokF7v m6lXgV+GPk; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tcpm@ietf.org, "Randall Stewart \(rrs\)" , "Mitesh Dalal \(mdalal\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu]=20 > Sent: Thursday, January 10, 2008 7:30 PM > To: Alfred ? > Cc: Anantha Ramaiah (ananth); Randall Stewart (rrs); Mitesh=20 > Dalal (mdalal); tcpm@ietf.org > Subject: Re: [tcpm] RE: TCP secure >=20 > The references continue to be out of date. >=20 > 1. antispoof has been an RFC (4953) since July. Point taken, this can be done during the next revision whenever that is. >=20 > 2. TCP-MD5 has a replacement (TCP-AO) that was discussed in=20 > Nov in Vancouver; that I-D should be noted, esp. where=20 > TCP-MD5 is discussed as an alternate solution. TCP secure just mentions TCP MD5 as an example of an already deployed existing security mechanism. There may be many ways available to protect TCP connections and it is NOT the purpose or motivation of TCP secure to list all of them. If the "antispoof" draft was still in the works I would have suggested to list AO in it. But if the workgroup strongly feels that TCP secure should make a note of AO, I am willing to add it, but at the moment I stand unconvinced. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jan 21 17:44:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH5N4-0002yF-AO; Mon, 21 Jan 2008 17:44:02 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JH5N3-0002y9-HK for tcpm-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 17:44:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH5N3-0002y1-7O for tcpm@ietf.org; Mon, 21 Jan 2008 17:44:01 -0500 Received: from c00l3r.networx.ch ([62.48.2.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JH5N1-00009E-HJ for tcpm@ietf.org; Mon, 21 Jan 2008 17:44:01 -0500 Received: (qmail 59138 invoked from network); 21 Jan 2008 22:05:42 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Jan 2008 22:05:42 -0000 Message-ID: <47952032.3030809@freebsd.org> Date: Mon, 21 Jan 2008 23:44:02 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [tcpm] Ordering of SACK blocks, flushing of reassembly queue after inactivity X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I'm currently rewriting the tcp reassembly queue of FreeBSD (which is still almost 4.4BSD verbatim) to deal with large socket buffers and to be more economic with kernel memory in the form of mbufs. [1] The new code is based on blocks of contiguous segment data instead of a list of received out-of-order segment that has to be traversed to find the right place for the new segment. It also does all the obvious optimizations based on the chance of things happening. Now there are two issues I'd like to solicit the input from this wg. The first is the ordering of SACK blocks. The block based reassembly queue lends itself to generate the SACK option from. The blocks are ordered ascending from the first segment closest to rcv_nxt. Per RFC 2018 Section 4 the first SACK block MUST be the one with the most recent addition to it. This is easily done by adding a pointer to the block last modified. However a bit later it says the following SACK blocks SHOULD be also in order of their 'recentness' while also specifying they may be listed in arbitrary order. Now tracking this information in the block based and sequence number ordered reassembly queue it a bit more involved and I wonder if it really necessary and useful. In general the SACK blocks tend to be ordered sequentially after the first SACK block in single random loss cases. Only in packet reordering cases, possibly mixed with loss, this may not be the case. On the other hand the most valuable information for the sender are the blocks closest to rcv_nxt so it can fill the hole and complete the sequence space. While the RFC leaves me free to do as I please I wonder if there are observations or rationales that clearly show the the ordering by recentness to be better than sequential ordering after the first SACK block? The second is how long to hold onto data in the reassembly queue. The general theme here is resource exhaustion be it through malicious activity or just end points that drop off the net. I think we can all agree that holding onto reassembly queue data until the session times out (if ever) is not really useful considering the overall resource constrains. The question now is after what time to flush the reassembly queue (and to send an appropriate ACK)? A range of options are available. On the wide side we have a flush timeout of something like 2 times MSL. On the small side we can go down to the current calculated retransmit timeout value as seen from our side. Also of importance is from where the timeout is calculated. From the time the first segment arrived in the reassembly queue (resetting when rcv_nxt is advanced), or from the arrival time of the most recent segment. For the moment and testing I've chosen the former at four times retransmit timeout as something that probably marks the boundary between spurious network losses or partitioning and longer-term disconnect or malicious activity. Is any empirical data available on abandoned sessions with data in the reassembly queue? What is your opinion and rationale on this? [1] http://perforce.freebsd.org/fileLogView.cgi?FSPC=//depot/projects/tcp_reass/netinet/tcp_reass.c -- Andre andre@freebsd.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jan 22 10:55:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHLSe-0001at-DS; Tue, 22 Jan 2008 10:54:52 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1J5pHh-0002zT-Bq for tcpm-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 16:19:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5pHg-0002zL-Qa for tcpm@ietf.org; Fri, 21 Dec 2007 16:19:56 -0500 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5pHg-0006GD-2y for tcpm@ietf.org; Fri, 21 Dec 2007 16:19:56 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=XMBkQLYJGkLTQSrA7qZHV0Y7L1gw+HXVf3Ys6rFXIkQJuD9MS8U2gfXnk0nOc4E1; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J5pHb-0001Eq-SR; Fri, 21 Dec 2007 16:19:52 -0500 Received: from 216.218.227.40 by webmail.pas.earthlink.net with HTTP; Fri, 21 Dec 2007 16:19:51 -0500 Message-ID: <27150782.1198271991859.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Date: Fri, 21 Dec 2007 13:19:51 -0800 (GMT-08:00) From: erblichs To: Lars Eggert , ext John Heffner , tcpm@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec794a5a3860c9a0dd7fca42c0f9fd417854350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.36 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 X-Mailman-Approved-At: Tue, 22 Jan 2008 10:54:50 -0500 Cc: erblichs , Mark Allman Subject: [tcpm] Re: [Tsvwg] Re: RFC 3465 : ABC : ACK'd Segments Just Smaller than SMSS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erblichs List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Ok group, With the understanding that at least SOME agreement of IMPLEMENTATION or ARCHECTURE change should be done, and until that occurs and maybe not even after that, the default for ABC is off, so can I get some feedback on first one code snippet. Yes, again within Linux.. Their is a comparison check for bytes acked and 2*MSS in the slow_start function.. So, this must be obvious to someone, but in my naive way of thinking that comparison only needs to check ONLY for greater than MSS. If two small segs are implicitly each acked then they theoretically can SUM larger than 1 MSS and be less than 2*MSS. IT is not possible to ACK without loss of a previous ACK, to ACK MSS sized segment plus just a few bytes. Thus, by definition their must have been at least two partial sized segment being ACK'ed. Thus, this one ACK was a DELACK!!!! Right? If non MSS sized segments are sent and ACKed,, then 3 or more implicit ACKs might be necessary for 2*MSS to be valid. Right? Then why assume that ONLY if a DELACK is generated that it is for bytes that consume at least 2 full sized segments? Secondly, with a ACK clocking mechanism, and we are WANT to keep as many ACKs inflight, why wouldn't we return EARLY IFF ONLY bytes-acked was equal to 0? This would have the same fucntionality as non-ABC code, right? I understand about piggybacking data, and such, and in theory not wanting Nagle/almost runt sized segments as the avg sized seg in flight, but, in IPv4 we have fragmentation and most normal apps are not going to ONLY send MSS sized segs. Right? Should we penalize ABC for being aware of byte counts? I thought the best thing of ABC was the ability to inform that a DELACK was for 2 previously sent segs. With these changes, I think I see, I think I see, a fairly decent set of performance numbers. Any yes, it reduces latency. But as stated in a earlier thread, that their is a tradeoff of bandwidth. However, just because we may push more packets/segments, due to smaller sizes, I am not sure that the smaller MSS sized segments will be significant enough to decrease the packet per second rates and will actually help in low inflight conditions. Mitchell Erblich -----Original Message----- >From: Lars Eggert >Sent: Dec 17, 2007 11:56 PM >To: ext John Heffner >Cc: erblichs , Mark Allman >Subject: Re: [Tsvwg] Re: RFC 3465 : ABC : ACK'd Segments Just Smaller than SMSS > >Folks, > >if you want to continue this thread, please do so on tcpm@ietf.org. > >Lars > >On 2007-12-17, at 23:02, ext John Heffner wrote: > >> erblichs wrote: >>> -----Original Message----- >>>> From: Mark Allman >>>> Sent: Dec 14, 2007 7:54 PM >>>> To: erblichs >>>> Cc: tsvwg@ietf.org >>>> Subject: Re: RFC 3465 : ABC : ACK'd Segments Just Smaller than SMSS >>>> >>>>> I think I am looking into the case where the ACK is just >>>>> slightly smaller than SMSS where ABC is utilized and cwnd is >>>>> not >>>>> growing. This is not an attack. At what point, percentage >>>>> wise, >>>>> should a partial segment be considered large enough to allow >>>>> cwnd to increase, without exposing one to the "ACK Division" >>>>> attack? >>>> I don't follow this. ABC does increase cwnd. If an >>>> implementation is >>>> using ABC and cwnd is not increasing then there is a bug, I think. >>>> Just to be clear, consider the case where we start cwnd at SMSS >>>> bytes, >>>> packets of size SMSS-5 bytes and use an initial window of just one >>>> packet (to keep things easy). So, >>>> >>>> RTT 1: >>>> cwnd = SMSS >>>> transmit segment 1 (SMSS-5 bytes) >>>> >>>> RTT 2: >>>> ack from segment 1 arrives >>>> cwnd = (2*SMSS) - 5 >>>> trasnmit segment 2 (SMSS-5 bytes) >>>> trasnmit segment 3 (SMSS-5 bytes) >>>> (5 bytes of unused cwnd left) >>>> >>>> RTT 3: >>>> ack from segments 2 & 3 arrive (either as one ack packet or two) >>>> cwnd = SMSS + (3 * (SMSS-5)) >>>> = (4*SMSS)-15 >>>> trasnmit segment 4 (SMSS-5 bytes) >>>> trasnmit segment 5 (SMSS-5 bytes) >>>> trasnmit segment 6 (SMSS-5 bytes) >>>> trasnmit segment 7 (SMSS-5 bytes) >>>> (5 bytes of unused cwnd left) >>>> >>>> (note, this step assumes an ABC limit of 2*SMSS; applying L=1*SMSS >>>> should be easy enough to work out) >>>> >>>> So, I don't follow the problem you're getting at here. >>>> >>>> allman >>>> >>>> >>>> >>> Mark and group, >>> Sorry about the Linux implementation code, but >>> within 2.6.23+ within tcp_cong.c : tcp_slow_start() >>> their is the check: >>> if (sysctl_tcp_abc && tp->bytes_acked < tp->mss_cache) >>> return; >>> below is where the congestion window increases. >>> I assume this is based on the 3.3 section against >>> ACk Division type attacks. >>> So... If the bytes acked are just 1 byte smaller than >>> the mss, this looks like the congestion window won't >>> increase in size and/or we are decreasing the number >>> of inflight segments. >>> Is this a bug??? >>> Thus, if any bytes are ACKed, then minimally the two >>> headers (IP & TCP), plus the interpacket gap, constitute >>> some bandwidth consumption and IFF we aren't concerned >>> with a "ACK Division attack", thus if their is only small >>> segments transversing the wire, do we ever grow the >>> congestion window? Yes, we are fighting with populating >>> the pipeline with smaller sized segments generated by >>> a well known networking protocol. >> >> >> In the Linux implementation, the value tp->bytes_acked is cumulative >> across ACKs, not the number of bytes acknowledged by the current >> ACK. (Its value is reduced when cwnd is increased.) >> >> If two ACKs are received of MSS-1 bytes, bytes_acked will be >> increased by 2*(MSS-1) > MSS, so the test above from the slow-start >> code will be false, and cwnd will be increased. >> >> -John >> >> > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jan 22 10:55:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHLSe-0001b1-JR; Tue, 22 Jan 2008 10:54:52 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JHLGK-0001W4-Td for tcpm-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 10:42:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHLGK-0001Vl-JN for tcpm@ietf.org; Tue, 22 Jan 2008 10:42:08 -0500 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHLGJ-0006SQ-WD for tcpm@ietf.org; Tue, 22 Jan 2008 10:42:08 -0500 Received: from mauser.ipx.ath.cx ([75.186.40.34]) by hrndva-omta01.mail.rr.com with ESMTP id <20080122154207.MMDF11942.hrndva-omta01.mail.rr.com@mauser.ipx.ath.cx>; Tue, 22 Jan 2008 15:42:07 +0000 Received: by mauser.ipx.ath.cx (Postfix, from userid 500) id 1AC56181C8; Tue, 22 Jan 2008 10:42:07 -0500 (EST) Date: Tue, 22 Jan 2008 10:42:07 -0500 From: Joshua Blanton To: Andre Oppermann Subject: Re: [tcpm] Ordering of SACK blocks, flushing of reassembly queue after inactivity Message-ID: <20080122154207.GD4320@mauser.ipx.ath.cx> Mail-Followup-To: Andre Oppermann , tcpm@ietf.org References: <47952032.3030809@freebsd.org> MIME-Version: 1.0 In-Reply-To: <47952032.3030809@freebsd.org> X-Operating-System: Linux User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-Mailman-Approved-At: Tue, 22 Jan 2008 10:54:50 -0500 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joshua Blanton List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0563638091==" Errors-To: tcpm-bounces@ietf.org --===============0563638091== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="brEuL7wsLY8+TuWz" Content-Disposition: inline --brEuL7wsLY8+TuWz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I don't have a good answer to your first question (other than to mention that, if you always send the most-recently-modified SACK regions, you ensure that they're sent multiple times - which is the only quasi-reliability you can create on the ACK path), but I would like to address the second. Andre Oppermann wrote: > The second is how long to hold onto data in the reassembly queue. > The general theme here is resource exhaustion be it through malicious > activity or just end points that drop off the net. I think we can > all agree that holding onto reassembly queue data until the session > times out (if ever) is not really useful considering the overall > resource constrains. The question now is after what time to flush > the reassembly queue (and to send an appropriate ACK)? A range of > options are available. On the wide side we have a flush timeout > of something like 2 times MSL. On the small side we can go down to > the current calculated retransmit timeout value as seen from our side. > Also of importance is from where the timeout is calculated. From the > time the first segment arrived in the reassembly queue (resetting when > rcv_nxt is advanced), or from the arrival time of the most recent > segment. For the moment and testing I've chosen the former at four > times retransmit timeout as something that probably marks the boundary > between spurious network losses or partitioning and longer-term > disconnect or malicious activity. Is any empirical data available on > abandoned sessions with data in the reassembly queue? What is your > opinion and rationale on this? Well, I actually disagree that holding onto reassembly queue data is a lost cause, even after long periods of inactivity - so perhaps we don't all agree :-). Certainly you could tell *after* the fact that holding such data was a fool's errand, if the connection is terminated; until that point, there's no reason to necessarily assume that the lack of progress in the connection is permanent. In general, I would expect an operating system to hold on to reassembly data for forever, assuming that there's no memory resource concern that makes the buffers valuable... To flush data simply because wall-clock time has elapsed doesn't make sense to me, since I've seen many traces where "long" time periods have elapsed and then connections suddenly resume. If there's no global "we're running out of memory" trigger available for a given OS, a stack could set a timer to fire at some arbitrary time (4*RTO, for instance) and check for memory pressure - *if* it exists, go ahead and flush the data. I don't have any data showing how much reassembly data is left hanging around when a session is abandoned, but I have looked at quite a few traces trying to find SACK renegs (which would be the result of your data flushing). In general, I believe that a scheme such as you're proposing is not used; other than some traces that I've found that p0f identifies as being FreeBSD receivers, there doesn't appear to be a solid link between connection progress timeouts and reneging. I don't know the FreeBSD stack well enough to say that, in its current implementations, it definitely flushes reassembly queue data based on a timer - but I suspected that it did, and your question reinforces my suspicion. If I am correct, and FreeBSD currently (5.x and 6.x) times out reassembly data as you're proposing, I've seen traces where this actually impedes a connection's recovery - so I vote against such a scheme. Again, I have no problem with stacks flushing out-of-order data in the face of a low-memory condition. Beyond that, I'd have to see some pretty convincing data that "long pauses == connection that will terminate without finishing," which is what I feel you're proposing. Josh --brEuL7wsLY8+TuWz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHlg7P1dp8qWK2G7QRAjniAKDLoEE2hxZxAS0HWklGY3RHle4/NwCfQzX0 o0bWDroL6qzcnDX/HByzZrY= =1c6W -----END PGP SIGNATURE----- --brEuL7wsLY8+TuWz-- --===============0563638091== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0563638091==-- From tcpm-bounces@ietf.org Tue Jan 22 17:40:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHRn8-0004EG-Az; Tue, 22 Jan 2008 17:40:26 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JHRn7-0004E6-29 for tcpm-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 17:40:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHRn6-0004Db-6Y for tcpm@ietf.org; Tue, 22 Jan 2008 17:40:24 -0500 Received: from [2001:5e8:2:42:2e0:81ff:fe30:e898] (helo=mailer2.psc.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHRn3-0002ST-Pp for tcpm@ietf.org; Tue, 22 Jan 2008 17:40:23 -0500 Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer2.psc.edu (8.14.2/8.13.3) with ESMTP id m0MMeJAD021806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jan 2008 17:40:20 -0500 (EST) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.13.1) with ESMTP id m0MMeJPw008662; Tue, 22 Jan 2008 17:40:19 -0500 Date: Tue, 22 Jan 2008 17:40:19 -0500 (EST) From: Matt Mathis To: Andre Oppermann Subject: Re: [tcpm] Ordering of SACK blocks, flushing of reassembly queue after inactivity In-Reply-To: <47952032.3030809@freebsd.org> Message-ID: References: <47952032.3030809@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > The first is the ordering of SACK blocks. The block based reassembly > queue lends itself to generate the SACK option from. The blocks are > ordered ascending from the first segment closest to rcv_nxt. Per RFC > 2018 Section 4 the first SACK block MUST be the one with the most > recent addition to it. This is easily done by adding a pointer to > the block last modified. However a bit later it says the following > SACK blocks SHOULD be also in order of their 'recentness' while also > specifying they may be listed in arbitrary order. Now tracking this > information in the block based and sequence number ordered reassembly > queue it a bit more involved and I wonder if it really necessary and > useful. In general the SACK blocks tend to be ordered sequentially > after the first SACK block in single random loss cases. Only in > packet reordering cases, possibly mixed with loss, this may not be > the case. On the other hand the most valuable information for the > sender are the blocks closest to rcv_nxt so it can fill the hole and > complete the sequence space. While the RFC leaves me free to do as > I please I wonder if there are observations or rationales that clearly > show the the ordering by recentness to be better than sequential > ordering after the first SACK block? RFC 2018 is written the way it is written to maximize the robustness in the presence of lost ACKs. If the network never looses ACKs, then just reporting the single SACK block with the newest data is guaranteed to be sufficient for the sender to have perfect knowledge about the state of the reassembly queue at the receiver. If occasional ACKs and one of several non-contiguous retransmissions are lost, the sender might not learn that some of the retransmissions were successful if the 2nd and 3rd SACK block do not reflect the history of the first block. Although in most cases you want to know about blocks closest to rcv_nxt, that is not always true. In particular if the two oldest retransmissions are lost and then some ACKs are also lost, the sender will not know that some of the later holes have been successfully filled. If you are going to take a timeout anyhow, this isn't so important, but we tried to avoid timeouts at all costs. If the 2nd and 3rd block reflect most recent history of the 1st block, the sender will have perfect knowledge of the reassembly queue as long as the network never looses 3 consecutive ACKs (and usually tolerates many more losses). The "may use other algorithms" is there because we suspect that you can do even better, for example by making the 2nd and 3rd blocks periodically or randomly re-report all old SACK blocks. As far a I know this has never been pursued, and we certainly did not want to specify or even suggest it in 2018. Everyone else implements it as written.... Oh, except nix "timeouts MUST clear the scoreboard"... If you preserve the scoreboard on a timeout, you might be able to do goodput=throughput (zero duplicate data at the receiver) under very high loss rates, which is a good thing. Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jan 23 04:03:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHbVT-0002Cf-Pl; Wed, 23 Jan 2008 04:02:51 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JHbVS-0002CS-Kh for tcpm-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 04:02:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHbVL-0002Bg-7D for tcpm@ietf.org; Wed, 23 Jan 2008 04:02:43 -0500 Received: from whisker.bluecoat.com ([216.52.23.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHbVH-0000JP-1Y for tcpm@ietf.org; Wed, 23 Jan 2008 04:02:43 -0500 Received: from bcs-mail6.internal.cacheflow.com ([10.2.2.69]) by whisker.bluecoat.com (8.13.8/8.13.8) with ESMTP id m0N92cAN014594 for ; Wed, 23 Jan 2008 01:02:38 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C85D9E.B03F8241" Subject: RE: [tcpm] Ordering of SACK blocks, flushing of reassembly queue after inactivity Date: Wed, 23 Jan 2008 01:02:32 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Ordering of SACK blocks, flushing of reassembly queue after inactivity Thread-Index: AchdGE0pX7tMAUkrQV+RarHCOIjkGgAg96xo References: From: "Mahdavi, Jamshid" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C85D9E.B03F8241 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Matt described the thinking behind the text in 2018 perfectly. In my = mind, that SHOULD is really almost a MUST because the consequence of = messing up is that the sender can retransmit data which has already = correctly arrived at the sender (or it would have to be so conservative = that you probably end up doing something more equivalent to new-reno in = cases where you get all 3 SACK blocks filled in). =20 I can't tell for sure from your question, but it sounds like you might = not be trying to coalesce adjacent SACKs together into a single SACK = option when the data being SACKed is contiguous. In particular, in the = case of a single dropped packet, no ACK ever needs to have more than one = SACK block in it; that SACK block just keeps getting bigger and bigger. In simulations, it is really easy to get "every other packet dropped" as = a result of slow-start with no delayed-ack. This is one of the = pathological cases in terms of needing the robustness, because every ACK = introduces a new and distinct SACK block. I believe if you tried out = some simple tests with FreeBSD and dummynet, you could get something = pretty close to this behavior with a regular network and stack. A long time ago (>10 years?), one stack author described a clever = solution to the problem you are asking about. I don't want to repeat it = here, because I can't remember if they were an open source developer or = someone working on a proprietary stack. Hopefully they are reading this = and wouldn't mind repeating it though. (I think it was probably a = NetBSD or FreeBSD developer, but I just can't remember...) --J -----Original Message----- Date: Mon, 21 Jan 2008 23:44:02 +0100 From: Andre Oppermann Subject: [tcpm] Ordering of SACK blocks, flushing of reassembly queue after inactivity To: tcpm@ietf.org Message-ID: <47952032.3030809@freebsd.org> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed I'm currently rewriting the tcp reassembly queue of FreeBSD (which is still almost 4.4BSD verbatim) to deal with large socket buffers and to be more economic with kernel memory in the form of mbufs. [1] The new code is based on blocks of contiguous segment data instead of a list of received out-of-order segment that has to be traversed to find the right place for the new segment. It also does all the obvious optimizations based on the chance of things happening. Now there are two issues I'd like to solicit the input from this wg. The first is the ordering of SACK blocks. The block based reassembly queue lends itself to generate the SACK option from. The blocks are ordered ascending from the first segment closest to rcv_nxt. Per RFC 2018 Section 4 the first SACK block MUST be the one with the most recent addition to it. This is easily done by adding a pointer to the block last modified. However a bit later it says the following SACK blocks SHOULD be also in order of their 'recentness' while also specifying they may be listed in arbitrary order. Now tracking this information in the block based and sequence number ordered reassembly queue it a bit more involved and I wonder if it really necessary and useful. In general the SACK blocks tend to be ordered sequentially after the first SACK block in single random loss cases. Only in packet reordering cases, possibly mixed with loss, this may not be the case. On the other hand the most valuable information for the sender are the blocks closest to rcv_nxt so it can fill the hole and complete the sequence space. While the RFC leaves me free to do as I please I wonder if there are observations or rationales that clearly show the the ordering by recentness to be better than sequential ordering after the first SACK block? The second is how long to hold onto data in the reassembly queue. The general theme here is resource exhaustion be it through malicious activity or just end points that drop off the net. I think we can all agree that holding onto reassembly queue data until the session times out (if ever) is not really useful considering the overall resource constrains. The question now is after what time to flush the reassembly queue (and to send an appropriate ACK)? A range of options are available. On the wide side we have a flush timeout of something like 2 times MSL. On the small side we can go down to the current calculated retransmit timeout value as seen from our side. Also of importance is from where the timeout is calculated. From the time the first segment arrived in the reassembly queue (resetting when rcv_nxt is advanced), or from the arrival time of the most recent segment. For the moment and testing I've chosen the former at four times retransmit timeout as something that probably marks the boundary between spurious network losses or partitioning and longer-term disconnect or malicious activity. Is any empirical data available on abandoned sessions with data in the reassembly queue? What is your opinion and rationale on this? [1]=20 http://perforce.freebsd.org/fileLogView.cgi?FSPC=3D//depot/projects/tcp_r= eass/netinet/tcp_reass.c --=20 Andre andre@freebsd.org ------_=_NextPart_001_01C85D9E.B03F8241 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IiIJAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAUgAAAFJFOiBbdGNwbV0gT3JkZXJp bmcgb2YgU0FDSyBibG9ja3MsIGZsdXNoaW5nIG9mIHJlYXNzZW1ibHkgcXVldWUgYWZ0ZXIgaW5h Y3Rpdml0eQBfHQEFgAMADgAAANgHAQAXAAEAAgAgAAMAHQEBIIADAA4AAADYBwEAFwABAAIAIAAD AB0BAQmAAQAhAAAAOUIxRDQ0NzYzMEU1MUY0MTkwNTIwRjkwNjdEQ0U2N0QAFwcBA5AGAJwUAAA5 AAAAAwAmAAAAAAADADYAAAAAAEAAOQBBgj+wnl3IAR4APQABAAAABQAAAFJFOiAAAAAAAgFHAAEA AAA2AAAAYz1VUzthPSA7cD1DQUNIRUZMT1c7bD1CQ1MtTUFJTDYtMDgwMTIzMDkwMjMyWi00MTAy MDYAAAAeAEkAAQAAAB0AAAB0Y3BtIERpZ2VzdCwgVm9sIDQ1LCBJc3N1ZSA4AAAAAEAATgCAR0ZJ GF3IAR4AWgABAAAAFgAAAHRjcG0tcmVxdWVzdEBpZXRmLm9yZwAAAAIBWwABAAAASQAAAAAAAACB Kx+kvqMQGZ1uAN0BD1QCAAAAAHRjcG0tcmVxdWVzdEBpZXRmLm9yZwBTTVRQAHRjcG0tcmVxdWVz dEBpZXRmLm9yZwAAAAACAVwAAQAAABsAAABTTVRQOlRDUE0tUkVRVUVTVEBJRVRGLk9SRwAAHgBd AAEAAAAWAAAAdGNwbS1yZXF1ZXN0QGlldGYub3JnAAAAAgFeAAEAAABJAAAAAAAAAIErH6S+oxAZ nW4A3QEPVAIAAAAAdGNwbS1yZXF1ZXN0QGlldGYub3JnAFNNVFAAdGNwbS1yZXF1ZXN0QGlldGYu b3JnAAAAAAIBXwABAAAAGwAAAFNNVFA6VENQTS1SRVFVRVNUQElFVEYuT1JHAAAeAGYAAQAAAAUA AABTTVRQAAAAAB4AZwABAAAAFgAAAHRjcG0tcmVxdWVzdEBpZXRmLm9yZwAAAB4AaAABAAAABQAA AFNNVFAAAAAAHgBpAAEAAAAWAAAAdGNwbS1yZXF1ZXN0QGlldGYub3JnAAAAHgBwAAEAAABOAAAA W3RjcG1dIE9yZGVyaW5nIG9mIFNBQ0sgYmxvY2tzLCBmbHVzaGluZyBvZiByZWFzc2VtYmx5IHF1 ZXVlIGFmdGVyIGluYWN0aXZpdHkAAAACAXEAAQAAABsAAAAByF0YTSlfu0wBSStBX5FqscI4iOQa ACD3rGgAHgB0AAEAAAAOAAAAdGNwbUBpZXRmLm9yZwAAAB4AGgwBAAAAEQAAAE1haGRhdmksIEph bXNoaWQAAAAAHgAdDgEAAABOAAAAW3RjcG1dIE9yZGVyaW5nIG9mIFNBQ0sgYmxvY2tzLCBmbHVz aGluZyBvZiByZWFzc2VtYmx5IHF1ZXVlIGFmdGVyIGluYWN0aXZpdHkAAAACAQkQAQAAAMgMAADE DAAAgRYAAExaRnXoaHo8AwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/ CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFDz CwkBZDM2FlALpgrjCoC0TWECQCABAATyYgmAsCB0aGUeMQuAawuAfGcgHgAekR4lDsILgCChAdAx OCBwBJBmBZCAdGx5LiAgSQOg7G15IXAfQSweMR1gBgDgSE9VTEQgAAQgGCBbB0AhACAHQARgcwVA YREF0FVTVB8BY2F1TxQQHjMFoACAZXEKUG7yYx5gb2YhcAeQAJAe4fx1cCLCIhMeQhQQH1ASgeck cAOgGCB0cgBxIbAdgdsdYCPgdx6QE9AgE+AEIPsHQCMBZCGQBaEYICDiI2DZKmBpdh4RJwwoBbEo oXp3CGBsHiAT4CsgHjBvzx8BJ2AtcCUTcnYdYCsR3SIEeQhgIIADYGIBoCNB8yeBJnJkbx7SLcAH gB6C/x7wBGAYIC/QJWArEAdACfCrJxEtcG4H0C0YIG4tcP8gESRwFBAEICkgBJAeYC8SLmcUICNh AyAzBgBBQ6ZLHwAXsGNrBCBmAxB3MgAeIAuAKSEhHPQc9El1J9InJxFlNJECEAXAc38IcB5gA1Iv AgXAJWEjsGlzAiAh8GJ1H/EFQC3AdWMfUAQgbGlrM+QhsGe+aAVAMuAFQC2RKEB5HtK/LWEFoDHx BPAeYCoAagDQ9zISNOImwW80QTOxIAEtYe8j4CYyMgA01G8FMDmBM5L/A6AeQijTHgAe0jTiNeIE INMlES5wZ3UIYHMhJAqx/S5wYyzQCsAh8CARJNMzUeslwj8XZANgcCCQHiAKsN81YBQgIfAy4TTy ZSsgBcD/MoAJgD4SLQQxUyIRA6ACIG8/hTUzIAIooDsiBUkYauckkAVAOtBlcAQgNEEucH8e4jtQ NEAFwABwHiBMVC63NnsDoACQbUOhOXJzQ+F3H/Ei5yMQcyGQLWE0QiK/RvIhkDuwPoJGBEV2IiNg tymhIvE4QGwFQCXRcxew/zKgI7BDUSkQKKApYDLhAQC1C2B5CYAtRhEhIVQekP8EICLRSMIl0R5C CrAeQBehvmcN4AdAMzVEAgSQbVXx/yXgR0I8Qx5RL2FLMTKABBC/ObEkZVDUNPI+wQNgZBrQ/weR I+AygUyzWOA5YSWQSlr/ISIfATqwRvEgACXgLxIoQP8IkB4gCGA6IgeATlILUB+ilyOwM4FUQkYJ 0UJTIrD5XGN1bSGAMoBGUS8SBaD/LNI0QjC4L1BL4SohF7Akov8tcB6BBCAfES0gOYAFwFQzr1LC QpBDsTJxdCywckmQ70zCU9FVQTZ6QTqgAiA8YYsHcSNgZy1wKD4xFlDzVPAT8T8pIfBIwmeTI2D/ OeBW8AXAHagj4GRwRvMtwP8KQEATZNNWoS9hMgA4wyrR/T0hcx7DAaBfcV3TMFA3cv53AHAyMxgg IJAiMSihM7L/Whg3NhggB4AG0D6SVmMhkP53M8JIkiCQTkEIYSWhAQD/KyAXsCCRJcBssgeASMJn Av8e0kAxI+AvUS9QCJBT4SGQ62eUITBIdFFmLNAjQXOD/26SKeJY9CLRTMIsszdyIbJvcLUe0iih VuF1O2AhISh/NzAegyxzKZEvVyPgB8B0/2FiBbFhJnUXObQ3MEsjcmyKLoIAKTZ6LS1Kgkytg/FP BRBXMG5XYU0mES1pcGWD8xz0RB1gZTrDBdA5kjIxIEoDkQHQAjAgcDIzOjQ0OvowFEArIFCHIBz0 YSADcO2GMEEfUDFxT0WxWEAAcG0DoDxMwRggQANQCeBiSHNkLgWwZz4c9FOYdWJqINGGMFt0DfD8 bV2JUAsgBnF2siXgNOnuLAyCNZAKQHMxAyXRIwF/BBBy8SNBJWEKUDZ1jiJhXwGAPpMA0C5xKKB5 HPRU1m+GMIwyQHeBZoriHPUJhOVJRIYwPDQ3OcEOQDAzMi4zlMCHMHwwOYpvCoAIUAIwMhEt3FR5 IJCSUQ7BLwtTSgABE9U9SVNPLTg48DU5LTFKADgBAMCYoO+OYFOgCYA2eyc4wEOQKmH3AjAjQRgg dwUQTAMeQw3w948fJcJhJigpIxz0ItE5YeM0kSN1NC40YWJHAS+A/WkhKS1SAQBXYVQzQ7E0QN8t sVGzOdABIASQcxz0TML/LWQxVCURA3AN4FQkOtAEoP83wCXxMVEhkEQFmYIlw6NB8ULRWzFdkdUe UVwiBaD/AQAiwi+AFBBfUQOgNTUl0ftCSCdhZweAMiEo0wuAI7D/KfEc9ETDOrAjsY7zJaArE/1f cS0l0K7AjKKrhyITKYL/LWQoQUcBqdEc9C1hNaAfVf+EUTtxC1EloTgCHkJcIquV/yEiNGItwTBQ W9I0kR5BrNXeYmWRq2E/8iGwek60qaj/JNNIgSWkMPMEIBPgRbEDAPse4E1rTlOgHjJuokhCLLD/ IsE4QAeRmxAeIDqzLWFs0ecN4HwzXoFucDnhOJNlA/53ugyosjWgFABPQx5CrwP/jO9C0qiySVSp tI8oHPSdxO8yATqBKKAUEGxWYVBiMoD/KFAOsB4zP6oDUsJqKaEYIP+s1cECKzI9AR9QHtK+VcAG D6uWZHMjsXCSY3ZfbosO0CEhUBKBUkZDHPTvIEMGYJFhQDE0yplJCSQF/8CkdjJUQh5CI5Ic9K4C MiH/KgBY4G0WKKBVaVABAxAhkP9v4cKxI1HS0W8SIIAwYZDy/y1gsWXCpwtgI7EEYQaQXzH/eENz 0EcCQSEooU6hPpI6If9U4MCUAhAjMFOgHtGLNTT5fyJlLZG00yARrwRWVMAwIPYn0lRZ0icpEj9x tNIc9PZzIJC9cGY8NHOSAMAhkP8tka2CNeMq0dkRKFBRAsECvyEhuuMoUDVgeeafNW6ZhN9AIkQF wtpnUyVWbmHwcxJ/yTbDn53TKKHY9DFTC4B2/wbwKyMfUTcwLLAnk16hKKH/IwUygFvBhQBRAUzB HPQkkf94sSEkxfS1kzTbltGkNsk2/yVELnAjIqO1kOPO30l1PzV/KFEwUDjAZIFCITNSISFP/m4j QQuBHQNRlRggwPczQ98h8NXQJiEvoiGweB4RoiT/9VEh8iLR4QI7pNZ4M0L147/ApD5zSIEeJCOT MeF1L5H/vdLkyLNF36UnhLuDyAjLz/86IixyJ+I1oh4zVvF0AppFfwWgYCLGVSVH4ACzASEhV//f Ex5CzVHE4S0h+kE4cgng/6GTPvGjpTcwYDFEgutquyj/L3AuJbdia3HGMTmBPNIiBP9sYWagxBaO kLr0wKzVEd5I/y1VHgBL8PKzSJHxaMjZbwP78p81Bj82eqhYmIAlEUHz/w3iaNRHsQOwqfKhoqwk WST/jz1NZaiy7rlf0TOzItN0pf8f0JhQSzFAIi2RfDNFkHyR/+DxvVK2gaO1kWV1oksjL+L/1dMm xUWCJcFWZGIxXdN9JO9z0CfSo7Wf8mcH86/zF0H/dqRwk509QPM6YJ/RBQX4kd/OgLFlaTFV8Tnh KF6hRvK/oYBPYTuiT5Xt9C3jacEV/8CzRwFPsdH2dKUt8uJRrGH/wmU5NjuRXEB6QpDjnuAM0d9p I7HCjnLWeCT/KKQV/+KfdBK5kXdDxkI08Sk/fND/aLD00aKhWICs1UADyIN+cP/9wN8g/gL76GDQ qVEqgiJi/0fTfoCOY2kTX3Gs12NovLOjh9AnxE1TTPvocx3B36AAN2YC0mmB9QB3bUL7CfubZHJR bEOS4aJkEfTRO/D/vYI4xP2zbrLmwXRxvlMsUfs3U01lQbTiWIFgEWtwauD/uKJPYb5TnuBz4g4j QEVPYf8+2LRxiKK1qC90yr9moJwg/65SGC8xhlLhEIEO8kSB9nXbAfZ6QmT9wLihZGpizTD/yldI 8+8CaTJWVf1z0lT/hv20JkazVdfASKSkIi3iDwH/mxBecZhAZJGm2AAivjEsUf8naj+P6cGfoWN3 DLN994mw/2cg2hRvUaQg7SGDlBBxc9D/dHK+EJwgtoJm1vVCJ/LNMH+TUR7QDCLVc6QhaNKl8C39 kPFtg5R50MnAzoDswa2x/80wHcd+cJFltHJ6Un5gbiD+cN4AnwCEoRfTNedqgaO1/34g9PHU4Oay JxO+0dEyF9//j3kz8QZgcQJM0G5RVNV4gP/2YG0iXQIMB7f0vAAUb5BgDaghIIOUsrB0cDovX5fA pfCzQQYRlYkvAxFlEExvZ1Z3gHcuY4GEcD9GU1BDPWuAnwAQ1dCXsTMgi8JzL5zR+l+PIy8hkfZg mJBvSG2gv4JMasWJA5paih+DlH11AB4ANRABAAAASgAAADxGQTQ1M0NCM0Y1QUU2RjQ5OTYwNjNG MUVEODMzMTVCRDNEMUJCMkBiY3MtbWFpbDYuaW50ZXJuYWwuY2FjaGVmbG93LmNvbT4AAAAeADkQ AQAAACYAAAA8RTFKSE1VNy0wMDA3WDgtN1ZAbWVnYXRyb24uaWV0Zi5vcmc+AAAAHgBHEAEAAAAP AAAAbWVzc2FnZS9yZmM4MjIAAAsA8hABAAAAHwDzEAEAAACwAAAAUgBFACUAMwBBACAAWwB0AGMA cABtAF0AIABPAHIAZABlAHIAaQBuAGcAIABvAGYAIABTAEEAQwBLACAAYgBsAG8AYwBrAHMALAAg AGYAbAB1AHMAaABpAG4AZwAgAG8AZgAgAHIAZQBhAHMAcwBlAG0AYgBsAHkAIABxAHUAZQB1AGUA IABhAGYAdABlAHIAIABpAG4AYQBjAHQAaQB2AGkAdAB5AC4ARQBNAEwAAAALAPYQAAAAAEAABzAZ pdQrnF3IAUAACDA9HXuwnl3IAQMA3j+vbwAAAwDxPwkEAAAeAPg/AQAAABEAAABNYWhkYXZpLCBK YW1zaGlkAAAAAAIB+T8BAAAAVAAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1DQUNI RUZMT1cvT1U9Q0YtQkFZL0NOPVJFQ0lQSUVOVFMvQ049SkFNU0hJRC5NQUhEQVZJAB4A+j8BAAAA FQAAAFN5c3RlbSBBZG1pbmlzdHJhdG9yAAAAAAIB+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAAr L+GCAQAAAAAAAAAuAAAAAwD9P+QEAAADABlAAAAAAAMAGkAAAAAAAwAdQAAAAAADAB5AAAAAAB4A MEABAAAAEAAAAEpBTVNISUQuTUFIREFWSQAeADFAAQAAABAAAABKQU1TSElELk1BSERBVkkAHgAy QAEAAAAWAAAAdGNwbS1yZXF1ZXN0QGlldGYub3JnAAAAHgAzQAEAAAAWAAAAdGNwbS1yZXF1ZXN0 QGlldGYub3JnAAAAHgA4QAEAAAAQAAAASkFNU0hJRC5NQUhEQVZJAB4AOUABAAAAAgAAAC4AAAAD AHZA/////wsAKQAAAAAACwAjAAAAAAADAAYQ/OxsjgMABxAnEAAAAwAQEAAAAAADABEQAAAAAB4A CBABAAAAZQAAAE1BVFRERVNDUklCRURUSEVUSElOS0lOR0JFSElORFRIRVRFWFRJTjIwMThQRVJG RUNUTFlJTk1ZTUlORCxUSEFUU0hPVUxESVNSRUFMTFlBTE1PU1RBTVVTVEJFQ0FVU0VUSEUAAAAA AgF/AAEAAABKAAAAPEZBNDUzQ0IzRjVBRTZGNDk5NjA2M0YxRUQ4MzMxNUJEM0QxQkIyQGJjcy1t YWlsNi5pbnRlcm5hbC5jYWNoZWZsb3cuY29tPgAAAL/f ------_=_NextPart_001_01C85D9E.B03F8241 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm ------_=_NextPart_001_01C85D9E.B03F8241-- From tcpm-bounces@ietf.org Wed Jan 23 18:14:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHoo0-0001Wo-9u; Wed, 23 Jan 2008 18:14:52 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JHonz-0001Wh-2M for tcpm-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 18:14:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHony-0001WZ-7L for tcpm@ietf.org; Wed, 23 Jan 2008 18:14:50 -0500 Received: from c00l3r.networx.ch ([62.48.2.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHonx-0002fE-4Q for tcpm@ietf.org; Wed, 23 Jan 2008 18:14:50 -0500 Received: (qmail 86102 invoked from network); 23 Jan 2008 22:36:09 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 23 Jan 2008 22:36:09 -0000 Message-ID: <4797CA6B.9080502@freebsd.org> Date: Thu, 24 Jan 2008 00:14:51 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: jblanton@irg.cs.ohiou.edu Subject: Re: [tcpm] Ordering of SACK blocks, flushing of reassembly queue after inactivity References: <47952032.3030809@freebsd.org> <20080122154207.GD4320@mauser.ipx.ath.cx> In-Reply-To: <20080122154207.GD4320@mauser.ipx.ath.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joshua Blanton wrote: > I don't have a good answer to your first question (other than to > mention that, if you always send the most-recently-modified SACK > regions, you ensure that they're sent multiple times - which is the > only quasi-reliability you can create on the ACK path), but I would > like to address the second. > > Andre Oppermann wrote: >> The second is how long to hold onto data in the reassembly queue. >> The general theme here is resource exhaustion be it through malicious >> activity or just end points that drop off the net. I think we can >> all agree that holding onto reassembly queue data until the session >> times out (if ever) is not really useful considering the overall >> resource constrains. The question now is after what time to flush >> the reassembly queue (and to send an appropriate ACK)? A range of >> options are available. On the wide side we have a flush timeout >> of something like 2 times MSL. On the small side we can go down to >> the current calculated retransmit timeout value as seen from our side. >> Also of importance is from where the timeout is calculated. From the >> time the first segment arrived in the reassembly queue (resetting when >> rcv_nxt is advanced), or from the arrival time of the most recent >> segment. For the moment and testing I've chosen the former at four >> times retransmit timeout as something that probably marks the boundary >> between spurious network losses or partitioning and longer-term >> disconnect or malicious activity. Is any empirical data available on >> abandoned sessions with data in the reassembly queue? What is your >> opinion and rationale on this? > > Well, I actually disagree that holding onto reassembly queue data is > a lost cause, even after long periods of inactivity - so perhaps we > don't all agree :-). Certainly you could tell *after* the fact that > holding such data was a fool's errand, if the connection is > terminated; until that point, there's no reason to necessarily > assume that the lack of progress in the connection is permanent. In > general, I would expect an operating system to hold on to reassembly > data for forever, assuming that there's no memory resource concern > that makes the buffers valuable... To flush data simply because > wall-clock time has elapsed doesn't make sense to me, since I've > seen many traces where "long" time periods have elapsed and then > connections suddenly resume. If there's no global "we're running > out of memory" trigger available for a given OS, a stack could set a > timer to fire at some arbitrary time (4*RTO, for instance) and check > for memory pressure - *if* it exists, go ahead and flush the data. The memory pressure thing is critical part here. Otherwise I fully agree that we should hold onto the reassembly queue forever. Unfortunately we can't afford to do that as memory is still limited. The problematic part I'm trying to address here is the very difficult definition of memory pressure. In modern kernels this isn't as simple as it seems on a first glance. Of course we can and do detect when we run out of physical memory in kernel. However memory pressure starts a lot earlier and may manifest itself by a couple of subsystems having trouble to obtain enough memory out of their zones. Memory also may be used for more productive things than reassembly queues, for example disk buffers. In SMP and NUMA systems various pools of memory on the CPUs may have associated memory regions which may be depleted to different levels. On top of it modern kernels run in memory overcommit mode where not all potential memory requirements can be fulfilled at the same time. Otherwise we would have to lock down the full socket buffer space for every connection we may have. This is very inefficient and uneconomical. Whether limited kernel memory is more valuable in a reassembly queue than other data structure really depends on the goals and purpose of a particular system and its application setting. All this and a lot more makes it really hard to go for a purist solution. We as developers of a general purpose operating system (in this case FreeBSD) have to chose appropriate limits and defaults for a wide range of operating conditions. Special and niche applications may require specific tunings and explicit settings. We have to find a good balance among allocation of memory to the various usages in the kernel. Not to forget we also have to protect to a certain extent against malicious attacks that try to chew us up. For this we use things like syncaches and other methods. TCP reassembly is no exception to this. The hard part, and the reason I've come here to solicit input, is to decide where to set the limits. There are a number of (imaginary) intersecting curves that represent the usefulness of memory tied up in an inactive or non-responsive reassembly queue vs. other valuable uses the kernel may have for that memory. The question is where these curves intersect and where to set the cutoff point in the reassembly queue. If for example 98% of all sessions get their reassembly act together within 2xRTO it may be worth the negative impact on the other 2% to opportunistically use the memory for other purposes. Even if we flush the reassembly queue in those two percent it is a graceful failure as the connections are not terminated and stay alive although not at the theoretically optimal point from a network resource conservation point of view. I guess this really gets into a discussion about the economics theory side of things... ;-) > I don't have any data showing how much reassembly data is left > hanging around when a session is abandoned, but I have looked at > quite a few traces trying to find SACK renegs (which would be the > result of your data flushing). In general, I believe that a scheme > such as you're proposing is not used; other than some traces that > I've found that p0f identifies as being FreeBSD receivers, there > doesn't appear to be a solid link between connection progress > timeouts and reneging. I don't know the FreeBSD stack well enough > to say that, in its current implementations, it definitely flushes > reassembly queue data based on a timer - but I suspected that it > did, and your question reinforces my suspicion. If I am correct, > and FreeBSD currently (5.x and 6.x) times out reassembly data as > you're proposing, I've seen traces where this actually impedes a > connection's recovery - so I vote against such a scheme. The reassembly queues in FreeBSD 5, 6 and 7 do not get flushed unless under severe system wide memory pressure (a time things already fall apart left and right). All the work and changes I'm doing and discussing here are on a separate development and testing branch and won't be in official FreeBSD until everything is sorted out and tested. > Again, I have no problem with stacks flushing out-of-order data in > the face of a low-memory condition. Beyond that, I'd have to see > some pretty convincing data that "long pauses == connection that > will terminate without finishing," which is what I feel you're > proposing. Whether the connection will terminate without finishing is only an optimization aspect. The tipping point is "long pause && holding on to valuable memory <> other more valuable use for memory". Now define long pause, value of memory and plot the trajectory. -- Andre _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jan 23 19:01:06 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHpWf-0003Al-1p; Wed, 23 Jan 2008 19:01:01 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JHpWd-0003Ae-Qi for tcpm-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 19:00:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHpWd-0003AV-Gu for tcpm@ietf.org; Wed, 23 Jan 2008 19:00:59 -0500 Received: from c00l3r.networx.ch ([62.48.2.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHpWb-0003sl-Oc for tcpm@ietf.org; Wed, 23 Jan 2008 19:00:59 -0500 Received: (qmail 86584 invoked from network); 23 Jan 2008 23:22:18 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 23 Jan 2008 23:22:18 -0000 Message-ID: <4797D53C.10908@freebsd.org> Date: Thu, 24 Jan 2008 01:01:00 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Matt Mathis Subject: Re: [tcpm] Ordering of SACK blocks, flushing of reassembly queue after inactivity References: <47952032.3030809@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Matt Mathis wrote: >> The first is the ordering of SACK blocks. The block based reassembly >> queue lends itself to generate the SACK option from. The blocks are >> ordered ascending from the first segment closest to rcv_nxt. Per RFC >> 2018 Section 4 the first SACK block MUST be the one with the most >> recent addition to it. This is easily done by adding a pointer to >> the block last modified. However a bit later it says the following >> SACK blocks SHOULD be also in order of their 'recentness' while also >> specifying they may be listed in arbitrary order. Now tracking this >> information in the block based and sequence number ordered reassembly >> queue it a bit more involved and I wonder if it really necessary and >> useful. In general the SACK blocks tend to be ordered sequentially >> after the first SACK block in single random loss cases. Only in >> packet reordering cases, possibly mixed with loss, this may not be >> the case. On the other hand the most valuable information for the >> sender are the blocks closest to rcv_nxt so it can fill the hole and >> complete the sequence space. While the RFC leaves me free to do as >> I please I wonder if there are observations or rationales that clearly >> show the the ordering by recentness to be better than sequential >> ordering after the first SACK block? > > RFC 2018 is written the way it is written to maximize the robustness in > the presence of lost ACKs. If the network never looses ACKs, then just > reporting the single SACK block with the newest data is guaranteed to be > sufficient for the sender to have perfect knowledge about the state of > the reassembly queue at the receiver. > > If occasional ACKs and one of several non-contiguous retransmissions are > lost, the sender might not learn that some of the retransmissions were > successful if the 2nd and 3rd SACK block do not reflect the history of > the first block. > > Although in most cases you want to know about blocks closest to rcv_nxt, > that is not always true. In particular if the two oldest > retransmissions are lost and then some ACKs are also lost, the sender > will not know that some of the later holes have been successfully > filled. If you are going to take a timeout anyhow, this isn't so > important, but we tried to avoid timeouts at all costs. This pretty much where my question originates from. The approach of reporting the most recent block first and then closest and second closest to rcv_nxt works just fine as long as the number of holes is not large or excessive. However even then I may argue that filling the hole after rcv_nxt is the most important goal, above reporting second and third recent blocks (if different). Once the first hole is filled the closest and second closest blocks to rcv_nxt automatically shift to the right by one and get reported immediately. When a large number of holes appear the sender is very likely to face a collapsed congestion window and will have to throttle down its rate of sending. This makes it probable that guaranteed knowledge further out is not relevant at this point in time. By the time this becomes relevant it get reported because it gets closer to rcv_nxt. I'm not forcefully arguing this view but want to bring it up for further elaboration and comparison with the other recommended approaches. > If the 2nd and 3rd block reflect most recent history of the 1st block, > the sender will have perfect knowledge of the reassembly queue as long > as the network never looses 3 consecutive ACKs (and usually tolerates > many more losses). > > The "may use other algorithms" is there because we suspect that you can > do even better, for example by making the 2nd and 3rd blocks > periodically or randomly re-report all old SACK blocks. As far a I know > this has never been pursued, and we certainly did not want to specify or > even suggest it in 2018. > > Everyone else implements it as written.... FreeBSD currently does so as well. It's in my development branch I'm working and experimenting with alternative approaches. Using the block building logic of the reassembly queue itself for SACK reporting is quite tempting. ;-) > Oh, except nix "timeouts MUST clear the scoreboard"... If you preserve > the scoreboard on a timeout, you might be able to do goodput=throughput > (zero duplicate data at the receiver) under very high loss rates, which > is a good thing. Thanks for your extensive explanations. -- Andre _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 24 09:29:57 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI35R-0000TA-7n; Thu, 24 Jan 2008 09:29:49 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JI35O-0000Dx-O0 for tcpm-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 09:29:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI35N-00008p-Qu for tcpm@ietf.org; Thu, 24 Jan 2008 09:29:45 -0500 Received: from mailer1.psc.edu ([2001:5e8:1:3a::64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI35N-0005ou-3J for tcpm@ietf.org; Thu, 24 Jan 2008 09:29:45 -0500 Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer1.psc.edu (8.14.2/8.13.3) with ESMTP id m0OETfRG002485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jan 2008 09:29:41 -0500 (EST) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.13.1) with ESMTP id m0OETfS6005873; Thu, 24 Jan 2008 09:29:41 -0500 Date: Thu, 24 Jan 2008 09:29:41 -0500 (EST) From: Matt Mathis To: Andre Oppermann Subject: Re: [tcpm] Ordering of SACK blocks, flushing of reassembly queue after inactivity In-Reply-To: <4797D53C.10908@freebsd.org> Message-ID: References: <47952032.3030809@freebsd.org> <4797D53C.10908@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: TCP Maintenance and Minor Extensions WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org If you are thinking at the scale of a dozen packet windows with just a couple of losses, I don't disagree with you. However, with 1000 packet windows, you almost never see "just a couple of losses", and your proposed simplification will be very exposed to lost ACKs. Given that the ACK rate doubles, your chances are not good. BTW 1000 packet windows are not all that big: 1500 Byte MTU, 70 ms RTT and only 90 Mb/s - well within reach for any university user in the US or Europe and FIOS users in Korea or Japan. The real challenge is getting the scoreboard to work well with 10k or 100k packet windows.... Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. On Thu, 24 Jan 2008, Andre Oppermann wrote: > Matt Mathis wrote: >>> The first is the ordering of SACK blocks. The block based reassembly >>> queue lends itself to generate the SACK option from. The blocks are >>> ordered ascending from the first segment closest to rcv_nxt. Per RFC >>> 2018 Section 4 the first SACK block MUST be the one with the most >>> recent addition to it. This is easily done by adding a pointer to >>> the block last modified. However a bit later it says the following >>> SACK blocks SHOULD be also in order of their 'recentness' while also >>> specifying they may be listed in arbitrary order. Now tracking this >>> information in the block based and sequence number ordered reassembly >>> queue it a bit more involved and I wonder if it really necessary and >>> useful. In general the SACK blocks tend to be ordered sequentially >>> after the first SACK block in single random loss cases. Only in >>> packet reordering cases, possibly mixed with loss, this may not be >>> the case. On the other hand the most valuable information for the >>> sender are the blocks closest to rcv_nxt so it can fill the hole and >>> complete the sequence space. While the RFC leaves me free to do as >>> I please I wonder if there are observations or rationales that clearly >>> show the the ordering by recentness to be better than sequential >>> ordering after the first SACK block? >> >> RFC 2018 is written the way it is written to maximize the robustness in the >> presence of lost ACKs. If the network never looses ACKs, then just >> reporting the single SACK block with the newest data is guaranteed to be >> sufficient for the sender to have perfect knowledge about the state of the >> reassembly queue at the receiver. >> >> If occasional ACKs and one of several non-contiguous retransmissions are >> lost, the sender might not learn that some of the retransmissions were >> successful if the 2nd and 3rd SACK block do not reflect the history of the >> first block. >> >> Although in most cases you want to know about blocks closest to rcv_nxt, >> that is not always true. In particular if the two oldest retransmissions >> are lost and then some ACKs are also lost, the sender will not know that >> some of the later holes have been successfully filled. If you are going to >> take a timeout anyhow, this isn't so important, but we tried to avoid >> timeouts at all costs. > > This pretty much where my question originates from. The approach of > reporting the most recent block first and then closest and second > closest to rcv_nxt works just fine as long as the number of holes is > not large or excessive. However even then I may argue that filling > the hole after rcv_nxt is the most important goal, above reporting > second and third recent blocks (if different). Once the first hole > is filled the closest and second closest blocks to rcv_nxt automatically > shift to the right by one and get reported immediately. When a large > number of holes appear the sender is very likely to face a collapsed > congestion window and will have to throttle down its rate of sending. > This makes it probable that guaranteed knowledge further out is not > relevant at this point in time. By the time this becomes relevant it > get reported because it gets closer to rcv_nxt. > > I'm not forcefully arguing this view but want to bring it up for further > elaboration and comparison with the other recommended approaches. > >> If the 2nd and 3rd block reflect most recent history of the 1st block, the >> sender will have perfect knowledge of the reassembly queue as long as the >> network never looses 3 consecutive ACKs (and usually tolerates many more >> losses). >> >> The "may use other algorithms" is there because we suspect that you can do >> even better, for example by making the 2nd and 3rd blocks periodically or >> randomly re-report all old SACK blocks. As far a I know this has never >> been pursued, and we certainly did not want to specify or even suggest it >> in 2018. >> >> Everyone else implements it as written.... > > FreeBSD currently does so as well. It's in my development branch I'm > working and experimenting with alternative approaches. Using the block > building logic of the reassembly queue itself for SACK reporting is > quite tempting. ;-) > >> Oh, except nix "timeouts MUST clear the scoreboard"... If you preserve the >> scoreboard on a timeout, you might be able to do goodput=throughput (zero >> duplicate data at the receiver) under very high loss rates, which is a good >> thing. > > Thanks for your extensive explanations. > > -- > Andre > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 24 10:05:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI3dY-00032v-N6; Thu, 24 Jan 2008 10:05:04 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JI3dX-00032q-PM for tcpm-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 10:05:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI3dX-00032i-Du for tcpm@ietf.org; Thu, 24 Jan 2008 10:05:03 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI3dW-0006qA-JK for tcpm@ietf.org; Thu, 24 Jan 2008 10:05:03 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0OF3sVR003211; Thu, 24 Jan 2008 17:04:34 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 17:04:29 +0200 Received: from esdhcp035182.research.nokia.com ([172.21.35.182]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 17:04:29 +0200 Message-Id: <1648983D-9F94-4C59-88AD-78496CBFA119@nokia.com> From: Lars Eggert To: ext Matt Mathis In-Reply-To: Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [tcpm] Ordering of SACK blocks, flushing of reassembly queue after inactivity Date: Thu, 24 Jan 2008 17:04:25 +0200 References: <47952032.3030809@freebsd.org> <4797D53C.10908@freebsd.org> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 24 Jan 2008 15:04:29.0239 (UTC) FILETIME=[6AF3B470:01C85E9A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: TCP Maintenance and Minor Extensions WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1524669133==" Errors-To: tcpm-bounces@ietf.org --===============1524669133== Content-Type: multipart/signed; boundary=Apple-Mail-43--458433543; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-43--458433543 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2008-1-24, at 16:29, ext Matt Mathis wrote: > BTW 1000 packet windows are not all that big: 1500 Byte MTU, 70 ms > RTT and only 90 Mb/s - well within reach for any university user in > the US or Europe > and FIOS users in Korea or Japan. The real challenge is getting > the scoreboard to work well with 10k or 100k packet windows.... The highspeed TCP folks have reported cases where SACK processing can eat CPU cycles up to a degree where it significantly affects performance. (I think this was under Linux.) I'm not sure if this is an issue with the code or an issue with the spec; if it's the latter, we may have some work to do. (But you probably know more about this than I do anyway.) Lars --Apple-Mail-43--458433543 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/TCCAvkw ggJioAMCAQICEFcKn6uMJyFYm3ow9AwDVo0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTEyMDA4NTMyMloXDTA4MTExOTA4NTMy MlowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxx0rd8E8VV2l2Y/zV2buSRcCWScJwDJc8moZY88N1Hla1CMhh83tIPQN pukkPE6GMIJjferzgTV8extFAd6jrk96U6HJLXF/xzxKX/U3ksT/rwyLCO8l9T8OwNtmjWjMwn0Y 1f4V5JnXLyZDz97BaN2rnJjccSIYuDJLXPzaTE3kxYe7j35iIgyaqhLYs3dERHOOJpiuWhHOj45C m/4hCWiSEtwabUtufw232z2r4tExOXuxH8OJtbbJxmf/tb+/m5pNRQbKl1KWbFlLqeojqgrG56jx uxNDfMaTNHfygPea8LGjzrE0Ck3lqUYXD2/dk45Y8lJAAhFQ3erCwMw1XwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBGcuNVdbuBMUyXaAiENyTmsKPOwd/PJOI540ONxvVyGtycdaMMlUL+tz/Qcznv/hnqN7u2 NqrvBYn+afSlZKQHgbSjFT4b8hD3rWnU6/EeS+HX8k5ogJqyy4et/TomMp4gIxC/jjhFw3XWhKpm 4Wr51tzDI3lUs2PlVNLFSiBhNzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhBXCp+rjCchWJt6MPQMA1aNMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDEyNDE1MDQyNlowIwYJKoZI hvcNAQkEMRYEFP01N2CUI2FD2MTzUTaZhQ7UlYhqMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVwqfq4wnIVibejD0DANWjTCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQVwqfq4wnIVibejD0DANWjTANBgkqhkiG9w0BAQEFAASCAQC+ShTM2tvLJ/n/Z99BhuluvfcA qHtyCv/pA1VdEA2L37f0MvN/shrdbt8BeLEfFsPDwIRXPjN5+lqpCmhSt/ixw1ocyjP/I0WJmwTh PIAXQWGVVarbqOF1Lh9Bco9b1qvosC67aULacqwLqIjct4zZMO7fP1DmY52zg/EutggGgc7sywz3 NIbm/xVTd30/XUHk5ZZin2x5njK61Etgrd63wkNRuy2v/2LWd5zh0o5p3YKSi6plklQhvrBDXhBk L9J0h/MZfHJ1CWEnxv4hw150LW6C2yJVR6HcTDIjK7hSI8whnkjEEhDW1KVHXjIYVRhZq3ipmpRJ Xgz0dd0Y4jzMAAAAAAAA --Apple-Mail-43--458433543-- --===============1524669133== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1524669133==-- From tcpm-bounces@ietf.org Thu Jan 24 10:24:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI3wZ-0000LN-Km; Thu, 24 Jan 2008 10:24:43 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JI3wY-0000K2-92 for tcpm-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 10:24:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI3wX-0000JB-UY for tcpm@ietf.org; Thu, 24 Jan 2008 10:24:41 -0500 Received: from kac.cnri.dit.ie ([147.252.67.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI3wX-0007wK-Ak for tcpm@ietf.org; Thu, 24 Jan 2008 10:24:41 -0500 Received: from kac.cnri.dit.ie (localhost.cnri.dit.ie [127.0.0.1]) by kac.cnri.dit.ie (8.13.4/8.13.4) with ESMTP id m0OFOTB1024134; Thu, 24 Jan 2008 15:24:30 GMT (envelope-from dwmalone@kac.cnri.dit.ie) Message-Id: <200801241524.m0OFOTB1024134@kac.cnri.dit.ie> To: Lars Eggert Subject: Re: [tcpm] Ordering of SACK blocks, flushing of reassembly queue after inactivity In-Reply-To: Your message of "Thu, 24 Jan 2008 17:04:25 +0200." <1648983D-9F94-4C59-88AD-78496CBFA119@nokia.com> From: David Malone Date: Thu, 24 Jan 2008 15:24:29 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: TCP Maintenance and Minor Extensions WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > The highspeed TCP folks have reported cases where SACK processing can > eat CPU cycles up to a degree where it significantly affects > performance. (I think this was under Linux.) I'm not sure if this is > an issue with the code or an issue with the spec; if it's the latter, > we may have some work to do. (But you probably know more about this > than I do anyway.) I think it was mainly implementation issues, see Chapter 3 of: http://www.hamilton.ie/publications/baruch_even_thesis.pdf it describes how to fix some of the problems. With that, there were no problems running up to about 1Gbps with sizeable RTTs. David. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 24 10:49:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI4Kl-0002xw-6s; Thu, 24 Jan 2008 10:49:43 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JI4Kk-0002xp-5S for tcpm-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 10:49:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI4Kj-0002xc-QX for tcpm@ietf.org; Thu, 24 Jan 2008 10:49:41 -0500 Received: from mailer1.psc.edu ([128.182.58.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI4Kj-0000DJ-FA for tcpm@ietf.org; Thu, 24 Jan 2008 10:49:41 -0500 Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer1.psc.edu (8.14.2/8.13.3) with ESMTP id m0OFne8C015306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jan 2008 10:49:40 -0500 (EST) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.13.1) with ESMTP id m0OFneu5006901; Thu, 24 Jan 2008 10:49:40 -0500 Date: Thu, 24 Jan 2008 10:49:40 -0500 (EST) From: Matt Mathis To: Lars Eggert Subject: Re: [tcpm] Ordering of SACK blocks, flushing of reassembly queue after inactivity In-Reply-To: <1648983D-9F94-4C59-88AD-78496CBFA119@nokia.com> Message-ID: References: <47952032.3030809@freebsd.org> <4797D53C.10908@freebsd.org> <1648983D-9F94-4C59-88AD-78496CBFA119@nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: TCP Maintenance and Minor Extensions WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Thu, 24 Jan 2008, Lars Eggert wrote: > The highspeed TCP folks have reported cases where SACK processing can eat CPU > cycles up to a degree where it significantly affects performance. (I think > this was under Linux.) I'm not sure if this is an issue with the code or an > issue with the spec; if it's the latter, we may have some work to do. (But > you probably know more about this than I do anyway.) Yes, the straight forward ways to implement the scoreboard all take O(N^2) time, especially in the pathological case where every 2nd or 3rd segment is lost, such as following a slowstart into a drop tail queue. At GigE, it is pretty easy to construct cases where the CPU time to process all of the SACK blocks in all ACKS exceeds rto. (Or at least this was true for Linux kernels that are more than a few years old. There has been a lot of attention to SACK efficiency lately). Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jan 29 18:30:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJzu1-0006e3-4J; Tue, 29 Jan 2008 18:30:05 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JJztz-0006dn-JO for tcpm-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 18:30:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJztz-0006df-7g; Tue, 29 Jan 2008 18:30:03 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJzty-0000NL-R2; Tue, 29 Jan 2008 18:30:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 78D822AC6B; Tue, 29 Jan 2008 23:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JJzty-0002l1-7T; Tue, 29 Jan 2008 18:30:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 29 Jan 2008 18:30:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-1323bis-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP Extensions for High Performance Author(s) : D. Borman, et al. Filename : draft-ietf-tcpm-1323bis-00.txt Pages : 46 Date : 2008-01-29 This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequences). Selective acknowledgments are not included in this memo. This memo updates and obsoletes RFC-1323 [Jacobson92d]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-1323bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-1323bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-1323bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-29182900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-1323bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-1323bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-29182900.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart--