From sallyfloyd@mac.com Tue May 12 16:54:55 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 313233A6778 for ; Tue, 12 May 2009 16:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KdTCKyw2oxX for ; Tue, 12 May 2009 16:54:53 -0700 (PDT) Received: from asmtpout016.mac.com (asmtpout016.mac.com [17.148.16.91]) by core3.amsl.com (Postfix) with ESMTP id B6B573A6910 for ; Tue, 12 May 2009 16:54:53 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Received: from [192.168.1.85] (adsl-70-231-238-221.dsl.snfc21.sbcglobal.net [70.231.238.221]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KJK0072E2H2R720@asmtp016.mac.com> for tcpm@ietf.org; Tue, 12 May 2009 16:55:51 -0700 (PDT) Message-id: <9727679D-2111-41E5-8774-F34396798E27@mac.com> From: Sally Floyd To: "Agarwal, Anil" In-reply-to: <0B0A20D0B3ECD742AA2514C8DDA3B065020BE918@VGAEXCH01.hq.corp.viasat.com> Content-transfer-encoding: quoted-printable Date: Tue, 12 May 2009 16:55:50 -0700 References: <0B0A20D0B3ECD742AA2514C8DDA3B065020BE918@VGAEXCH01.hq.corp.viasat.com> X-Mailer: Apple Mail (2.930.3) Cc: Aleksandar Kuzmanovic , "K. K. Ramakrishnan" , tcpm , Amit Mondal Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-ecnsyn (Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets) to Experimental RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 23:54:55 -0000 Anil - On Apr 16, 2009, at 1:26 PM, Agarwal, Anil wrote: > Here are a few comments and suggestions on draft-ietf-tcpm-=20 > ecnsyn-08.txt. Many thanks, and my apologies for the delay in getting back to you. We made some of the changes that you suggested, but not others. The details are below. In general, we find that it is useful not to expand the scope of standards documents more than necessary. - Sally http://www.icir.org/floyd/ > 1. Figure 1 - > Should we replace "possibly ECT" by "ECT, since this doc is all =20 > about SYN/ACK with ECT? But in Figure 1, the response when the SYN/ACK packet is dropped is the same for a SYN/ACk packet *without* ECT as it is for a SYN/ACK packet *with* ECT. So we have left it how it is. > 2. Section 3.2, first para - > Would be useful to clarify that the responder must not advance the =20 > send sequence number, even though it has received an acknowledgement =20= > for the SYN. Done. > Would be useful to explicitly state that the responder must restart =20= > the retransmission timer. Done. > What timer value should the responder use - 3 seconds or the =20 > measured RTT? I presume it is 3 seconds. I added the following: "The responder follows RFC 2988 in setting the RTO (retransmission timeout)." Thus, if the responder has a measured RTT, it uses that in setting the RTO. > 3. Figures 2 and 3 - > Perhaps first Data/ACK should be labeled as ACK, since the initiator =20= > is not allowed to send data at this point. > Would be useful to show the subsequent Data segment as carrying ECT. Thanks, done. > 4. Figure 2 and last para of section 3.2 - > Doesn't ECN-setup SYN/ACK packet include CWR bit by definition? =46rom RFC 3168, an ECN-setup SYN/ACK packet has the ECE flag set, but the CWR flag not set. > The figure and text imply that the second ECN-Setup SYN/ACK packet =20 > has the CWR bit set as a result of having received an ECN-echo =20 > indication. Does not seem right. Many thanks, you are right that this is a problem. We have changed the specification so that the second ECN-Setup SYN/ACK packet does not have the CWR bit set. We have also specified that on receiving the non-ECN-Capable SYN/ACK packet, the TCP initiator clears the ECN-Echo flag on replying packets. > 5. Section 3.2, 3rd para - > Sentence "However, with ECN+/TryOnce the initiator does not advance =20= > from the "SYN-Sent" to the "SYN-Received" state ..". > A bit confusing. Normally, TCP advances to the Established state, =20 > not SYN-Received state on reception of a SYN/ACK. Yes, TCP advances =20= > to the SYN-Received state on reception of a SYN, but we are not =20 > using that example here. Thanks, we changed it to "Established" state. > 6. Section 3.2, 3rd para - > First line "However, with ECN+/TryOnce ..." seems confusing. The =20 > previous para (and the rest of the doc) deals with ECN_/TryOnce =20 > only, right? Fixed. > 7. Section 3.2, 3rd para - > "... initiator resets the retransmit timer..." would the word =20 > "restarts" instead of "resets" be more descriptive? Or do we really =20= > mean "stop"? Done (following the terminology in RFC 2988). I also changed "retransmit timer" to "retransmission timer". > 8. Section 3.2, 3rd para - > Clarify what the initiator does on receipt of the SYN/ACK packet =20 > with ECM-mark - > Does it accept or ignore the contents of the SYN/ACK packet (ack =20 > field, mss option, etc). Does it consider its SYN to be acked? > Clarify what the initiator does while it stays in the SYN-Sent state. > Does it behave as if it never received a SYN/ACK packet - not quite =20= > true, since it sends ECN-echo on subsequent packets. > Does it restart or stop the retransmission timer? If restart, =20 > presumably it uses the 3 second value. > Does it retransmit SYN if a timeout occurs? > > One suggestion is that the initiator should not make any changes to =20= > its TCP state when it receives an ECN-marked SYN/ACK packet in the =20 > SYN-Sent state (not sure of this is what is intended in the current =20= > doc). It should not remember the ECN state for subsequent sending of =20= > ECN-Echo flags. It should simply send the ACK with ECN-echo packet =20 > and restart its 3-second timer. > > Similarly, the responder should make the following changes only to =20 > its TCP state on receiving an ACK with ECN-echo packet in the SYN-=20 > received state - set the initial window size to 1 segment, disable =20 > sending of ECT with SYN segments and restart the 3-second timer =20 > after sending the SYN/ACK segment. We have put in an additional sentence: "The responder also sets the retransmission timer." > The responder should make the following changes to its TCP state =20 > after timeout in the SYN-Received state - disable sending of ECT =20 > with SYN segments. The document is aiming at specifying behavior without specifying implementation-specific state. We made some revisions to this section, but did not discuss it in terms of the state maintained by the TCP initiator and responder. > 9. Section 3.2, 3rd para, last sentence - > "... initiator continues to set ECN-Echo flag ..." > Since the initiator is waiting for a SYN/ACK packet, which would =20 > arrive with the CWR bit set, under what circumstance would the =20 > initiator resend the ECN-Echo flag? I couldn't think of one, so I deleted that sentence. > 10. Section 3.2, 3rd para - > Packet duplication by a network can create some pathological cases =20 > which might need to be clarified. > * What if the initiator receives a second copy of the SYN/ACK packet =20= > with CE? > * What if the initiator receives a SYN/ACK packet with CE, and soon =20= > thereafter receives a duplicate SYN/ACK packet without CE? > * What if the initiator receives a SYN/ACK packet without CE, =20 > transitions to the SYN-Received and the Established state and then =20 > receives a SYN/ACK packet with CE. Should it do anything special? =20 > Presumably not. We added the following: "The TCP hosts follow the standard specification for the response to duplicate SYN/ACK packets (e.g., Section 3.4 of RFC 793)." > 11. Section 3.2, 5th para - > Last sentence seems garbled. Something is missing. Thanks, we rephrased it. > 12. Section 3.2 - > There is an opportunity here for both initiator and responder to =20 > update its RTT measurement and use it for subsequent timers. It can =20= > provide some benefit. Should we make use of it? We think this is outside the scope of this document. > 13. Section 3.2 - > The examples are very good in understanding the specification. Would =20= > be useful to separately write the precise specification about what =20 > the initiator and responder must/should and must not / should not do =20= > for various events in different TCP states. See suggestion above. While this comment is appreciated, we think we have to balance between =93overspecification=94 and having an ambiguous spec. We have left it as it is. > 14. General - > It might be worth mentioning that if a SYN/ACK with ECT is lost or =20 > its ACK response with ECN-Echo is lost - due to congestion - the =20 > responder ends up not reducing its initial congestion window size to =20= > 1. This is illustrated in Figure 1, so we didn't think there was any need to add this. > Also, the initiator does not ever reduce its initial congestion =20 > window size to 1 because of congestion. We didn't add this. This document does not discuss congestion on the forward path. > 15. Section 8 or elsewhere - > Might be useful to state that if congestion is in the initiator to =20 > responder direction, then this enhancement does not provide any =20 > benefits. > If congestion is in the responder to initiator direction, and data =20 > transfer is in the initiator to responder direction, this =20 > enhancement provides some benefit, since the initiator does not have =20= > to experience a 3 second timeout, if the SYN/ACK packet gets ECN-=20 > marked instead of getting dropped by the network. We thought this was clear from Section 6.1. > 16. General - > It might be useful to add counters (MIB variables?) for these events. We didn't add this. MIBs are usually addressed in separate documents. > 17. Appendices - editorial comments - > Some of the "Target Load" values are incorrectly stated as .95%, =20 > 1.5%, etc. > Table 2 - Target Load =3D 150% line is missing. Thanks, fixed. > 18. Section 1, Garbled sentence - "The sender of the SYN/ACK =20 > packet ... (a router with the CE codepoint set in the ECN field of =20 > the IP header)". > Should it be "... (a packet with the ...)"? Fixed. > 19. Section 1, minor comment - > Sentence - "RFC 3168 only specifies marking Congestion Experienced =20 > codepoint on TCP's data packets". > Might be better stated as "RFC3168 only specifies marking ECN-=20 > Capable codepoint on TCP's data packets". Done. Many thanks for all of the feedback! From wesley.m.eddy@nasa.gov Wed May 13 11:05:19 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E8FD28C216 for ; Wed, 13 May 2009 11:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.451 X-Spam-Level: X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfERApWlTw+X for ; Wed, 13 May 2009 11:05:18 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id 8BDCA28C21B for ; Wed, 13 May 2009 11:05:18 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id D69C17906E; Wed, 13 May 2009 13:06:50 -0500 (CDT) Received: from ndjshub02.ndc.nasa.gov (ndjshub02.ndc.nasa.gov [198.117.4.161]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n4DI6odm002892; Wed, 13 May 2009 13:06:50 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.4.161]) with mapi; Wed, 13 May 2009 13:06:50 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: "tcpm@ietf.org" Date: Wed, 13 May 2009 13:06:51 -0500 Thread-Topic: Compound TCP draft Thread-Index: AcnT9Zd1O2/151pZS1eFBxTmr15yQQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-05-13_08:2009-04-28, 2009-05-13, 2009-05-12 signatures=0 Cc: Murari Sridharan , "Deepak Bansal \(NETWORKING\)" , Dave Thaler Subject: [tcpm] Compound TCP draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 18:05:19 -0000 TCPMers: For awhile, there has been a Compound TCP draft available: http://www.ietf.org/internet-drafts/draft-sridharan-tcpm-ctcp-02.txt The authors would like this to become a working group item with a target of Experimental in TCPM. The draft has received a large amount of detailed review during evaluation done in the ICCRG: http://www.ietf.org/mail-archive/web/tcpm/current/msg04241.html This has followed the process in the ION at: http://www.ietf.org/IESG/content/ions/ion-tsv-alt-cc.txt At this point in time, TCPM has not discussed the draft yet, and we would like to begin that discussion and feedback from the WG about taking it onto the charter as an item for Experimental. Please provide comments on this to the list. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- From wesley.m.eddy@nasa.gov Wed May 13 11:35:15 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF21428C225 for ; Wed, 13 May 2009 11:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEE7IFfLzBM8 for ; Wed, 13 May 2009 11:35:15 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id D430D28C215 for ; Wed, 13 May 2009 11:35:14 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 182BE108113; Wed, 13 May 2009 13:36:47 -0500 (CDT) Received: from ndjshub01.ndc.nasa.gov (ndjshub01.ndc.nasa.gov [198.117.4.160]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n4DIakoK004768; Wed, 13 May 2009 13:36:46 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.4.160]) with mapi; Wed, 13 May 2009 13:36:46 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: "tcpm@ietf.org" Date: Wed, 13 May 2009 13:36:48 -0500 Thread-Topic: WGLC on draft-ietf-tcpm-early-rexmt-01 Thread-Index: Acm9GA415Wd77/J2SpqUcp662SX2dQW39jMg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-05-13_08:2009-04-28, 2009-05-13, 2009-05-12 signatures=0 Cc: "k.avrachenkov@sophia.inria.fr" , Josh, "mallman@icir.org" , Blanton Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 18:35:15 -0000 TCP Maintainers & Minor Extenders: The WGLC came and went on the Early Retransmit draft without a single comment. If it really is perfect, then someone should speak up and say so :). As the chairs, we don't have a good feeling about forwarding this draft up for publication without any discussion in the WG, so we are proposing to hold it here until at least a handful of people submit comments on it.=20 Please review and provide WGLC feedback on this draft so that it can make progress: http://tools.ietf.org/html/draft-ietf-tcpm-early-rexmt-01 --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Eddy, Wesley M. (GRC-RCN0)[Verizon] >Sent: Tuesday, April 14, 2009 11:46 AM >To: tcpm@ietf.org >Cc: k.avrachenkov@sophia.inria.fr; Josh Blanton; mallman@icir.org >Subject: [tcpm] WGLC on draft-ietf > >We'd like to start a 2-week TCPM working group last call on the >early retransmit draft: >http://tools.ietf.org/html/draft-ietf-tcpm-early-rexmt-01 >I don't think the document itself says it, but our charter has >this for an Experimental target. > >WGLC comments would be appreciated by April 30. > >The document has been cooking for a long time in TSVWG before >TCPM took it, and the authors think it's pretty mature based >on the progress on it there and in TCPM since it was taken >up by TCPM at IETF 69. > >--------------------------- >Wes Eddy >Network & Systems Architect >Verizon FNS / NASA GRC >Office: (216) 433-6682 >--------------------------- > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From root@core3.amsl.com Wed May 13 12:15:01 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AA9D63A6FF2; Wed, 13 May 2009 12:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090513191501.AA9D63A6FF2@core3.amsl.com> Date: Wed, 13 May 2009 12:15:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-ecnsyn-09.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 19:15:01 -0000 --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 Filename : draft-ietf-tcpm-ecnsyn-09.txt Pages : 33 Date : 2009-05-13 The proposal in this document is experimental. While it may be deployed in the current Internet, it does not represent a consensus that this is the best possible mechanism for the use of ECN in TCP SYN/ACK packets. This draft describes an optional, experimental modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 specifies setting an ECN-Capable codepoint on data packets, but 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 retransmission timeout, this document describes 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 the initial TCP SYN/ACK packet as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmission timeout for a connection that has not yet started placing a load on the network. The TCP responder (the sender of the SYN/ACK packet) must reply to a report of an ECN- marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN- Capable. If the resent SYN/ACK packet is acknowledged, then the TCP responder reduces its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. If instead the SYN/ACK packet is dropped, or for some other reason the TCP responder does not receive an acknowledgement in the specified time, the TCP responder follows TCP standards for a dropped SYN/ACK packet (setting the retransmission timer). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-ecnsyn-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-tcpm-ecnsyn-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-13120824.I-D@ietf.org> --NextPart-- From iljitsch@muada.com Thu May 14 07:05:25 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068CA3A6F4F for ; Thu, 14 May 2009 07:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bow5TxLYZA+B for ; Thu, 14 May 2009 07:05:24 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id F190F3A6F43 for ; Thu, 14 May 2009 07:05:23 -0700 (PDT) Received: from [163.117.139.52] ([163.117.139.52]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n4EE4VNt071934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 May 2009 16:04:46 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 14 May 2009 16:04:38 +0200 References: X-Mailer: Apple Mail (2.935.3) Cc: "k.avrachenkov@sophia.inria.fr" , Blanton , "tcpm@ietf.org" , Josh@core3.amsl.com, "mallman@icir.org" Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 14:05:25 -0000 On 13 mei 2009, at 20:36, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > TCP Maintainers & Minor Extenders: The WGLC came and went on the > Early Retransmit draft without a single comment. If it really is > perfect, then someone should speak up and say so :). I think the non-SACK stuff should be removed and that the use of SACK should be made mandatory. First of all, this doesn't matter in practice because everybody (for a large value of "everybody") supports SACK today anyway. Second, allowing people to pick and choose arbitrarily is a bad precedent and undermines our work. I would like to see the fast retransmit threshold be dependent on the actually observed reordering, but I don't think that would work in the common use case addressed here, were the whole session is over after a handful of segments. From mallman@icir.org Thu May 14 07:21:45 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B485B3A6F44 for ; Thu, 14 May 2009 07:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlfMLS3r3Zhp for ; Thu, 14 May 2009 07:21:44 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id DF44E3A6F63 for ; Thu, 14 May 2009 07:21:15 -0700 (PDT) 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 n4EELSf1010246; Thu, 14 May 2009 07:21:28 -0700 Received: from lawyers.icir.org (unknown [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 5BF473A0B05C; Thu, 14 May 2009 10:21:22 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 92E5AD4B6D7; Thu, 14 May 2009 10:21:22 -0400 (EDT) To: Iljitsch van Beijnum From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Lawyers, Guns and Money MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma10465-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 14 May 2009 10:21:22 -0400 Sender: mallman@icir.org Message-Id: <20090514142122.92E5AD4B6D7@lawyers.icir.org> Cc: "k.avrachenkov@sophia.inria.fr" , Blanton , "tcpm@ietf.org" , Josh@core3.amsl.com Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 14:21:45 -0000 ----------ma10465-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > I think the non-SACK stuff should be removed and that the use of > SACK should be made mandatory. > > First of all, this doesn't matter in practice because everybody (for > a large value of "everybody") supports SACK today anyway. We wondered about this at some point in the past and I don't think we ever developed consensus that completely cutting to SACK was a good idea. Personally, I have no problem with it as SACK is clearly the way to go and, as you note, it is widely supported. So, I am personally on-board if the WG wants us to chop those sections out. (I do not, however, speak for my co-authors on this. I don't recall their hit.) (We just finished putting together a wide-ranging study of traffic from DSL customers and found 97% of the connections trying to use SACK (i.e., in the SYN) and 82% of the connections ultimately using SACK (i.e., also in the SYN+ACK). On a host-level we find 82-94% of the hosts use SACK (the variation is across datasets and also across host counting techniques since we cannot simply use IP address or even DSL line-id because of NATs).) > Second, allowing people to pick and choose arbitrarily is a bad > precedent and undermines our work. (I don't know that I buy this angle, however.) > I would like to see the fast retransmit threshold be dependent on the > actually observed reordering, but I don't think that would work in the > common use case addressed here, were the whole session is over after a > handful of segments. Right... this is a pretty constrained case. See RFC 4653 for a more general way to address reordering. allman ----------ma10465-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkoMKOEACgkQWyrrWs4yIs4ijgCeLuTZ35REV3LSEoAXfpOhtNhC Wd4AoIJFVekrROTfCMzgFReZiNQ7WWj3 =6WsJ -----END PGP SIGNATURE----- ----------ma10465-1-- From wesley.m.eddy@nasa.gov Thu May 14 07:21:45 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9163A6F44 for ; Thu, 14 May 2009 07:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zx0JABhOtqPk for ; Thu, 14 May 2009 07:21:45 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id D72703A703B for ; Thu, 14 May 2009 07:21:19 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 34D4A793FB; Thu, 14 May 2009 09:22:43 -0500 (CDT) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n4EEMh01029559; Thu, 14 May 2009 09:22:43 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Thu, 14 May 2009 09:22:42 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: Iljitsch van Beijnum Date: Thu, 14 May 2009 09:22:41 -0500 Thread-Topic: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01 Thread-Index: AcnUnUD8CRuml/o3S1eFDshzeq/9OwAAZq4g Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-05-13_09:2009-04-28, 2009-05-13, 2009-05-12 signatures=0 Cc: "k.avrachenkov@sophia.inria.fr" , Blanton , "tcpm@ietf.org" , "Josh@core3.amsl.com" , "mallman@icir.org" Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 14:21:46 -0000 Making SACK mandatory is far outside the scope of this draft and the WGLC ... I think it should be in a separate thread if we want to consider it, and not impact the near-term progress of this draft, as this is a much larger (and harder) topic. The authors can probably speak to the second point about pegging the retransmit threshold to the observed reordering, but I would guess that the challenge there lies in measuring the observed reordering within resource limitations. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- >-----Original Message----- >From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] >Sent: Thursday, May 14, 2009 10:05 AM >To: Eddy, Wesley M. (GRC-MS00)[Verizon] >Cc: tcpm@ietf.org; k.avrachenkov@sophia.inria.fr; Josh@core3.amsl.com; >mallman@icir.org; Blanton >Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01 > >On 13 mei 2009, at 20:36, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > >> TCP Maintainers & Minor Extenders: The WGLC came and went on the >> Early Retransmit draft without a single comment. If it really is >> perfect, then someone should speak up and say so :). > >I think the non-SACK stuff should be removed and that the use of SACK >should be made mandatory. > >First of all, this doesn't matter in practice because everybody (for a >large value of "everybody") supports SACK today anyway. > >Second, allowing people to pick and choose arbitrarily is a bad >precedent and undermines our work. > >I would like to see the fast retransmit threshold be dependent on the >actually observed reordering, but I don't think that would work in the >common use case addressed here, were the whole session is over after a >handful of segments. From iljitsch@muada.com Thu May 14 07:26:56 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18A753A6F30 for ; Thu, 14 May 2009 07:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeLrgwZsLLQa for ; Thu, 14 May 2009 07:26:55 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 04D573A6E70 for ; Thu, 14 May 2009 07:26:54 -0700 (PDT) Received: from [163.117.139.52] ([163.117.139.52]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n4EERX0i072106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 May 2009 16:27:33 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <9CA2C1CF-A7D3-42A8-8BC3-4E48E9C7348D@muada.com> From: Iljitsch van Beijnum To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 14 May 2009 16:27:39 +0200 References: X-Mailer: Apple Mail (2.935.3) Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 14:26:56 -0000 On 14 mei 2009, at 16:22, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > Making SACK mandatory is far outside the scope of this draft > and the WGLC ... Obviously I meant within the scope of the draft. So if you want to implement this draft, you can only do that on a system that also implements SACK. From wesley.m.eddy@nasa.gov Thu May 14 07:28:46 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8272028C271 for ; Thu, 14 May 2009 07:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zKkG9rE8JWR for ; Thu, 14 May 2009 07:28:45 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id B844928C105 for ; Thu, 14 May 2009 07:28:45 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 44CE110811A; Thu, 14 May 2009 09:30:15 -0500 (CDT) Received: from ndjshub02.ndc.nasa.gov (ndjshub02.ndc.nasa.gov [198.117.4.161]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n4EEUF6U009635; Thu, 14 May 2009 09:30:15 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.4.161]) with mapi; Thu, 14 May 2009 09:30:14 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: Iljitsch van Beijnum Date: Thu, 14 May 2009 09:30:13 -0500 Thread-Topic: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01 Thread-Index: AcnUoEFoSIG81+2qTkikP49xgxLFgwAACTIQ Message-ID: References: <9CA2C1CF-A7D3-42A8-8BC3-4E48E9C7348D@muada.com> In-Reply-To: <9CA2C1CF-A7D3-42A8-8BC3-4E48E9C7348D@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-05-13_09:2009-04-28, 2009-05-13, 2009-05-12 signatures=0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 14:28:46 -0000 Oh, well that makes more sense; for some reason it wasn't so obvious to me :). Thanks for clarifying. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- >-----Original Message----- >From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] >Sent: Thursday, May 14, 2009 10:28 AM >To: Eddy, Wesley M. (GRC-MS00)[Verizon] >Cc: tcpm@ietf.org >Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01 > >On 14 mei 2009, at 16:22, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > >> Making SACK mandatory is far outside the scope of this draft >> and the WGLC ... > >Obviously I meant within the scope of the draft. > >So if you want to implement this draft, you can only do that on a >system that also implements SACK. From mallman@icir.org Thu May 14 07:30:22 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17ED028C278 for ; Thu, 14 May 2009 07:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lscL+nqe9Ik for ; Thu, 14 May 2009 07:30:21 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 32E3C3A6EFD for ; Thu, 14 May 2009 07:30:21 -0700 (PDT) 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 n4EEUUhM010469; Thu, 14 May 2009 07:30:30 -0700 Received: from lawyers.icir.org (unknown [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 770803A0B1BA; Thu, 14 May 2009 10:30:24 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C056FD4B75D; Thu, 14 May 2009 10:30:24 -0400 (EDT) To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Lawyers, Guns and Money MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma11008-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 14 May 2009 10:30:24 -0400 Sender: mallman@icir.org Message-Id: <20090514143024.C056FD4B75D@lawyers.icir.org> Cc: "tcpm@ietf.org" , "k.avrachenkov@sophia.inria.fr" , "Josh@core3.amsl.com" , Blanton Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 14:30:22 -0000 ----------ma11008-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Making SACK mandatory is far outside the scope of this draft > and the WGLC ... I think it should be in a separate thread if > we want to consider it, and not impact the near-term progress > of this draft, as this is a much larger (and harder) topic. Perhaps we took this comment two different ways. I took it to suggest only specifying the SACK variant of early retransmit---which I believe would be perfectly within he purview of this draft. > The authors can probably speak to the second point about > pegging the retransmit threshold to the observed reordering, > but I would guess that the challenge there lies in measuring > the observed reordering within resource limitations. Per my previous message ER is so scoped to particular situations that this isn't all that possible. We sketch some thoughts to protect against pathological reordering in the appendix. Our intent for this document is that it be experimental and so it is not clear to me what more we can or should do before this goes experimental. But, obviously, we're happy to have input. allman ----------ma11008-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkoMKwAACgkQWyrrWs4yIs4GCgCePwidzkNDGgfdXxnVjwXCfXZP EPUAoI7pEC8DQMyDrCH0AmyhMZIDA7Jh =+Y4i -----END PGP SIGNATURE----- ----------ma11008-1-- From iljitsch@muada.com Thu May 14 07:44:32 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBFBC28C24E for ; Thu, 14 May 2009 07:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9Je8AdE6el8 for ; Thu, 14 May 2009 07:44:31 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 79EF028C288 for ; Thu, 14 May 2009 07:44:31 -0700 (PDT) Received: from [163.117.139.52] ([163.117.139.52]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n4EEiVdZ072247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 May 2009 16:44:32 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 14 May 2009 16:44:38 +0200 References: X-Mailer: Apple Mail (2.935.3) Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 14:44:32 -0000 On 14 mei 2009, at 16:24, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > Oh, and thanks for replying to the WGLC :). Other than the > comments you raised, do you think the draft looks good to > publish? I don't like the part about tracking the seqnum edges. Why would someone send 400 byte packets when the MSS is 1400+? How does this interact with the Nagle algorithm? From root@core3.amsl.com Thu May 14 10:45:01 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 62FA728C2F0; Thu, 14 May 2009 10:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090514174501.62FA728C2F0@core3.amsl.com> Date: Thu, 14 May 2009 10:45:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-rfc2581bis-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 17:45:01 -0000 --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 Congestion Control Author(s) : V. Paxson, E. Blanton, M. Allman Filename : draft-ietf-tcpm-rfc2581bis-05.txt Pages : 16 Date : 2009-5-14 This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc2581bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-tcpm-rfc2581bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-5-14103402.I-D@ietf.org> --NextPart-- From mallman@icir.org Fri May 15 05:36:54 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C10F3A6BD2 for ; Fri, 15 May 2009 05:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPnmpxgOpGFk for ; Fri, 15 May 2009 05:36:53 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id DCDF93A6A80 for ; Fri, 15 May 2009 05:36:53 -0700 (PDT) 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 n4FCcR5G003532; Fri, 15 May 2009 05:38:27 -0700 Received: from lawyers.icir.org (unknown [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id ED1403A122B2; Fri, 15 May 2009 08:38:20 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1C7EBD513E2; Fri, 15 May 2009 08:38:19 -0400 (EDT) To: Iljitsch van Beijnum From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Lawyers, Guns and Money MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma25144-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 15 May 2009 08:38:19 -0400 Sender: mallman@icir.org Message-Id: <20090515123819.1C7EBD513E2@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 12:36:54 -0000 ----------ma25144-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > I don't like the part about tracking the seqnum edges. > > Why would someone send 400 byte packets when the MSS is 1400+? Something interactive like ssh. Why do we give apps the chance to turn off Nagle? It's a big, ugly world with a vast range of behavior. > How does this interact with the Nagle algorithm? As sketched in the draft ... + You can use a byte-based variant of ER which assumes MSS-sized packets. As discussed in the draft this *can* have precision problems in terms of determining the number of packets outstanding in the network and therefore when ER should and should not be used. In particular, if Nagle is turned off and so short packets are being sent then ER can get confused (see two examples in section 2.1. + Given that there can be a lack of precision we note that a TCP could in fact track the three packets on the right side of the window (four sequence numbers) to fully grok how many packets are in the network [*] and therefore to more accurately trigger ER. This in particular helps when Nagle is in use. I am not clear what you are getting at by an 'interaction'. I don't think ER interacts with Nagle, but the packet-based variant does cope with Nagle. [*] Obviously tracking only the right side of the window doesn't give you a fine-grained notion of how many packets are in the network in total. It tells you that either (a) there are at least four (and so we're out of the ER regime) or (b) there are less than four outstanding packets and how many there actually are. So, it works for ER's purpose. allman ----------ma25144-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkoNYjoACgkQWyrrWs4yIs79qQCgmNJpxu+mGrzqqLIhSMRX51v8 Iu0An2B28I+MAj5tTV6b0XksPm/bd4c3 =qyAD -----END PGP SIGNATURE----- ----------ma25144-1-- From nwnetworks@dial.pipex.com Sun May 17 23:08:21 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C97743A6F5F for ; Sun, 17 May 2009 23:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.96 X-Spam-Level: X-Spam-Status: No, score=0.96 tagged_above=-999 required=5 tests=[AWL=1.145, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19vLD-oZ0mv1 for ; Sun, 17 May 2009 23:08:20 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id BE04F3A6F6B for ; Sun, 17 May 2009 23:08:19 -0700 (PDT) X-Trace: 104039141/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.136/None/nwnetworks@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.136 X-IP-MAIL-FROM: nwnetworks@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEANOYEEo+vBGI/2dsb2JhbACDKItGwAIHg3oF X-IronPort-AV: E=Sophos;i="4.41,208,1241391600"; d="scan'208";a="104039141" X-IP-Direction: IN Received: from 1cust136.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.136]) by smtp.pipex.tiscali.co.uk with SMTP; 18 May 2009 07:09:51 +0100 Message-ID: <005201c9d776$c88bfce0$0601a8c0@allison> From: "Tom Petch" To: "Brian E Carpenter" References: <20090402150706.EC83D28C222@core3.amsl.com> <49E3ADA4.1090402@gont.com.ar> <0C53DCFB700D144284A584F54711EC58070763E3@xmb-sjc-21c.amer.cisco.com> <49E8EE86.3010600@gmail.com> Date: Mon, 18 May 2009 07:02:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: tcpm@ietf.org Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP'sRobustness to Blind In-Window Attacks) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Tom Petch List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 06:08:21 -0000 ----- Original Message ----- From: "Brian E Carpenter" To: "Fernando Gont" Cc: ; "Anantha Ramaiah (ananth)" ; Sent: Friday, April 17, 2009 11:03 PM Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP'sRobustness to Blind In-Window Attacks) to Proposed Standard > On 2009-04-17 17:14, Fernando Gont wrote: > > On Mon, Apr 13, 2009 at 10:23 PM, Anantha Ramaiah (ananth) > > wrote: > > > >>> * The document never mentions the fact that this document is > >>> IPR-encumbered. > ... > > I personally believe this should be noted in all RFCs on which there's > > a known IPR. However, Joel Halpern mentioned this is not current > > practice. If that's the case, I'd have no problem with leaving it "as > > is". (FWIW, if you look at our tcp-security document, we do recommend > > the implementation of the counter-measures you propose, but just note > > that there's an IPR, and that implementers should research how this > > would affect them). > > Personal belief doesn't come into it. It's strictly defined in a BCP. > RFC3979 tells us the rules about this. Basically, the RFC Editor will > do what is required: > > "4. Actions for Documents for which IPR Disclosure(s) Have Been Received > > (A) When any Intellectual Property Right is disclosed before > publication as an RFC, with respect to any technology or > specification, described in a Contribution in the manner set > forth in Section 6 of this document, the RFC Editor shall ensure > that the document include a note indicating the existence of such > claimed Intellectual Property Rights in any RFC published from > the Contribution. (See Section 5 below.)" > > [Section 5 defines the exact text to be included in such RFCs. > I believe you can use in xml2rfc.] This is what I thought but .... RFC5425 has recently been published and I can find no mention of IPR claims in it. The IESG Protocol Action Message-Id: <20081008150846.3A3B03A6BDE@core3.amsl.com> calls out the fact that claims were made, in fact repeatedly so, against each successive version of the I-D. So why nothing in the RFC? What am I missing? Tom Petch > "11. No IPR Disclosures in IETF Documents > > IETF and RFC Editor Documents must not contain any mention of > specific IPR. All specific IPR disclosures must be submitted as > described in Section 6. Specific IPR disclosures must not be in the > affected IETF and RFC Editor Documents because the reader could be > misled. The inclusion of a particular IPR disclosure in a document > could be interpreted to mean that the IETF, IESG, or RFC Editor has > formed an opinion on the validity, enforceability, or applicability > of the IPR. The reader could also be misled to think that the > included IPR disclosures are the only IPR disclosures the IETF has > received concerning the IETF document. Readers should always refer > to the on-line web page to get a full list of IPR disclosures > received by the IETF concerning any Contribution. > (http://www.ietf.org/ipr/)" > > Brian > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From iljitsch@muada.com Mon May 18 07:23:30 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F83B3A6E05 for ; Mon, 18 May 2009 07:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1OUA3Iwsbn2 for ; Mon, 18 May 2009 07:23:29 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 461D93A6D76 for ; Mon, 18 May 2009 07:23:29 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.52]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n4IEOLLQ005705 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 May 2009 16:24:22 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: mallman@icir.org In-Reply-To: <20090515123819.1C7EBD513E2@lawyers.icir.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 18 May 2009 16:24:30 +0200 References: <20090515123819.1C7EBD513E2@lawyers.icir.org> X-Mailer: Apple Mail (2.935.3) Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 14:23:30 -0000 On 15 mei 2009, at 14:38, Mark Allman wrote: >> I don't like the part about tracking the seqnum edges. >> Why would someone send 400 byte packets when the MSS is 1400+? > Something interactive like ssh. Why do we give apps the chance to > turn > off Nagle? It's a big, ugly world with a vast range of behavior. Yes, but you don't want all that behavior to be reflected in the decision tree in your TCP implementation. Would it be possible to specify a single behavior that is simple, provides the intended benefits in the common cases that compromise 90% or more of all cases and doesn't do worse than what we have today in the remaining cases? From mallman@icir.org Mon May 18 08:21:30 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B62963A7049 for ; Mon, 18 May 2009 08:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.519 X-Spam-Level: X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWNFhz8eQ0+S for ; Mon, 18 May 2009 08:21:24 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id CAB4E3A67AE for ; Mon, 18 May 2009 08:21:11 -0700 (PDT) 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 n4IFMlOV002269; Mon, 18 May 2009 08:22:47 -0700 Received: from lawyers.icir.org (unknown [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 4ADDC3A23262; Mon, 18 May 2009 11:22:41 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 8C4F1D5C2C4; Mon, 18 May 2009 11:22:41 -0400 (EDT) To: Iljitsch van Beijnum From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Lawyers, Guns and Money MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma32063-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 18 May 2009 11:22:41 -0400 Sender: mallman@icir.org Message-Id: <20090518152241.8C4F1D5C2C4@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 15:21:30 -0000 ----------ma32063-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > >> I don't like the part about tracking the seqnum edges. > > >> Why would someone send 400 byte packets when the MSS is 1400+? > > > Something interactive like ssh. Why do we give apps the chance to > > turn off Nagle? It's a big, ugly world with a vast range of > > behavior. > > Yes, but you don't want all that behavior to be reflected in the > decision tree in your TCP implementation. I guess I have lost track of what you really don't like here. Early retransmit depends on having a notion of how many *packets* are outstanding. However, since TCP work in terms of *bytes* this is not readily apparent. When you get down to it all the draft says is that you have to somehow figure out how many packets are outstanding and to do so you can do estimation on one end of the spectrum to full tracking on the other end. These options both have their pros and cons and so we leave it to the implementer to puzzle through these for their own implementation. Sure, it would be nice if I could tie a "method [foo] is always best, use it" bow around this question. But, I don't know what [foo] is. Perhaps that can be viewed as part of the experiment here. If you know what [foo] is and why then certainly tell us because that's useful information. But, in the absence of such an answer that is based on observations of actual network behavior (i.e., as opposed to simple conjecture or our all-too-often-wrong mental models of how networks work) my inclination here is to leave the draft as it is and let the implementers choose and then we can go look at those those choices are working after some period of time. > Would it be possible to specify a single behavior that is simple, > provides the intended benefits in the common cases that compromise 90% > or more of all cases and doesn't do worse than what we have today in > the remaining cases? If don't view any of ER as complicated in any form. But, certainly YMMV. Further, note that ER provides additional opportunities to retransmit some packet and I do not expect it to be worse that what we have today. (The only chance of it being worse is that reordering could cause needless retransmits that both waste network resources and reduce the cwnd (although the impact of both of these is likely very minor within the well-defined scope of ER).) allman ----------ma32063-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkoRfUEACgkQWyrrWs4yIs53ewCcDuF2fbVf379C1ombIsf64ZEU wWoAn2rW4Ekubsoajyv3E/kEqxJUqUU2 =fHnI -----END PGP SIGNATURE----- ----------ma32063-1-- From jblanton@irg.cs.ohiou.edu Mon May 18 09:13:14 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6FE23A6D28 for ; Mon, 18 May 2009 09:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+Y92sjx11fZ for ; Mon, 18 May 2009 09:13:08 -0700 (PDT) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.124]) by core3.amsl.com (Postfix) with ESMTP id D47623A68F9 for ; Mon, 18 May 2009 09:13:07 -0700 (PDT) Received: from mauser.ipx.ath.cx ([75.186.30.55]) by hrndva-omta01.mail.rr.com with ESMTP id <20090518161422721.DPKI8008@hrndva-omta01.mail.rr.com>; Mon, 18 May 2009 16:14:22 +0000 Received: by mauser.ipx.ath.cx (Postfix, from userid 500) id A50DD18274; Mon, 18 May 2009 12:14:21 -0400 (EDT) Date: Mon, 18 May 2009 12:14:21 -0400 From: Joshua Blanton To: Iljitsch van Beijnum Message-ID: <20090518161421.GA25791@mauser.ipx.ath.cx> Mail-Followup-To: Iljitsch van Beijnum , mallman@icir.org, tcpm@ietf.org References: <20090515123819.1C7EBD513E2@lawyers.icir.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: X-Operating-System: Linux User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Joshua Blanton List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 16:13:14 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Iljitsch van Beijnum wrote: > Would it be possible to specify a single behavior that is simple, =20 > provides the intended benefits in the common cases that compromise 90% = =20 > or more of all cases and doesn't do worse than what we have today in the= =20 > remaining cases? Is that not what section 2.1 describes? Note that the boundary-tracking method is *optional* - as is the byte-counting method - so if an implementor feels that boundary tracking is an unacceptable burden, it can be left out. Similarly, if an implementor feels that the byte-counting method is too inexact, the boundary-tracking version may be chosen. Josh --LQksG6bCIzRHxTLp 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) iD8DBQFKEYld1dp8qWK2G7QRAueqAKDrhogz/C95e8ZQ999cjltsrfFYGQCfdj2G ykDkou+T+R/kklayrgbvhpk= =OomC -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From fernando.gont.netbook.win@gmail.com Tue May 19 08:00:04 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D42B03A6E1D for ; Tue, 19 May 2009 08:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeOOFPq6E8qe for ; Tue, 19 May 2009 08:00:04 -0700 (PDT) Received: from mail-qy0-f114.google.com (mail-qy0-f114.google.com [209.85.221.114]) by core3.amsl.com (Postfix) with ESMTP id 003F33A6D61 for ; Tue, 19 May 2009 08:00:03 -0700 (PDT) Received: by qyk12 with SMTP id 12so673047qyk.29 for ; Tue, 19 May 2009 08:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=lKXrHcfSjfPj7tUG6/eEwAeSp6xPYs7lNXR6lvwF/rM=; b=DN2UOAU7WFnrM2Dc02QvkC17fhGTSAAhCo6MO+0cG36BUz9ank6gfnEoLnVs2eXZL4 1qnbhK4pfRFQy3d6Y5M4ntS6c3qxypado5xnAdD+bQDJQXI1gLS1wwgNMTHPW8Y9iAoY 4DSSGtaqZSjSScfsSCgIcQMnWI1nyOB2r0aDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=l87DA86YJ2Je852k+X4pTL82GhQDdKGP6Bo7drRu0FvkQfue2TqI8s1PR0nzn0NBAf XEx6sS/XGGzpIYotT6SsPySS9xtapFfWDaLLRzxYB6CEfpQm7P6T2vdyUZR6vCSYHGxM fakNnlKo47GguBLoNXJ/MouBWv/jjxlQ1cd/c= Received: by 10.229.110.6 with SMTP id l6mr27754qcp.52.1242745298621; Tue, 19 May 2009 08:01:38 -0700 (PDT) Received: from ?172.16.1.133? (host87.190-139-184.telecom.net.ar [190.139.184.87]) by mx.google.com with ESMTPS id 4sm3941240yxq.24.2009.05.19.08.01.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 May 2009 08:01:37 -0700 (PDT) Sender: Fernando Gont Message-ID: <4A12C9C9.9060404@gont.com.ar> Date: Tue, 19 May 2009 12:01:29 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "tcpm@ietf.org" X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] urgent data draft (draft-gont-tcpm-urgent-data-01.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 15:00:04 -0000 Hello, folks, I'm planning to work on a revision of the urgent data I-D anytime soon. I was wondering if there are any plans for proceeding with this I-D. There was some discussion on-list about TCP urgent data, and IIRC Dave Borman had suggested (hat off) that this I-D be adopted as a WG item. Thoughts? Plans? Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From dab@weston.borman.com Tue May 19 08:25:37 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8B73A6BC3 for ; Tue, 19 May 2009 08:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxkc3Y2DuW35 for ; Tue, 19 May 2009 08:25:36 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 21E783A6AEF for ; Tue, 19 May 2009 08:25:36 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id n4JFR7IU004525; Tue, 19 May 2009 08:27:08 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 08:27:07 -0700 Received: from [172.25.34.21] ([172.25.34.21]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 08:27:07 -0700 Message-Id: From: David Borman To: Fernando Gont , tcpm@ietf.org In-Reply-To: <4A12C9C9.9060404@gont.com.ar> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 19 May 2009 10:27:05 -0500 References: <4A12C9C9.9060404@gont.com.ar> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 19 May 2009 15:27:07.0670 (UTC) FILETIME=[45559360:01C9D896] Cc: tcpm-chairs@tools.ietf.org Subject: Re: [tcpm] urgent data draft (draft-gont-tcpm-urgent-data-01.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 15:25:37 -0000 I think I forgot to follow up on this, sorry! So, with my WG co-chair hat on: The agreement at the San Francisco IETF meeting on the Urgent Pointer definition was: 1) Adopt this document as a WG item 2) Change the definition of the Urgent Pointer (defined in RFC 1122) to match the definition on page 17 of RFC 793, which is what most implementations use. 3) New applications should be discouraged from using the Urgent Pointer 4) TCP implementations still need to implement the Urgent Pointer for existing applications that use it 5) All applications that do make use of the Urgent Pointer must use the SO_OOBINLINE socket option to keep all of the data in sequence; applications that don't use SO_OOBINLINE and continue to use the old, broken BSD implementation that actually removes bytes of data from data stream are out of scope for the IETF, since that is not part of the TCP protocol. Please respond with whether you do or do not support adopting this as a WG item, even if you were at the meeting, so that we have a record on the mailing list. Now with my WG chair hat off: I support adopting this as a WG item. -David Borman, TCPM WG co-chair On May 19, 2009, at 10:01 AM, Fernando Gont wrote: > Hello, folks, > > I'm planning to work on a revision of the urgent data I-D anytime > soon. > I was wondering if there are any plans for proceeding with this I-D. > > There was some discussion on-list about TCP urgent data, and IIRC Dave > Borman had suggested (hat off) that this I-D be adopted as a WG item. > > Thoughts? Plans? > > Thanks! > > Kind regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Tue May 19 09:06:15 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38E3C3A6EAE for ; Tue, 19 May 2009 09:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prfQ5I-r7N6o for ; Tue, 19 May 2009 09:06:14 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 1689A3A6F55 for ; Tue, 19 May 2009 09:05:55 -0700 (PDT) Received: from [128.9.161.245] ([128.9.161.245]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n4JG76TI015975; Tue, 19 May 2009 09:07:08 -0700 (PDT) Message-ID: <4A12D92A.8030306@isi.edu> Date: Tue, 19 May 2009 09:07:06 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Borman References: <4A12C9C9.9060404@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm-chairs@tools.ietf.org, tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] urgent data draft (draft-gont-tcpm-urgent-data-01.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 16:06:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I agree with all below. Joe David Borman wrote: > I think I forgot to follow up on this, sorry! > > So, with my WG co-chair hat on: > > The agreement at the San Francisco IETF meeting on the Urgent Pointer > definition was: > > 1) Adopt this document as a WG item > > 2) Change the definition of the Urgent Pointer (defined in RFC 1122) to > match the definition on page 17 of RFC 793, which is what most > implementations use. > > 3) New applications should be discouraged from using the Urgent Pointer > > 4) TCP implementations still need to implement the Urgent Pointer for > existing applications that use it > > 5) All applications that do make use of the Urgent Pointer must use the > SO_OOBINLINE socket option to keep all of the data in sequence; > applications that don't use SO_OOBINLINE and continue to use the old, > broken BSD implementation that actually removes bytes of data from data > stream are out of scope for the IETF, since that is not part of the TCP > protocol. > > Please respond with whether you do or do not support adopting this as a > WG item, even if you were at the meeting, so that we have a record on > the mailing list. > > > Now with my WG chair hat off: > > I support adopting this as a WG item. > > -David Borman, TCPM WG co-chair > > > > On May 19, 2009, at 10:01 AM, Fernando Gont wrote: > >> Hello, folks, >> >> I'm planning to work on a revision of the urgent data I-D anytime soon. >> I was wondering if there are any plans for proceeding with this I-D. >> >> There was some discussion on-list about TCP urgent data, and IIRC Dave >> Borman had suggested (hat off) that this I-D be adopted as a WG item. >> >> Thoughts? Plans? >> >> Thanks! >> >> Kind regards, >> -- >> Fernando Gont >> e-mail: fernando@gont.com.ar || fgont@acm.org >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoS2SoACgkQE5f5cImnZrvP2wCbBUsMrZ/C/ODkAwbT/oUisgup NjYAni4rrYLe6js0Tpsmv4+Wdm0/02h7 =aSCp -----END PGP SIGNATURE----- From fernando.gont.netbook.win@gmail.com Tue May 19 20:02:59 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB363A683B for ; Tue, 19 May 2009 20:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJriMThf9y3o for ; Tue, 19 May 2009 20:02:59 -0700 (PDT) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.240]) by core3.amsl.com (Postfix) with ESMTP id EDC7C3A67A8 for ; Tue, 19 May 2009 20:02:58 -0700 (PDT) Received: by ag-out-0708.google.com with SMTP id 23so36678agd.12 for ; Tue, 19 May 2009 20:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=gFimvqm+7EsfH+HabrDgRQdEsaxCubTTpsxtJoS1ius=; b=RR8CBBvhmA0bjqFHsbUjKoNoWonJATfHV0aPf3lWLXhw5AwCrIfXpEMeZrrQzjLjoi 9AsUcby2karXTocB/pR6ii1P61+ra99QN3rNu8+iBr4d0iM4UbYHX/hryUbVd/KfZLaw pYIBiKlOLhiAQbIWCqQ+9EXsafmPjOG8eaF9E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=cmULGMPf3UBgmtzO5kHl6Ovpe1SKyyAWq+dtQE24mY7Fbh/q/6XAemj2LuvTy+/aHi ZG93EN3U5PNIvApo8Y15B2R1byv3Vc2GTnGCJ1MO1rPRFYRidtlc2ZEhSYiqAjbINfQQ FPsRV5ZZwYSKPC4BlDJAJpcCVUAYNhptbq/Ng= Received: by 10.100.3.4 with SMTP id 4mr1431586anc.128.1242788673631; Tue, 19 May 2009 20:04:33 -0700 (PDT) Received: from ?192.168.0.151? (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id 8sm1695668ywg.43.2009.05.19.20.04.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 May 2009 20:04:32 -0700 (PDT) Sender: Fernando Gont Message-ID: <4A137338.9070004@gont.com.ar> Date: Wed, 20 May 2009 00:04:24 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Borman References: <4A12C9C9.9060404@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm-chairs@tools.ietf.org, tcpm@ietf.org Subject: Re: [tcpm] urgent data draft (draft-gont-tcpm-urgent-data-01.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 03:02:59 -0000 Hello, David, Thanks so much for your response! Comments in-line... > The agreement at the San Francisco IETF meeting on the Urgent Pointer > definition was: > > 1) Adopt this document as a WG item Should I resubmit the I-D as draft-ietf? Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From root@core3.amsl.com Wed May 20 17:00:01 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6541B3A6BFD; Wed, 20 May 2009 17:00:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090521000001.6541B3A6BFD@core3.amsl.com> Date: Wed, 20 May 2009 17:00:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-urgent-data-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 00:00:01 -0000 --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 : On the implementation of TCP urgent data Author(s) : F. Gont, A. Yourtchenko Filename : draft-ietf-tcpm-urgent-data-00.txt Pages : 11 Date : 2009-05-20 This document analyzes how current TCP implementations process TCP urgent indications, and how the behavior of some widely-deployed middle-boxes affect how urgent indications are processed by end systems. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, and raises awareness about the reliability of TCP urgent indications in the current Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-urgent-data-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-tcpm-urgent-data-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-20165152.I-D@ietf.org> --NextPart-- From pasi.sarolahti@iki.fi Thu May 21 02:14:02 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844EC3A6F51 for ; Thu, 21 May 2009 02:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4ZkHxnUk8+K for ; Thu, 21 May 2009 02:14:01 -0700 (PDT) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by core3.amsl.com (Postfix) with ESMTP id A7D033A6F45 for ; Thu, 21 May 2009 02:14:01 -0700 (PDT) Received: from [192.168.0.104] (a88-113-36-32.elisa-laajakaista.fi [88.113.36.32]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 526821517B2 for ; Thu, 21 May 2009 12:15:36 +0300 (EEST) Message-Id: From: Pasi Sarolahti To: tcpm@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 21 May 2009 12:15:34 +0300 X-Mailer: Apple Mail (2.935.3) Subject: [tcpm] Multipath TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 09:14:02 -0000 Hi, Some of you know this already, but there is an active discussion ongoing about Multipath TCP in a dedicated mailing list, which might be interesting to many of the TCPM readers. There are plans to have a BOF in the next IETF to discuss enhancements to TCP to make it capable of using multiple connection paths in parallel. If you are interested to take part in the discussion, you can get the mailing list info, and join the list, at https://www.ietf.org/mailman/listinfo/MultipathTcp . There are also a couple of related drafts, and some other material available at http://trac.tools.ietf.org/area/tsv/trac/wiki/MultipathTcp - Pasi From lars.eggert@nokia.com Thu May 21 20:00:42 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45DF03A6D50 for ; Thu, 21 May 2009 20:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqliriPl+6lX for ; Thu, 21 May 2009 20:00:41 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 1D50B3A6DF4 for ; Thu, 21 May 2009 20:00:40 -0700 (PDT) Received: from [192.168.1.18] (event-241.akiba-b.hpcc.jp [192.50.75.241]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n4M328fo086493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 May 2009 06:02:13 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <53AC2432-4B39-46FD-8414-F29EC648066C@nokia.com> From: Lars Eggert To: tcpm@ietf.org In-Reply-To: <29AE22C3-F03F-48A8-B335-A7C8E0265406@nokia.com> Content-Type: multipart/signed; boundary=Apple-Mail-20-513634832; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 22 May 2009 12:02:03 +0900 References: <20090402150706.EC83D28C222@core3.amsl.com> <29AE22C3-F03F-48A8-B335-A7C8E0265406@nokia.com> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Fri, 22 May 2009 06:02:16 +0300 (EEST) Cc: draft-ietf-tcpm-tcpsecure@tools.ietf.org Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 03:00:42 -0000 --Apple-Mail-20-513634832 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, authors, it's been over a month since the IETF last call ended, and I have not seen a document revision or even an attempt at discussing the comments you have received. Please start this discussion and eventually revise the document. Thanks, Lars On 2009-4-17, at 5:11, Eggert Lars (Nokia-NRC/Espoo) wrote: > Hi, authors, > > the IETF last call has ended, and it looks like the few comments I've > seen will require some text changes, so I'm placing this document in > the Revised ID Needed state. > > Also: Has the discussion of the comments that Fernando made concluded? > > Lars > > > On 2009-4-2, at 18:07, The IESG wrote: > >> The IESG has received a request from the TCP Maintenance and Minor >> Extensions WG (tcpm) to consider the following document: >> >> - 'Improving TCP's Robustness to Blind In-Window Attacks ' >> as a Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to >> the >> ietf@ietf.org mailing lists by 2009-04-16. Exceptionally, >> comments may be sent to iesg@ietf.org instead. In either case, please >> retain the beginning of the Subject line to allow automated sorting. >> >> The file can be obtained via >> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-11.txt >> >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11735&rfc_flag=0 >> >> The following IPR Declarations may be related to this I-D: >> >> https://datatracker.ietf.org/ipr/421/ >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > --Apple-Mail-20-513634832 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA1MjIwMzAyMDNaMCMGCSqGSIb3DQEJBDEWBBTrbWNuefphHhL3 ByrglRmZDWqyJzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAX7WUisENwcO01f2GSYwqRCWu5fFFGju+nNDkMwO/g034MXCkuUAI Z2ibSghuLJGHZE4VfVbViU8Cct3EQsRVCMUPSHT66dnL1LP/66w4AiKHZCzTuYjBmBlxQeiGvGlv +NdxMVwCR0ns56Gz8C7J4oKax7X6Fe1SFrMzhPIAIRPqpkUXp0nF+QANC+3IKkJihotPn+m7rqDi nzTASq5+jRiPDFJk7RCj0nYA/ubyYlr4mFMXAGIap6gBkq/HszmgwVbLahXeqBdyllckFQCE8g8i 3emyCnsmQK+Dio9IZ1ooIUWEQT3eeBv+y2dedDGjCIbtOwURfbJ9rl7A8VLX6gAAAAAAAA== --Apple-Mail-20-513634832-- From ananth@cisco.com Thu May 21 22:32:48 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E583A6EE7 for ; Thu, 21 May 2009 22:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BO0zNN40GUn2 for ; Thu, 21 May 2009 22:32:42 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7B0873A69B7 for ; Thu, 21 May 2009 22:32:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,231,1241395200"; d="scan'208";a="308945178" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 22 May 2009 05:33:58 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4M5XwIr002289; Thu, 21 May 2009 22:33:58 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4M5XwFv006229; Fri, 22 May 2009 05:33:58 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 May 2009 22:33:58 -0700 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, 21 May 2009 22:33:14 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58074EEA6E@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <53AC2432-4B39-46FD-8414-F29EC648066C@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard Thread-Index: AcnaicEx7z3HtG7FR3ev6lvcNYBaVQAE5IJg References: <20090402150706.EC83D28C222@core3.amsl.com> <29AE22C3-F03F-48A8-B335-A7C8E0265406@nokia.com> <53AC2432-4B39-46FD-8414-F29EC648066C@nokia.com> From: "Anantha Ramaiah (ananth)" To: "Lars Eggert" , X-OriginalArrivalTime: 22 May 2009 05:33:58.0330 (UTC) FILETIME=[E7AC81A0:01C9DA9E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2763; t=1242970438; x=1243834438; 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=20[tcpm]=20Last=20Call=3A=20draft-ietf-tc pm-tcpsecure=20(Improving=20TCP's=20=09Robustness=20to=20Bli nd=20In-Window=20Attacks)=20to=20Proposed=20Standard |Sender:=20; bh=VWu0q7St58QIrwOmwcEj40p4opHi76W0ZWaq34E59+8=; b=0KO31KJd65WLAq/J5pCy/XjzSWR3abYDFVSytxdeEueEwThE1jxzbdluzO PD3FgBc4eUoyjUGEwUW3HJ953pu3Zad3j8Tn8d0yH/wKEyBECl49GD139C1I IXDx6L2xIQ; Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: draft-ietf-tcpm-tcpsecure@tools.ietf.org Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 05:32:48 -0000 Lars, There were some comments by Sandra Murphy which we have had discussion. I had already responded to Fernando's comments and the agreed upon comments are being incorporated.=20 That said, I agree that we have been slow in getting the next revision for which I sincerely apologize, well for a change this time it is us! =20 -Anantha=20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: Thursday, May 21, 2009 8:02 PM > To: tcpm@ietf.org > Cc: draft-ietf-tcpm-tcpsecure@tools.ietf.org > Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure=20 > (Improving TCP's Robustness to Blind In-Window Attacks) to=20 > Proposed Standard >=20 > Hi, authors, >=20 > it's been over a month since the IETF last call ended, and I=20 > have not seen a document revision or even an attempt at=20 > discussing the comments you have received. Please start this=20 > discussion and eventually revise the document. >=20 > Thanks, > Lars >=20 > On 2009-4-17, at 5:11, Eggert Lars (Nokia-NRC/Espoo) wrote: >=20 > > Hi, authors, > > > > the IETF last call has ended, and it looks like the few=20 > comments I've=20 > > seen will require some text changes, so I'm placing this=20 > document in=20 > > the Revised ID Needed state. > > > > Also: Has the discussion of the comments that Fernando made=20 > concluded? > > > > Lars > > > > > > On 2009-4-2, at 18:07, The IESG wrote: > > > >> The IESG has received a request from the TCP Maintenance and Minor=20 > >> Extensions WG (tcpm) to consider the following document: > >> > >> - 'Improving TCP's Robustness to Blind In-Window Attacks ' > >> as a Proposed Standard > >> > >> The IESG plans to make a decision in the next few weeks,=20 > and solicits=20 > >> final comments on this action. Please send substantive=20 > comments to=20 > >> the ietf@ietf.org mailing lists by 2009-04-16. Exceptionally,=20 > >> comments may be sent to iesg@ietf.org instead. In either=20 > case, please=20 > >> retain the beginning of the Subject line to allow=20 > automated sorting. > >> > >> The file can be obtained via > >>=20 > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-11.txt > >> > >> > >> IESG discussion can be tracked via > >>=20 > = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dT > >> ag=3D11735&rfc_flag=3D0 > >> > >> The following IPR Declarations may be related to this I-D: > >> > >> https://datatracker.ietf.org/ipr/421/ > >> > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > > > > >=20 >=20 From fernando.gont.netbook.win@gmail.com Fri May 22 14:58:08 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4C63A6AED for ; Fri, 22 May 2009 14:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chcfa0ripkX3 for ; Fri, 22 May 2009 14:58:07 -0700 (PDT) Received: from mail-gx0-f164.google.com (mail-gx0-f164.google.com [209.85.217.164]) by core3.amsl.com (Postfix) with ESMTP id 18EF23A6971 for ; Fri, 22 May 2009 14:58:07 -0700 (PDT) Received: by gxk8 with SMTP id 8so179548gxk.13 for ; Fri, 22 May 2009 14:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=XQQCtSMSzYLh/1iR7mgYYZS4PRXP1MWrZ0dZLHXynsU=; b=W2hioqmuBXYf19GRYceS28einJtWnuCiuutK1ZL2s2wtGmxDT61zvscXTTBeb43ASb umd3bo9LS3C1xn3BINSvPeb6k69bcZ4r4gl43FUR+Ur9PTzddCBiR+3KRuikGDYnCpT0 Hay9MXx5lOg24RdCZOcpe83sF4wGqsxQOSqZ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=ebNz8INMAQKaPY7QFXrR9NpUnY0JzbXUdb9+F//8lRHIjNJtgL5dLA4qc5hTB4Qwk8 a8My93ECpCrlFe6yTqLcMs8gSZna/8JruK4DvUxvKfBGxN+h5N/TB8BAvjVqFf4m2avr UOLSD6nm5pCjbCOfsreAgLvW2kJX1wtYUZVHk= Received: by 10.151.133.11 with SMTP id k11mr8544135ybn.199.1243029582354; Fri, 22 May 2009 14:59:42 -0700 (PDT) Received: from ?192.168.0.102? (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id 9sm713742yws.10.2009.05.22.14.59.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 22 May 2009 14:59:41 -0700 (PDT) Sender: Fernando Gont Message-ID: <4A172044.2050103@gont.com.ar> Date: Fri, 22 May 2009 18:59:32 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <20090402150706.EC83D28C222@core3.amsl.com> <29AE22C3-F03F-48A8-B335-A7C8E0265406@nokia.com> <53AC2432-4B39-46FD-8414-F29EC648066C@nokia.com> <0C53DCFB700D144284A584F54711EC58074EEA6E@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58074EEA6E@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, draft-ietf-tcpm-tcpsecure@tools.ietf.org Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 21:58:08 -0000 Anantha Ramaiah (ananth) wrote: > There were some comments by Sandra Murphy which we have had > discussion. I had already responded to Fernando's comments and the > agreed upon comments are being incorporated. IIRC, there had been comments from Brian Carpenter about specific requirements for text in RFC 3979. Here's a quote from Brian's post: > Personal belief doesn't come into it. It's strictly defined in a BCP. > RFC3979 tells us the rules about this. Basically, the RFC Editor will > do what is required: > > "4. Actions for Documents for which IPR Disclosure(s) Have Been > Received > > (A) When any Intellectual Property Right is disclosed before > publication as an RFC, with respect to any technology or > specification, described in a Contribution in the manner set > forth in Section 6 of this document, the RFC Editor shall > ensure > that the document include a note indicating the existence of > such > claimed Intellectual Property Rights in any RFC published from > the Contribution. (See Section 5 below.)" > > [Section 5 defines the exact text to be included in such RFCs. > I believe you can use in xml2rfc.] I'm not sure what's the chairs' and ADs' take on this issue. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From ananth@cisco.com Fri May 22 17:36:22 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6188D3A690D for ; Fri, 22 May 2009 17:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG7YF-nNDPiB for ; Fri, 22 May 2009 17:36:15 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 931163A6A1F for ; Fri, 22 May 2009 17:36:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,235,1241395200"; d="scan'208";a="168605101" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 23 May 2009 00:37:46 +0000 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 n4N0bjs7022287; Fri, 22 May 2009 17:37:45 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n4N0bjW3015172; Sat, 23 May 2009 00:37:45 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); Fri, 22 May 2009 17:37:45 -0700 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: Fri, 22 May 2009 17:37:44 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58074EEDE0@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4A172044.2050103@gont.com.ar> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard Thread-Index: AcnbKJ4Ou4PZp3laRZeKl7Vw6ruvNAAEne0w References: <20090402150706.EC83D28C222@core3.amsl.com> <29AE22C3-F03F-48A8-B335-A7C8E0265406@nokia.com> <53AC2432-4B39-46FD-8414-F29EC648066C@nokia.com> <0C53DCFB700D144284A584F54711EC58074EEA6E@xmb-sjc-21c.amer.cisco.com> <4A172044.2050103@gont.com.ar> From: "Anantha Ramaiah (ananth)" To: "Fernando Gont" X-OriginalArrivalTime: 23 May 2009 00:37:45.0782 (UTC) FILETIME=[B0D2A560:01C9DB3E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2468; t=1243039065; x=1243903065; 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=20[tcpm]=20Last=20Call=3A=20draft-ietf-tc pm-tcpsecure=20(Improving=20TCP's=20Robustness=20to=20Blind= 20In-Window=20Attacks)=20to=20Proposed=20Standard |Sender:=20; bh=tgJ2V3czkbzlVWzZ+0rlkOcN53fH01b6T/iADbMbYkY=; b=Pz8xH1MtmP5UP9YG2Gh7pSLtK7qO5Qb1+tbNeKPivYVXsNkfEgCOi8cA5s 5/ymtlvX2pYX/nPmN0ANSMdU432gmBa52m/OH2Lz8T7XZ6wAImzfdairWnis keuW4B/LLM; Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: tcpm@ietf.org, draft-ietf-tcpm-tcpsecure@tools.ietf.org Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 00:36:22 -0000 Fernando, I will summarize all the comments which have been incorporated when I post the next revision. I have no issues trying out the suggestion by Brian. My email to Lars was = primarily to say that "there have been discussions about the comments and the next revision is work in progress" Does that clarify? -Anantha > -----Original Message----- > From: Fernando Gont=20 > [mailto:fernando.gont.netbook.win@gmail.com] On Behalf Of=20 > Fernando Gont > Sent: Friday, May 22, 2009 3:00 PM > To: Anantha Ramaiah (ananth) > Cc: Lars Eggert; tcpm@ietf.org;=20 > draft-ietf-tcpm-tcpsecure@tools.ietf.org > Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure=20 > (Improving TCP's Robustness to Blind In-Window Attacks) to=20 > Proposed Standard >=20 > Anantha Ramaiah (ananth) wrote: >=20 > > There were some comments by Sandra Murphy which we have had=20 > > discussion. I had already responded to Fernando's comments and the=20 > > agreed upon comments are being incorporated. >=20 > IIRC, there had been comments from Brian Carpenter about=20 > specific requirements for text in RFC 3979. Here's a quote=20 > from Brian's post: >=20 >=20 > > Personal belief doesn't come into it. It's strictly defined=20 > in a BCP. > > RFC3979 tells us the rules about this. Basically, the RFC=20 > Editor will=20 > > do what is required: > > > > "4. Actions for Documents for which IPR Disclosure(s) Have Been > > Received > > > > (A) When any Intellectual Property Right is disclosed before > > publication as an RFC, with respect to any technology or > > specification, described in a Contribution in the manner set > > forth in Section 6 of this document, the RFC Editor shall > > ensure > > that the document include a note indicating the existence of > > such > > claimed Intellectual Property Rights in any RFC=20 > published from > > the Contribution. (See Section 5 below.)" > > > > [Section 5 defines the exact text to be included in such RFCs. > > I believe you can use in xml2rfc.] >=20 >=20 > I'm not sure what's the chairs' and ADs' take on this issue. >=20 > Thanks! >=20 > Kind regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org PGP=20 > Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 >=20 From nishida@sfc.wide.ad.jp Sun May 24 15:09:50 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 867FD3A6D0B for ; Sun, 24 May 2009 15:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.613 X-Spam-Level: ** X-Spam-Status: No, score=2.613 tagged_above=-999 required=5 tests=[AWL=-0.891, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Lbn012xcBue for ; Sun, 24 May 2009 15:09:49 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id AD2913A6996 for ; Sun, 24 May 2009 15:09:49 -0700 (PDT) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 40AA34C05F for ; Mon, 25 May 2009 07:18:41 +0900 (JST) Date: Mon, 25 May 2009 07:11:25 +0900 (JST) Message-Id: <20090525.071125.45895741.nishida@sfc.wide.ad.jp> To: tcpm@ietf.org From: Yoshifumi Nishida In-Reply-To: References: X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2009 22:09:50 -0000 Hi, I've read the draft and I have one very minor comment about it. It seems to me that the definition of "outstading data/segments" in the document is a bit ambigious. If it simply defines "data/segments sent but not yet acknowledged", the data/segments in SACK blocks can be excluded from the definition. I prefer to have something like the following explanation in the document. outstanding data/segement is data/segments sent but not yet acknowledged with cumulative ACKs and does not include data/segments in SACK blocks. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01 Date: Wed, 13 May 2009 13:36:48 -0500 Message-ID: > TCP Maintainers & Minor Extenders: The WGLC came and went on the > Early Retransmit draft without a single comment. If it really is > perfect, then someone should speak up and say so :). > > As the chairs, we don't have a good feeling about forwarding this > draft up for publication without any discussion in the WG, so we > are proposing to hold it here until at least a handful of people > submit comments on it. > > Please review and provide WGLC feedback on this draft so that it > can make progress: > http://tools.ietf.org/html/draft-ietf-tcpm-early-rexmt-01 > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > > > >-----Original Message----- > >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > >Eddy, Wesley M. (GRC-RCN0)[Verizon] > >Sent: Tuesday, April 14, 2009 11:46 AM > >To: tcpm@ietf.org > >Cc: k.avrachenkov@sophia.inria.fr; Josh Blanton; mallman@icir.org > >Subject: [tcpm] WGLC on draft-ietf > > > >We'd like to start a 2-week TCPM working group last call on the > >early retransmit draft: > >http://tools.ietf.org/html/draft-ietf-tcpm-early-rexmt-01 > >I don't think the document itself says it, but our charter has > >this for an Experimental target. > > > >WGLC comments would be appreciated by April 30. > > > >The document has been cooking for a long time in TSVWG before > >TCPM took it, and the authors think it's pretty mature based > >on the progress on it there and in TCPM since it was taken > >up by TCPM at IETF 69. > > > >--------------------------- > >Wes Eddy > >Network & Systems Architect > >Verizon FNS / NASA GRC > >Office: (216) 433-6682 > >--------------------------- > > > >_______________________________________________ > >tcpm mailing list > >tcpm@ietf.org > >https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From fernando.gont.netbook.win@gmail.com Mon May 25 08:22:22 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9192E3A6B7C for ; Mon, 25 May 2009 08:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10e6cxnXf9SY for ; Mon, 25 May 2009 08:22:21 -0700 (PDT) Received: from mail-gx0-f164.google.com (mail-gx0-f164.google.com [209.85.217.164]) by core3.amsl.com (Postfix) with ESMTP id B27893A67F4 for ; Mon, 25 May 2009 08:22:21 -0700 (PDT) Received: by gxk8 with SMTP id 8so420323gxk.13 for ; Mon, 25 May 2009 08:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=43b8UqSqAesTQOrtp7EwJtYojRv1n1uoRDc2OprDriY=; b=A2aR9e+0dClOkWAyHbibr8KKcXCWF8JUWcZDq/ole6gvHhW4pYtXAFjmis4j7XcXuw nQkUyM2yBIZtYdc8sYmGYOvXsjM8P3v1YcqjutMO8AX9a9q21ht2M4T+O+KobSO9J3G9 N1uPNb/bdj3dZ9pIcOdu9MzfE2uXkRRMuMBQs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=MWbK/DHE1g1KcR/afRbMBBtuZeF3yeOFAUY+aJfqhIexfcX+TLXwI4Wz6ejPBuIVD9 zRu6J31NCqf5GLUg8sShWIAulACC2BSPhiCa+BymoOno/TpdnPKXp5SiiXVGMw319eEH gMFVFcvNoef9ws8uq7gCEwd1p2qGussiC/nv8= Received: by 10.100.166.10 with SMTP id o10mr12807274ane.95.1243265039943; Mon, 25 May 2009 08:23:59 -0700 (PDT) Received: from ?168.77.196.154? (154.196.lacnicxii.lacnic.net [168.77.196.154]) by mx.google.com with ESMTPS id d22sm11304079and.5.2009.05.25.08.23.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 25 May 2009 08:23:58 -0700 (PDT) Sender: Fernando Gont Message-ID: <4A1AB804.1070902@gont.com.ar> Date: Mon, 25 May 2009 12:23:48 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <20090402150706.EC83D28C222@core3.amsl.com> <29AE22C3-F03F-48A8-B335-A7C8E0265406@nokia.com> <53AC2432-4B39-46FD-8414-F29EC648066C@nokia.com> <0C53DCFB700D144284A584F54711EC58074EEA6E@xmb-sjc-21c.amer.cisco.com> <4A172044.2050103@gont.com.ar> <0C53DCFB700D144284A584F54711EC58074EEDE0@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58074EEDE0@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, draft-ietf-tcpm-tcpsecure@tools.ietf.org Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2009 15:22:22 -0000 Hello, Anantha, > I will summarize all the comments which have been incorporated when > I post the next revision. I have no issues trying out the iprnotified="yes"?> suggestion by Brian. Great! > My email to Lars was primarily > to say that "there have been discussions about the comments and the next > revision is work in progress" > Does that clarify? Sure it does. I was just wondering what had been the outcome of the e-mails discussion. We had also had a brief discussion on more technical stuff. But I'm not sure if there are any changes that will be incorporated in the next rev in response to that e-mail exchange. Maybe you could post a heads up on the upcoming changes? Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From root@core3.amsl.com Mon May 25 21:30:02 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1A2C33A6C01; Mon, 25 May 2009 21:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090526043002.1A2C33A6C01@core3.amsl.com> Date: Mon, 25 May 2009 21:30:02 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-ecnsyn-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 04:30:02 -0000 --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 Filename : draft-ietf-tcpm-ecnsyn-10.txt Pages : 35 Date : 2009-05-25 The proposal in this document is experimental. While it may be deployed in the current Internet, it does not represent a consensus that this is the best possible mechanism for the use of ECN in TCP SYN/ACK packets. This draft describes an optional, experimental modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 specifies setting an ECN-Capable codepoint on data packets, but 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 retransmission timeout, this document describes 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 the initial TCP SYN/ACK packet as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmission timeout for a connection that has not yet started placing a load on the network. The TCP responder (the sender of the SYN/ACK packet) must reply to a report of an ECN- marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN- Capable. If the resent SYN/ACK packet is acknowledged, then the TCP responder reduces its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. If instead the SYN/ACK packet is dropped, or for some other reason the TCP responder does not receive an acknowledgement in the specified time, the TCP responder follows TCP standards for a dropped SYN/ACK packet (setting the retransmission timer). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-ecnsyn-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-tcpm-ecnsyn-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-25212228.I-D@ietf.org> --NextPart-- From tim987@email.com Wed May 27 22:23:30 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3AC3A6986 for ; Wed, 27 May 2009 22:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ3cM7wTRxzY for ; Wed, 27 May 2009 22:23:30 -0700 (PDT) Received: from outbound1-1.us4.outblaze.com (outbound1-1.us4.outblaze.com [208.36.123.129]) by core3.amsl.com (Postfix) with ESMTP id 454293A68E3 for ; Wed, 27 May 2009 22:23:30 -0700 (PDT) Received: from wfilter3.us4.outblaze.com.int (wfilter3.us4.outblaze.com.int [192.168.8.242]) by outbound1-1.us4.outblaze.com (Postfix) with QMQP id 7220B7A05AD for ; Thu, 28 May 2009 05:25:13 +0000 (GMT) X-OB-Received: from unknown (205.158.62.50) by wfilter3.us4.outblaze.com; 28 May 2009 05:25:13 -0000 Received: by ws1-4.us4.outblaze.com (Postfix, from userid 1001) id 1B1D0606884; Thu, 28 May 2009 05:25:14 +0000 (GMT) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_124348831437170" MIME-Version: 1.0 From: "tim robertson" To: tcpm@ietf.org Date: Thu, 28 May 2009 00:25:14 -0500 Importance: high X-Priority: 1 Received: from [222.152.65.178] by ws1-4.us4.outblaze.com with http for tim987@email.com; Thu, 28 May 2009 00:25:14 -0500 X-Originating-Ip: 222.152.65.178 X-Originating-Server: ws1-4.us4.outblaze.com X-Ob-Auth: tim987:email.com@mail.com Message-Id: <20090528052514.1B1D0606884@ws1-4.us4.outblaze.com> X-Mailman-Approved-At: Thu, 28 May 2009 08:01:13 -0700 Subject: [tcpm] Suggestion for TCP Maintenance and Minor Extensions (tcpm) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 05:23:31 -0000 This is a multi-part message in MIME format. --_----------=_124348831437170 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi, I have=A0a suggestion for TCP Maintenance and Minor Extensions (tcpm). You should make TCP censorship free. By that I mean isp's shouldn't be able to block websites by using blacklists, url blocking, ip address block, dns, keyword block etc. For example, in China, some perfectly legal websites like wikipedia are blocked, so that is why TCP should be changed so isp's cannot block websites. So you may have to work with operating system makers and router makers to update their software, but it should be backwards compatible too.=A0Can you pass on my suggestion?Than= ks --=20 Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com --_----------=_124348831437170 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"
Hi, I have a suggestion for TCP Maintenance and Minor Extensions = (tcpm). You should make TCP censorship free. By that I mean isp's shouldn't= be able to block websites by using blacklists, url blocking, ip address bl= ock, dns, keyword block etc. For example, in China, some perfectly legal we= bsites like wikipedia are blocked, so that is why TCP should be changed so = isp's cannot block websites. So you may have to work with operating system = makers and router makers to update their software, but it should be backwar= ds compatible too.
 
Can you pass on my suggestion?
Thanks

--=20
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com!
--_----------=_124348831437170-- From touch@ISI.EDU Thu May 28 08:26:48 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB9CB3A6B3C for ; Thu, 28 May 2009 08:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEfnIfvNKczB for ; Thu, 28 May 2009 08:26:48 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id F16863A6885 for ; Thu, 28 May 2009 08:26:47 -0700 (PDT) Received: from [192.168.1.46] (pool-71-106-86-44.lsanca.dsl-w.verizon.net [71.106.86.44]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n4SFRTTJ001400; Thu, 28 May 2009 08:27:30 -0700 (PDT) Message-ID: <4A1EAD60.3060006@isi.edu> Date: Thu, 28 May 2009 08:27:28 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: tim robertson References: <20090528052514.1B1D0606884@ws1-4.us4.outblaze.com> In-Reply-To: <20090528052514.1B1D0606884@ws1-4.us4.outblaze.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Suggestion for TCP Maintenance and Minor Extensions (tcpm) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 15:26:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Tim, tim robertson wrote: > Hi, I have a suggestion for TCP Maintenance and Minor Extensions (tcpm). > You should make TCP censorship free. By that I mean isp's shouldn't be > able to block websites by using blacklists, url blocking, ip address > block, dns, keyword block etc. If what you're asking for is to have us design a TCP that can't be easily blocked, then yes, that might happen here. Note that this would require a way to specify the service that, e.g., a popular web server could decipher (e.g., wikipedia, etc.), but that an intermediate could not. The intermediate could always block anything it can't decipher, and you're back where you are now, though. However, if you're asking us to regulate what ISPs do, that doesn't happen in the IETF. We don't regulate, do compliance verification, or otherwise endorse implementations. It might be useful to clarify what you are seeking... Joe (PS to the WG - I was surprised that there doesn't appear to be a direct statement of the second point above in the Tao of the IETF. Anyone have a better reference?) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoerWAACgkQE5f5cImnZrv/hACffD1ZOaw1Kp7W7W256ppnUSMk /oMAoIyTXGXHvHluswxVvmycZdkFchu+ =Z/NN -----END PGP SIGNATURE----- From ananth@cisco.com Sun May 31 23:30:06 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B14EF3A6971; Sun, 31 May 2009 23:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaBy5K4PfsPw; Sun, 31 May 2009 23:30:05 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 31FF23A68AD; Sun, 31 May 2009 23:30:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,283,1241395200"; d="scan'208";a="192621668" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 01 Jun 2009 06:30:05 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n516U5Nu030082; Sun, 31 May 2009 23:30:05 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n516U52a008941; Mon, 1 Jun 2009 06:30:05 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); Sun, 31 May 2009 23:30:05 -0700 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: Sun, 31 May 2009 23:30:04 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58075644AF@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard thread-index: Acm/G2g/G5uE5R9NR0iDL9KmjNDIAQjYO0rQ References: <20090402150706.EC83D28C222@core3.amsl.com> <49E3ADA4.1090402@gont.com.ar> <0C53DCFB700D144284A584F54711EC58070763E3@xmb-sjc-21c.amer.cisco.com> From: "Anantha Ramaiah (ananth)" To: "Fernando Gont" X-OriginalArrivalTime: 01 Jun 2009 06:30:05.0107 (UTC) FILETIME=[668F6830:01C9E282] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8333; t=1243837805; x=1244701805; 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]=20Last=20Call=3A=20draft-ietf-tc pm-tcpsecure=20(Improving=20TCP's=20Robustness=20to=20Blind= 20In-Window=20Attacks)=20to=20Proposed=20Standard |Sender:=20; bh=vA8jgp44hyslHg1Sv1U60p4jZbcihGH16Fe65L/KQ4I=; b=fO6Rc+HNLbRqea853Hwir/5mfZ5Ue92QuK7QKNVCAfj/1+1jKdDb1MtLNJ gAxt2UO8bQQtVLYwO8Af6ugQ79BxSqguSxZLhKNqCxxA+kqdWyQfhsdUJU++ B82/tpz8A6; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: tcpm@ietf.org, ietf@ietf.org Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 06:30:06 -0000 Fernando, I was modifying the document to update the last call comments and I would want to make sure if we are on same page w.r.t to your comments. Pl see inline.=20 > -----Original Message----- > From: fernando.gont.netbook.win@gmail.com=20 > [mailto:fernando.gont.netbook.win@gmail.com] On Behalf Of=20 > Fernando Gont > Sent: Thursday, April 16, 2009 10:15 PM > To: Anantha Ramaiah (ananth) > Cc: ietf@ietf.org; tcpm@ietf.org > Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure=20 > (Improving TCP's Robustness to Blind In-Window Attacks) to=20 > Proposed Standard >=20 > On Mon, Apr 13, 2009 at 10:23 PM, Anantha Ramaiah (ananth)=20 > wrote: >=20 > > > * The document never mentions the fact that this document is=20 > > > IPR-encumbered. As far as I recall, much of the dicussion within=20 > > > tcpm with respect to the level of requirements of this document=20 > > > (MAY/SHOULD/MUST, etc.) had to do with this fact. I believe the=20 > > > document should include a warning mentioning that there's=20 > an IPR on=20 > > > the document, so that implementers can consider this=20 > point in their=20 > > > decision of whether to implement the described mechanisms or not. > > > > I am confused what to do since this is being brought up=20 > very late in=20 > > the game. That said, there are *many* drafts/RFC's that have IPR on=20 > > them in the whole of ietf. Do all them explicitly state the=20 > IPR link ?=20 > > I'll leave it to the collective wisdom of the group and the=20 > chairs to=20 > > offer guidance on this matter. >=20 > I personally believe this should be noted in all RFCs on=20 > which there's a known IPR. However, Joel Halpern mentioned=20 > this is not current practice. If that's the case, I'd have no=20 > problem with leaving it "as is". (FWIW, if you look at our=20 > tcp-security document, we do recommend the implementation of=20 > the counter-measures you propose, but just note that there's=20 > an IPR, and that implementers should research how this would=20 > affect them). I think we seem to have concluded this. As per Brian Carpenter's suggestion I have done an iprnotified =3D yes in my xml2rfc. I hope that should take care of this. >=20 > > Now the scope of this document is to improve robustness to=20 > TCP esp. in=20 > > cases where the TCP connection is not protected by other means like=20 > > TCP MD5 or TCP AO etc., Now this point is very clear in the=20 > document.=20 > > That said I have no issues putting a reference to the port=20 > > randomization in the document. >=20 > What I mean is that anybody that cares about this stuff=20 > (FWIW, I do) would also implement port randmization, ISN=20 > randomization, etc. One might argue that there's no use in It depends on how you view this document. To me, this document is about improving TCP's robustness on some type of scenarios. It is not intended to be a plethora of all possible TCP attacks and mitigations. =20 >=20 > > > and other quite a few times in the tcpm wg list, pre and=20 > post wglc,=20 > > > but this comment was never addressed. It's particularly=20 > curious that=20 > > > port randomization is not mentioned when tsvwg is working on it=20 > > > (draft-ietf-tsvwg-port-randomization). > > > > Yes, you did raise this issue last time, but I did defer it=20 > to the WG=20 > > and did not receive any response, so I simply left it at that. >=20 > IIRC, both Joe and me had agreed on this one (yeah, we did :-) ). Like I said earlier, I have no issues putting a reference to port randomization document. Can you suggest a right place for this? >=20 >=20 >=20 > > > * Among the factors that determine how easy these attacks be=20 > > > exploited is the window size. This document should=20 > provide, at the=20 > > > very least, pointers with advice on what to do with the=20 > tcp window.=20 > > > While quickly skimming through RFC 4953, it > > > > It does mentions about the window size relationship, For example in=20 > > the beginning sections of the document we briefly mention=20 > the window=20 > > size and the # of packets that is required to generate a=20 > successful attack. >=20 > What I mean is: you should not use windows that are larger=20 > than necessary. Using larger windows than necessary doesn't=20 > come for free (e.g., it increases the chances of an attacker=20 > of successfully performing these attacks). Provide advice on window sizes is deemed beyond the scope of this document, IMO. >=20 >=20 > > > * Yet another factor is TCP ISN randomization. At the very least,=20 > > > this document could/should a pointer to RFC 1948. We do offer a=20 > > > lengthy discussion of this and other issues in=20 > > > draft-gont-tcp-security and=20 > > > http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf > > > > Why should it talk about ISN randomization since ISN=20 > randomization, is=20 > > somewhat orthogonal to the type of attack here, it is not=20 > even one of=20 > > the attack vector. >=20 > If I can predict the ISN, I don't have to guess it.=20 > Therefore, it's easier to successfully perform the attack. Well, predicting ISN helps, but it really depends on how much volume of data that got exchanged and the current sliding window snapshot (snduna -- sndnxt) which really determines the acceptability of a segment. >=20 >=20 >=20 > > > * The counter-measure of for the SYN-based reset attack may have=20 > > > missed a common heuristics for the handling of SYN segments. See=20 > > > pages 86 and > > > 87 of the UK CPNI paper on TCP security. FWIW, we argue that the=20 > > > processing of SYN segments proposed in [Ramaiah et al,=20 > 2008] should=20 > > > apply only for connections in any of the synchronized=20 > states other=20 > > > than the TIME-WAIT state. > > > > We just followed RFC 793 as the base and the changes are made w.r.t=20 > > that. TIME-WAIT may be an exception but doesn't RFC 793 already has=20 > > that language correct? >=20 > Well, the timestamps was published *after* RFC 793. So RFC=20 > imsply doesn't address this, because timestamps didn't exist=20 > at the time. Why are you bringing in timestamps, the huerisitic suggested by RFC 1122 applies *without* timestamps in place. Just to be clear : The current mitigation *does* not preclude any host to have the TIME-WAIT hueristic suggested as a MAY condition in RFC 1122. The scope of the document is to only change the language w.r.t 793. That said, I'll leave it to the collective wisdom of the WG to comment on this, if there is a strong consensus I don't issues to add some text. >=20 >=20 >=20 > > > * When it comes to TCP-based blind-connection reset=20 > attacks, there's=20 > > > a much more trivial -- yet not discussed before? --=20 > alternative. See=20 > > > Section 11.1.3 and Section 11.1.4 in=20 > draft-gont-tcp-security and the=20 > > > CPNI paper=20 > > >=20 > (http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf). > > > These variants should, at the very least, be mentioned=20 > and a pointer=20 > > > provided to them as, at least in theory, are much easier=20 > to exploit. > > > > Those sounds like some new proposals (security and precedence)=20 > > different stacks would have taken different measures to=20 > address this issue. > > Anyways this is something new and hence needs more discussion and=20 > > evaluation. Has these ideas been submitted in a draft to=20 > TCPM? (your=20 > > recent BCP document tcp-security, covers it ?) >=20 > Yes, the tcp-security I-D covers it. This stuff came as a=20 > surprise while assessing RFC 793. One would expect that these=20 > attacks don't work in practice--- but you never know.=20 > However, IETF-wise they do... > therefore I think it should be mentioned as another potential=20 > connection-reset attack vector (*much* easier, as you don't=20 > even have to guess the sequence number) Like I said this document has been only taking about the 3 attacks from the beginning when this document was out (5 years), I see no point in delaying this document any further by adding new attacks without the consensus of the WG. Thanks, -Anantha=20