From rs@netapp.com Wed Jul 6 08:58:55 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C75521F85A2 for ; Wed, 6 Jul 2011 08:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dZ8ZIq4m+NT for ; Wed, 6 Jul 2011 08:58:50 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8C17621F85A0 for ; Wed, 6 Jul 2011 08:58:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,487,1304319600"; d="scan'208";a="253582134" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 06 Jul 2011 08:58:49 -0700 Received: from amsrsexc1-prd.hq.netapp.com (amsrsexc1-prd.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p66FwmXt000311; Wed, 6 Jul 2011 08:58:48 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jul 2011 17:58:48 +0200 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: Wed, 6 Jul 2011 16:58:27 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0F1E3100@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <4DE6A6D8.20908@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] feedback from group to draft-scheffenegger-tcpm-timestamp-negotiation-02.txt Thread-Index: AcwgnguAzAZQQA/bSkST02VxiUcF2AbUQOvQ References: <5FDC413D5FA246468C200652D63E627A0E99C04B@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0E99C04C@LDCMVEXC1-PRD.hq.netapp.com> <4DE51EC0.7070302@isi.edu> <5FDC413D5FA246468C200652D63E627A0E99CD4C@LDCMVEXC1-PRD.hq.netapp.com> <4DE57E52.5030501@isi.edu> <5FDC413D5FA246468C200652D63E627A0EAA9115@LDCMVEXC1-PRD.hq.netapp.com> <4DE666DB.3010109@isi.edu> <5FDC413D5FA246468C200652D63E627A0EAA9444@LDCMVEXC1-PRD.hq.netapp.com> <4DE6A6D8.20908@isi.edu> From: "Scheffenegger, Richard" To: "Joe Touch" X-OriginalArrivalTime: 06 Jul 2011 15:58:48.0672 (UTC) FILETIME=[97CCF600:01CC3BF5] Cc: tcpm@ietf.org Subject: Re: [tcpm] feedback from group to draft-scheffenegger-tcpm-timestamp-negotiation-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2011 15:58:55 -0000 Hi Joe, group, it took me a while to get hold of a good volume of trace data (Using the Waikato set, Jan-Aug 2005), to investigate the prevalence and type of misbehavior around TCP timestamps in [SYN]. (Unfortunately, I don't have access to more recent CAIDA data sets :( ). The data I evaluated totals to slightly over 1 billion [SYN]. 45% of these [SYN]s carried the Timestamp option. 8*10^-6 of these SYNs were sent with TSecr not zero (this includes duplicate/retransmitted [SYN]s; approximately 45% of such [SYN]s are retransmissions/duplicated - a much higher fraction, than in the normal population of [SYN]s I'm currently verifying if these TSecr!=3D0 events were all preceded by = a TCP session, where the sender got to know a timestamp from the receiver. Nevertheless, the distribution of the TSecr timestamp values is quite skewed towards lower values of the timestamps: 3 MSB bits; number of unique [SYNs] 000 1311 001 341 010 136 011 51 100 55 101 36 110 26 111 20 Based on the current proposal, only the last 3 bins could inadvertently trigger the changed timestamp handling on the receiver side (82 out of 1947 - 4.2%), but 6 hosts don't negotiate also for SACK (76/1947 =3D 3.9%). The hosts in the "100" bin could potentially negotiate successfully for both the changed timestamp handling (again, 6 Hosts don't negotiate for SACK), and signal some timestamp clock rate. However, using the REServed bits (2nd octet), which must be zero according to the draft, none of these sessions would have successfully negotiated for timestamp capabilities. At a high bound, this leaves some 150 sessions out of 1 billion sessions (1.5*10^-7) to inadvertently have timestamp signaling changed (with a heavy skew towards getting immediate TS echos, instead of the algorithm in RFC1323; with legacy hosts, this may lead to an increase in spurious retransmits - and thereby TCP throughput reductions).=20 The upper bound to erroneously negotiate timestamp capabilities, and also coax the receiver into enabling advances heuristics seems to be around 10^-10 of all sessions. Again, this is based on trace data from 2005, and addresses issues with misbehaving TCP senders, that have broken timestamp implementations. It's likely, that these fractions reduced over the last 6 years, as these misbehaving implementations got fixed over time. I would like to hear from the group, if this rate of false positives is at an acceptable level, or if further mitigations beyond what is in the draft are required. (Or if I need to try to get hold of more recent data).=20 Richard Scheffenegger > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Mittwoch, 01. Juni 2011 22:54 > To: Scheffenegger, Richard > Cc: tcpm@ietf.org > Subject: Re: [tcpm] feedback from group to draft-scheffenegger-tcpm- > timestamp-negotiation-02.txt >=20 >=20 >=20 > On 6/1/2011 1:02 PM, Scheffenegger, Richard wrote: > > > > Hi Joe, > > > > I am sorry, but you lost me... > > > > I fully agree, the PRNG assumption may not hold. But I don't quite > > follow where you set a fixed date (or was your choice of the signed > unix > > epoch rollover random?)... >=20 > I picked dates that had the bits set as you indicated ;-) >=20 From touch@isi.edu Wed Jul 6 09:09:57 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C2D21F87A8 for ; Wed, 6 Jul 2011 09:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.05 X-Spam-Level: X-Spam-Status: No, score=-103.05 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kd6bu4JpNcrp for ; Wed, 6 Jul 2011 09:09:56 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4B58821F87A6 for ; Wed, 6 Jul 2011 09:09:56 -0700 (PDT) Received: from [192.168.1.87] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p66G9AIV013180 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 6 Jul 2011 09:09:20 -0700 (PDT) Message-ID: <4E1488A6.1040809@isi.edu> Date: Wed, 06 Jul 2011 09:09:10 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <5FDC413D5FA246468C200652D63E627A0E99C04B@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0E99C04C@LDCMVEXC1-PRD.hq.netapp.com> <4DE51EC0.7070302@isi.edu> <5FDC413D5FA246468C200652D63E627A0E99CD4C@LDCMVEXC1-PRD.hq.netapp.com> <4DE57E52.5030501@isi.edu> <5FDC413D5FA246468C200652D63E627A0EAA9115@LDCMVEXC1-PRD.hq.netapp.com> <4DE666DB.3010109@isi.edu> <5FDC413D5FA246468C200652D63E627A0EAA9444@LDCMVEXC1-PRD.hq.netapp.com> <4DE6A6D8.20908@isi.edu> <5FDC413D5FA246468C200652D63E627A0F1E3100@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0F1E3100@LDCMVEXC1-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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] feedback from group to draft-scheffenegger-tcpm-timestamp-negotiation-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2011 16:09:58 -0000 Hi, Richard, Well, IMO, the whole point behind TCP is that it works. It never works optimally, but if it *can* work it *does* work. Anything with *any* false positives, excepting those traced to implementation bugs, is unacceptable to me. TCP connections should *never* have to "try again" due to such a protocol error. Others can weigh their views. Joe On 7/6/2011 8:58 AM, Scheffenegger, Richard wrote: > Hi Joe, group, > > it took me a while to get hold of a good volume of trace data (Using the > Waikato set, Jan-Aug 2005), to investigate the prevalence and type of > misbehavior around TCP timestamps in [SYN]. > > (Unfortunately, I don't have access to more recent CAIDA data sets :( ). > > > > The data I evaluated totals to slightly over 1 billion [SYN]. > > 45% of these [SYN]s carried the Timestamp option. > 8*10^-6 of these SYNs were sent with TSecr not zero (this includes > duplicate/retransmitted [SYN]s; approximately 45% of such [SYN]s are > retransmissions/duplicated - a much higher fraction, than in the normal > population of [SYN]s > > I'm currently verifying if these TSecr!=0 events were all preceded by a > TCP session, where the sender got to know a timestamp from the receiver. > > Nevertheless, the distribution of the TSecr timestamp values is quite > skewed towards lower values of the timestamps: > > 3 MSB bits; number of unique [SYNs] > 000 1311 > 001 341 > 010 136 > 011 51 > 100 55 > 101 36 > 110 26 > 111 20 > > Based on the current proposal, only the last 3 bins could inadvertently > trigger the changed timestamp handling on the receiver side (82 out of > 1947 - 4.2%), but 6 hosts don't negotiate also for SACK (76/1947 = > 3.9%). > > The hosts in the "100" bin could potentially negotiate successfully for > both the changed timestamp handling (again, 6 Hosts don't negotiate for > SACK), and signal some timestamp clock rate. However, using the REServed > bits (2nd octet), which must be zero according to the draft, none of > these sessions would have successfully negotiated for timestamp > capabilities. > > At a high bound, this leaves some 150 sessions out of 1 billion sessions > (1.5*10^-7) to inadvertently have timestamp signaling changed (with a > heavy skew towards getting immediate TS echos, instead of the algorithm > in RFC1323; with legacy hosts, this may lead to an increase in spurious > retransmits - and thereby TCP throughput reductions). > > The upper bound to erroneously negotiate timestamp capabilities, and > also coax the receiver into enabling advances heuristics seems to be > around 10^-10 of all sessions. > > Again, this is based on trace data from 2005, and addresses issues with > misbehaving TCP senders, that have broken timestamp implementations. > It's likely, that these fractions reduced over the last 6 years, as > these misbehaving implementations got fixed over time. > > > I would like to hear from the group, if this rate of false positives is > at an acceptable level, or if further mitigations beyond what is in the > draft are required. (Or if I need to try to get hold of more recent > data). > > > Richard Scheffenegger > > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Mittwoch, 01. Juni 2011 22:54 >> To: Scheffenegger, Richard >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] feedback from group to draft-scheffenegger-tcpm- >> timestamp-negotiation-02.txt >> >> >> >> On 6/1/2011 1:02 PM, Scheffenegger, Richard wrote: >>> >>> Hi Joe, >>> >>> I am sorry, but you lost me... >>> >>> I fully agree, the PRNG assumption may not hold. But I don't quite >>> follow where you set a fixed date (or was your choice of the signed >> unix >>> epoch rollover random?)... >> >> I picked dates that had the bits set as you indicated ;-) >> > From rs@netapp.com Wed Jul 6 09:28:21 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F0C21F86C7 for ; Wed, 6 Jul 2011 09:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tPuYH68AVBB for ; Wed, 6 Jul 2011 09:28:20 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3E31421F84DA for ; Wed, 6 Jul 2011 09:28:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,487,1304319600"; d="scan'208";a="262612913" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 06 Jul 2011 09:28:19 -0700 Received: from ldcrsexc2-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p66GSHqQ004767; Wed, 6 Jul 2011 09:28:19 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jul 2011 17:28:15 +0100 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: Wed, 6 Jul 2011 17:27:54 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0F1E3124@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <4E1488A6.1040809@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] feedback from group to draft-scheffenegger-tcpm-timestamp-negotiation-02.txt Thread-Index: Acw79yc/P0yiQBveQi2A/IdWAHoGIQAAGfuA References: <5FDC413D5FA246468C200652D63E627A0E99C04B@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0E99C04C@LDCMVEXC1-PRD.hq.netapp.com> <4DE51EC0.7070302@isi.edu> <5FDC413D5FA246468C200652D63E627A0E99CD4C@LDCMVEXC1-PRD.hq.netapp.com> <4DE57E52.5030501@isi.edu> <5FDC413D5FA246468C200652D63E627A0EAA9115@LDCMVEXC1-PRD.hq.netapp.com> <4DE666DB.3010109@isi.edu> <5FDC413D5FA246468C200652D63E627A0EAA9444@LDCMVEXC1-PRD.hq.netapp.com> <4DE6A6D8.20908@isi.edu> <5FDC413D5FA246468C200652D63E627A0F1E3100@LDCMVEXC1-PRD.hq.netapp.com> <4E1488A6.1040809@isi.edu> From: "Scheffenegger, Richard" To: "Joe Touch" X-OriginalArrivalTime: 06 Jul 2011 16:28:15.0439 (UTC) FILETIME=[B4E035F0:01CC3BF9] Cc: tcpm@ietf.org Subject: Re: [tcpm] feedback from group to draft-scheffenegger-tcpm-timestamp-negotiation-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2011 16:28:21 -0000 Thanks Joe, as all these TSecr!=3D0 are due to faulty implementation (RFC1323 stipulates that a [SYN] has to have TSecr=3D0), I take your comment that the expected false positive rate of 1.5*10^-7 for immediate TS echos / 10^-10 for wrong enhanced receiver side heuristics (putting these broken implementations at a further disadvantage) is acceptable.=20 The outcome of false positives, at the simplest, will be a higher level of spurious retransmits for those sessions. Also standard TCP CC reaction and loss recovery instead of enhanced (optimized) reactions (TCP Chirp; lost retransmission detection...).=20 Thus these broken implementations are disadvantaged w.r.t. legacy RFC1323 implementations, while new implementations can benefit from improved TCP CC reaction and improved loss recovery... Richard Scheffenegger > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Mittwoch, 06. Juli 2011 18:09 > To: Scheffenegger, Richard > Cc: tcpm@ietf.org > Subject: Re: [tcpm] feedback from group to draft-scheffenegger-tcpm- > timestamp-negotiation-02.txt >=20 > Hi, Richard, >=20 > Well, IMO, the whole point behind TCP is that it works. It never works > optimally, but if it *can* work it *does* work. >=20 > Anything with *any* false positives, excepting those traced to > implementation bugs, is unacceptable to me. >=20 > TCP connections should *never* have to "try again" due to such a > protocol error. >=20 > Others can weigh their views. >=20 > Joe >=20 > On 7/6/2011 8:58 AM, Scheffenegger, Richard wrote: > > Hi Joe, group, > > > > it took me a while to get hold of a good volume of trace data (Using > the > > Waikato set, Jan-Aug 2005), to investigate the prevalence and type of > > misbehavior around TCP timestamps in [SYN]. > > > > (Unfortunately, I don't have access to more recent CAIDA data sets :( > ). > > > > > > > > The data I evaluated totals to slightly over 1 billion [SYN]. > > > > 45% of these [SYN]s carried the Timestamp option. > > 8*10^-6 of these SYNs were sent with TSecr not zero (this includes > > duplicate/retransmitted [SYN]s; approximately 45% of such [SYN]s are > > retransmissions/duplicated - a much higher fraction, than in the > normal > > population of [SYN]s > > > > I'm currently verifying if these TSecr!=3D0 events were all preceded by > a > > TCP session, where the sender got to know a timestamp from the > receiver. > > > > Nevertheless, the distribution of the TSecr timestamp values is quite > > skewed towards lower values of the timestamps: > > > > 3 MSB bits; number of unique [SYNs] > > 000 1311 > > 001 341 > > 010 136 > > 011 51 > > 100 55 > > 101 36 > > 110 26 > > 111 20 > > > > Based on the current proposal, only the last 3 bins could > inadvertently > > trigger the changed timestamp handling on the receiver side (82 out > of > > 1947 - 4.2%), but 6 hosts don't negotiate also for SACK (76/1947 =3D > > 3.9%). > > > > The hosts in the "100" bin could potentially negotiate successfully > for > > both the changed timestamp handling (again, 6 Hosts don't negotiate > for > > SACK), and signal some timestamp clock rate. However, using the > REServed > > bits (2nd octet), which must be zero according to the draft, none of > > these sessions would have successfully negotiated for timestamp > > capabilities. > > > > At a high bound, this leaves some 150 sessions out of 1 billion > sessions > > (1.5*10^-7) to inadvertently have timestamp signaling changed (with a > > heavy skew towards getting immediate TS echos, instead of the > algorithm > > in RFC1323; with legacy hosts, this may lead to an increase in > spurious > > retransmits - and thereby TCP throughput reductions). > > > > The upper bound to erroneously negotiate timestamp capabilities, and > > also coax the receiver into enabling advances heuristics seems to be > > around 10^-10 of all sessions. > > > > Again, this is based on trace data from 2005, and addresses issues > with > > misbehaving TCP senders, that have broken timestamp implementations. > > It's likely, that these fractions reduced over the last 6 years, as > > these misbehaving implementations got fixed over time. > > > > > > I would like to hear from the group, if this rate of false positives > is > > at an acceptable level, or if further mitigations beyond what is in > the > > draft are required. (Or if I need to try to get hold of more recent > > data). > > > > > > Richard Scheffenegger > > > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@isi.edu] > >> Sent: Mittwoch, 01. Juni 2011 22:54 > >> To: Scheffenegger, Richard > >> Cc: tcpm@ietf.org > >> Subject: Re: [tcpm] feedback from group to draft-scheffenegger-tcpm- > >> timestamp-negotiation-02.txt > >> > >> > >> > >> On 6/1/2011 1:02 PM, Scheffenegger, Richard wrote: > >>> > >>> Hi Joe, > >>> > >>> I am sorry, but you lost me... > >>> > >>> I fully agree, the PRNG assumption may not hold. But I don't quite > >>> follow where you set a fixed date (or was your choice of the signed > >> unix > >>> epoch rollover random?)... > >> > >> I picked dates that had the bits set as you indicated ;-) > >> > > From touch@isi.edu Wed Jul 6 10:09:29 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEFC21F87A6 for ; Wed, 6 Jul 2011 10:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.449 X-Spam-Level: X-Spam-Status: No, score=-105.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylT0RX2Rdfx2 for ; Wed, 6 Jul 2011 10:09:28 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 480A521F866B for ; Wed, 6 Jul 2011 10:09:28 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p66H8sT3005404 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 6 Jul 2011 10:08:54 -0700 (PDT) Message-ID: <4E1496A5.3090401@isi.edu> Date: Wed, 06 Jul 2011 10:08:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <5FDC413D5FA246468C200652D63E627A0E99C04B@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0E99C04C@LDCMVEXC1-PRD.hq.netapp.com> <4DE51EC0.7070302@isi.edu> <5FDC413D5FA246468C200652D63E627A0E99CD4C@LDCMVEXC1-PRD.hq.netapp.com> <4DE57E52.5030501@isi.edu> <5FDC413D5FA246468C200652D63E627A0EAA9115@LDCMVEXC1-PRD.hq.netapp.com> <4DE666DB.3010109@isi.edu> <5FDC413D5FA246468C200652D63E627A0EAA9444@LDCMVEXC1-PRD.hq.netapp.com> <4DE6A6D8.20908@isi.edu> <5FDC413D5FA246468C200652D63E627A0F1E3100@LDCMVEXC1-PRD.hq.netapp.com> <4E1488A6.1040809@isi.edu> <5FDC413D5FA246468C200652D63E627A0F1E3124@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0F1E3124@LDCMVEXC1-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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] feedback from group to draft-scheffenegger-tcpm-timestamp-negotiation-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2011 17:09:29 -0000 On 7/6/2011 9:27 AM, Scheffenegger, Richard wrote: > > Thanks Joe, > > as all these TSecr!=0 are due to faulty implementation (RFC1323 > stipulates that a [SYN] has to have TSecr=0), I take your comment that > the expected false positive rate of 1.5*10^-7 for immediate TS echos / > 10^-10 for wrong enhanced receiver side heuristics (putting these broken > implementations at a further disadvantage) is acceptable. > > The outcome of false positives, at the simplest, will be a higher level > of spurious retransmits for those sessions. Also standard TCP CC > reaction and loss recovery instead of enhanced (optimized) reactions > (TCP Chirp; lost retransmission detection...). The part that bothers me is that the retransmits had a much higher (nearly 50%) repeat rate of errors, so your logic doesn't hold. I.e., this takes a broken implementation that had no impact and makes it break a connection. It'd be useful to track that down to *confirm* that it's a broken implementation, and what OS/version it tracks to. > Thus these broken implementations are disadvantaged w.r.t. legacy > RFC1323 implementations, while new implementations can benefit from > improved TCP CC reaction and improved loss recovery... The concern right now is that 'broken' used to mean either silently working or at worst slightly slower, and you're breaking it harder. Although 1323 says MUST, 'be generous in what you receive' means generally ignoring errors in that field, since it wasn't spec'd for other uses. I.e., making TCP more brittle at the expense of a performance win is a bad thing, IMO. If these errors can be tracked and confirmed as a bug (and hopefully a patch issued), then that's another story... Joe >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Mittwoch, 06. Juli 2011 18:09 >> To: Scheffenegger, Richard >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] feedback from group to draft-scheffenegger-tcpm- >> timestamp-negotiation-02.txt >> >> Hi, Richard, >> >> Well, IMO, the whole point behind TCP is that it works. It never works >> optimally, but if it *can* work it *does* work. >> >> Anything with *any* false positives, excepting those traced to >> implementation bugs, is unacceptable to me. >> >> TCP connections should *never* have to "try again" due to such a >> protocol error. >> >> Others can weigh their views. >> >> Joe >> >> On 7/6/2011 8:58 AM, Scheffenegger, Richard wrote: >>> Hi Joe, group, >>> >>> it took me a while to get hold of a good volume of trace data (Using >> the >>> Waikato set, Jan-Aug 2005), to investigate the prevalence and type > of >>> misbehavior around TCP timestamps in [SYN]. >>> >>> (Unfortunately, I don't have access to more recent CAIDA data sets > :( >> ). >>> >>> >>> >>> The data I evaluated totals to slightly over 1 billion [SYN]. >>> >>> 45% of these [SYN]s carried the Timestamp option. >>> 8*10^-6 of these SYNs were sent with TSecr not zero (this includes >>> duplicate/retransmitted [SYN]s; approximately 45% of such [SYN]s are >>> retransmissions/duplicated - a much higher fraction, than in the >> normal >>> population of [SYN]s >>> >>> I'm currently verifying if these TSecr!=0 events were all preceded > by >> a >>> TCP session, where the sender got to know a timestamp from the >> receiver. >>> >>> Nevertheless, the distribution of the TSecr timestamp values is > quite >>> skewed towards lower values of the timestamps: >>> >>> 3 MSB bits; number of unique [SYNs] >>> 000 1311 >>> 001 341 >>> 010 136 >>> 011 51 >>> 100 55 >>> 101 36 >>> 110 26 >>> 111 20 >>> >>> Based on the current proposal, only the last 3 bins could >> inadvertently >>> trigger the changed timestamp handling on the receiver side (82 out >> of >>> 1947 - 4.2%), but 6 hosts don't negotiate also for SACK (76/1947 = >>> 3.9%). >>> >>> The hosts in the "100" bin could potentially negotiate successfully >> for >>> both the changed timestamp handling (again, 6 Hosts don't negotiate >> for >>> SACK), and signal some timestamp clock rate. However, using the >> REServed >>> bits (2nd octet), which must be zero according to the draft, none of >>> these sessions would have successfully negotiated for timestamp >>> capabilities. >>> >>> At a high bound, this leaves some 150 sessions out of 1 billion >> sessions >>> (1.5*10^-7) to inadvertently have timestamp signaling changed (with > a >>> heavy skew towards getting immediate TS echos, instead of the >> algorithm >>> in RFC1323; with legacy hosts, this may lead to an increase in >> spurious >>> retransmits - and thereby TCP throughput reductions). >>> >>> The upper bound to erroneously negotiate timestamp capabilities, and >>> also coax the receiver into enabling advances heuristics seems to be >>> around 10^-10 of all sessions. >>> >>> Again, this is based on trace data from 2005, and addresses issues >> with >>> misbehaving TCP senders, that have broken timestamp implementations. >>> It's likely, that these fractions reduced over the last 6 years, as >>> these misbehaving implementations got fixed over time. >>> >>> >>> I would like to hear from the group, if this rate of false positives >> is >>> at an acceptable level, or if further mitigations beyond what is in >> the >>> draft are required. (Or if I need to try to get hold of more recent >>> data). >>> >>> >>> Richard Scheffenegger >>> >>> >>>> -----Original Message----- >>>> From: Joe Touch [mailto:touch@isi.edu] >>>> Sent: Mittwoch, 01. Juni 2011 22:54 >>>> To: Scheffenegger, Richard >>>> Cc: tcpm@ietf.org >>>> Subject: Re: [tcpm] feedback from group to > draft-scheffenegger-tcpm- >>>> timestamp-negotiation-02.txt >>>> >>>> >>>> >>>> On 6/1/2011 1:02 PM, Scheffenegger, Richard wrote: >>>>> >>>>> Hi Joe, >>>>> >>>>> I am sorry, but you lost me... >>>>> >>>>> I fully agree, the PRNG assumption may not hold. But I don't quite >>>>> follow where you set a fixed date (or was your choice of the > signed >>>> unix >>>>> epoch rollover random?)... >>>> >>>> I picked dates that had the bits set as you indicated ;-) >>>> >>> From rs@netapp.com Thu Jul 7 02:47:37 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D236E21F86B6 for ; Thu, 7 Jul 2011 02:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waZUDedM7poV for ; Thu, 7 Jul 2011 02:47:37 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8463E21F86AA for ; Thu, 7 Jul 2011 02:47:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,492,1304319600"; d="scan'208";a="262666444" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 07 Jul 2011 02:47:34 -0700 Received: from amsrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p679lY2f004017; Thu, 7 Jul 2011 02:47:34 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jul 2011 11:47:34 +0200 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, 7 Jul 2011 10:47:12 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0F1E33AA@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <4E1496A5.3090401@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] feedback from group to draft-scheffenegger-tcpm-timestamp-negotiation-02.txt Thread-Index: Acw7/3gbiLuwazKYSUSyC/ReqIuPuAAAXzGQ References: <5FDC413D5FA246468C200652D63E627A0E99C04B@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0E99C04C@LDCMVEXC1-PRD.hq.netapp.com> <4DE51EC0.7070302@isi.edu> <5FDC413D5FA246468C200652D63E627A0E99CD4C@LDCMVEXC1-PRD.hq.netapp.com> <4DE57E52.5030501@isi.edu> <5FDC413D5FA246468C200652D63E627A0EAA9115@LDCMVEXC1-PRD.hq.netapp.com> <4DE666DB.3010109@isi.edu> <5FDC413D5FA246468C200652D63E627A0EAA9444@LDCMVEXC1-PRD.hq.netapp.com> <4DE6A6D8.20908@isi.edu> <5FDC413D5FA246468C200652D63E627A0F1E3100@LDCMVEXC1-PRD.hq.netapp.com> <4E1488A6.1040809@isi.edu> <5FDC413D5FA246468C200652D63E627A0F1E3124@LDCMVEXC1-PRD.hq.netapp.com> <4E1496A5.3090401@isi.edu> From: "Scheffenegger, Richard" To: "Joe Touch" X-OriginalArrivalTime: 07 Jul 2011 09:47:34.0536 (UTC) FILETIME=[E5CB4880:01CC3C8A] Cc: tcpm@ietf.org Subject: Re: [tcpm] feedback from group to draft-scheffenegger-tcpm-timestamp-negotiation-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2011 09:47:37 -0000 Hi Joe, > The part that bothers me is that the retransmits had a much higher > (nearly 50%) repeat rate of errors, so your logic doesn't hold. I.e., > this takes a broken implementation that had no impact and makes it > break > a connection. I was being imprecise. In the traces, there are series of two or more SYNs (actually, the few instances I have looked at in detail so far, a series of very short (<10 pkts) tcp sessions) that are in close succession, between the same hosts, but different source ports, where the TSecr is identical and non-zero.=20 I still need to investigate, if the later sender has always a preceding TCP session, by which it learned some TSval from the later receiver. (I.e. to differentiate between genuinely broken implementations, that send some non-zeroed memory fragment, vs. implementations that re-use some prior TCPCB under some circumstances, without clearing it properly - see below. When looking at TSecr values and their distribution, I called these duplicates, as they are duplicating the TSecr in close temporal proximity. The receivers timestamp clock was still identical between these sessions - also indicating, that the receiver is not using timestamp randomization. > It'd be useful to track that down to *confirm* that it's a broken > implementation, and what OS/version it tracks to. One misbehaving stack appears to be a version of linux, from the passive fingerprint (order of TCP options, initial values used in the tcp header field of the [SYN]). Again, I need to verify this for all ~2000 occurances and not just a handful. =20 > > Thus these broken implementations are disadvantaged w.r.t. legacy > > RFC1323 implementations, while new implementations can benefit from > > improved TCP CC reaction and improved loss recovery... >=20 > The concern right now is that 'broken' used to mean either silently > working or at worst slightly slower, and you're breaking it harder. > Although 1323 says MUST, 'be generous in what you receive' means > generally ignoring errors in that field, since it wasn't spec'd for > other uses. >=20 > I.e., making TCP more brittle at the expense of a performance win is a > bad thing, IMO. IMHO, the draft doesn't make TCP itself more brittle; it puts clients which are not fully compliant at a slight disadvantage - possibly motivating the upgrade of these clients. If the misbehavior only appears when there was a preceding tcp session within 2 MSL, there may be some mitigations: A possible workaround would be to have a TCP receiver send TSval=3D0 = with [FIN] control packets (if the receiver used timestamp randomization), or check if the TSecr received in a [SYN] is close to its current timestamp clock. That may indicate the sender is echoing the timestamp value of a preceeding session. Obviously, that latter approach fails, if timestamp randomization is used. RFC1323 already declares, that TSval=3D0 has a special meaning (no valid timestamp available), and with the observed misbehaving clients, this would effectively clear out the stored timestamp value in the re-used TCPCB. Afterwards, the next [SYN] would look clean again to the receiver... BTW, Linux was long time broken in this respect as well, as TSval=3D0 in = a [SYN] (i.e. from Win95/98/2000 clients) would disable timestamps for the session - the [SYN,ACK] from a linux box would not contain the timestamp option. > If these errors can be tracked and confirmed as a bug (and hopefully a > patch issued), then that's another story... The TCP/IP header options investigated so far indicate, that this behavior shows with Linux Kernels - see also http://kerneltrap.org/mailarchive/linux-netdev/2009/4/10/5446374 Seems to be considered a "feature" of linux (in violation of RFC1323), not a bug... But it's non-default, enabled by tweaking some sysctls. =20 However, I don't like to cater for specific "features" (bugs) of one particular TCP implementation (Linux) in a potential standards document, especially when these are due to non-default tunables or already fixed bugs (TSval=3D0 [SYN]). Best regards, Richard=20 From touch@isi.edu Thu Jul 7 10:38:12 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C271F0C46 for ; Thu, 7 Jul 2011 10:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.939 X-Spam-Level: X-Spam-Status: No, score=-105.939 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aC2mVmJ0xXJH for ; Thu, 7 Jul 2011 10:38:11 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 61AAB1F0C44 for ; Thu, 7 Jul 2011 10:38:11 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p67HaDNT016001 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 7 Jul 2011 10:36:13 -0700 (PDT) Message-ID: <4E15EE8D.3060804@isi.edu> Date: Thu, 07 Jul 2011 10:36:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <5FDC413D5FA246468C200652D63E627A0E99C04B@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0E99C04C@LDCMVEXC1-PRD.hq.netapp.com> <4DE51EC0.7070302@isi.edu> <5FDC413D5FA246468C200652D63E627A0E99CD4C@LDCMVEXC1-PRD.hq.netapp.com> <4DE57E52.5030501@isi.edu> <5FDC413D5FA246468C200652D63E627A0EAA9115@LDCMVEXC1-PRD.hq.netapp.com> <4DE666DB.3010109@isi.edu> <5FDC413D5FA246468C200652D63E627A0EAA9444@LDCMVEXC1-PRD.hq.netapp.com> <4DE6A6D8.20908@isi.edu> <5FDC413D5FA246468C200652D63E627A0F1E3100@LDCMVEXC1-PRD.hq.netapp.com> <4E1488A6.1040809@isi.edu> <5FDC413D5FA246468C200652D63E627A0F1E3124@LDCMVEXC1-PRD.hq.netapp.com> <4E1496A5.3090401@isi.edu> <5FDC413D5FA246468C200652D63E627A0F1E33AA@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0F1E33AA@LDCMVEXC1-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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] feedback from group to draft-scheffenegger-tcpm-timestamp-negotiation-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2011 17:38:12 -0000 Hi, Richard, On 7/7/2011 2:47 AM, Scheffenegger, Richard wrote: ... > The TCP/IP header options investigated so far indicate, that this > behavior shows with Linux Kernels - see also > http://kerneltrap.org/mailarchive/linux-netdev/2009/4/10/5446374 > > Seems to be considered a "feature" of linux (in violation of RFC1323), > not a bug... But it's non-default, enabled by tweaking some sysctls. Ick. Pity this isn't more of a surprise. > However, I don't like to cater for specific "features" (bugs) of one > particular TCP implementation (Linux) in a potential standards document, > especially when these are due to non-default tunables or already fixed > bugs (TSval=0 [SYN]). One of our challenges is how to deal with this sort of issue, which includes things like ignoring the current IW (and IETF process for that one), using a nonstandard congestion alg, etc. I'm glad to have the WG put its foot down on this sort of thing, but it ought to do so uniformly, IMO. Joe From Michael.Scharf@alcatel-lucent.com Thu Jul 7 10:53:45 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C721F0C60 for ; Thu, 7 Jul 2011 10:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgQC1mhV3ObP for ; Thu, 7 Jul 2011 10:53:44 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 58D721F0C5D for ; Thu, 7 Jul 2011 10:53:44 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p67HrggS001947; Thu, 7 Jul 2011 19:53:42 +0200 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, 7 Jul 2011 19:53:41 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0654B39C@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for agenda items - REMINDER Thread-Index: AcwqmhMy3Lq5oLbgSqq0R8Kt81WFTQSM6q3Q From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Cc: tcpm-chairs@tools.ietf.org Subject: [tcpm] Call for agenda items - REMINDER X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2011 17:53:45 -0000 Dear all,=20 the TCPM WG session has been scheduled for Tuesday moring (tentatively, as usually). The chairs have to set up the agenda. If you have a topic you would like a slot for, and if you haven't asked for a slot yet, please send the chairs a request ASAP. Thanks Michael -----Original Message----- From: SCHARF, Michael [mailto:Michael.Scharf@alcatel-lucent.com]=20 Sent: Tuesday, June 14, 2011 3:51 PM To: tcpm@ietf.org Cc: tcpm-chairs@tools.ietf.org Subject: TCPM meeting in Quebec City: Call for agenda items Dear all, the TCPM WG is expected to meet in Quebec City. If you want to present a draft there, please drop a note to the TCPM WG co-chairs as soon as possible. The deadline for agenda requests is July 1. Please provide the following information: * draft name / presentation title * presenter * estimated duration In order to ensure an efficient meeting, all presenters should also provide an initial version of the planned presentation to the chairs by July 8. Thanks a lot! David Borman and Michael Scharf (TCPM WG co-chairs) From touch@isi.edu Thu Jul 7 17:59:59 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F75021F891E for ; Thu, 7 Jul 2011 17:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.882 X-Spam-Level: X-Spam-Status: No, score=-105.882 tagged_above=-999 required=5 tests=[AWL=0.717, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmiZ82roHbgs for ; Thu, 7 Jul 2011 17:59:58 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A4BA421F8915 for ; Thu, 7 Jul 2011 17:59:58 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p680xh5A008105 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 7 Jul 2011 17:59:43 -0700 (PDT) Message-ID: <4E16567F.2@isi.edu> Date: Thu, 07 Jul 2011 17:59:43 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-automatic-iw-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 00:59:59 -0000 FYI. This version incorporates suggestions from various discussions on the mailing list shortly after the doc was initially posted. I intend to pursue this as an experimental extension to TCP. I would be glad to have further feedback. Note that some portions of the doc intended to be 'fleshed out' further are waiting for a decision as to whether this will become a TCPM doc or an individual submission. Joe -------- Original Message -------- Subject: New Version Notification for draft-touch-tcpm-automatic-iw-01.txt Date: Thu, 07 Jul 2011 17:56:36 -0700 From: internet-drafts@ietf.org To: touch@isi.edu CC: touch@isi.edu A new version of I-D, draft-touch-tcpm-automatic-iw-01.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Filename: draft-touch-tcpm-automatic-iw Revision: 01 Title: Automating the Initial Window in TCP Creation date: 2011-07-07 WG ID: Individual Submission Number of pages: 11 Abstract: The Initial Window (IW) provides the starting point for TCP's feedback-based congestion control algorithm. Its value has increased over time to increase performance and to reflect increased capability of Internet devices. This document describes a mechanism to adjust the IW over long timescales, to make future changes more safely deployed and to potentially avoid reexamination of this value in the future. The IETF Secretariat From Michael.Scharf@alcatel-lucent.com Tue Jul 12 16:54:44 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A88C11E80AF for ; Tue, 12 Jul 2011 16:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGYJ2YuJzPbS for ; Tue, 12 Jul 2011 16:54:43 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADC611E80AE for ; Tue, 12 Jul 2011 16:54:43 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p6CNsgu1013487 for ; Wed, 13 Jul 2011 01:54:42 +0200 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: Wed, 13 Jul 2011 01:54:40 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0654B57A@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for input regarding the initial window increase Thread-Index: AcxA7xCWInpOSAUpQ7iLQFJHwZvw7w== From: "SCHARF, Michael" To: "TCP Maintenance and Minor Extensions WG" X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Subject: [tcpm] Request for input regarding the initial window increase X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 23:54:44 -0000 Dear all, according to the TCPM charter, the working group has to determine the intended publication track for the document on increasing the initial window by Aug. 2011. In addition, there are some further open issues regarding an increase of TCP's permitted initial congestion window. I tried to narrow this down to three key questions: Question 1: Moving forward a fixed increase of the permitted TCP initial congestion window (draft-ietf-tcpm-initcwnd-01)? Answer 1A: Fixed upper limit to proposed standard Answer 2B: Fixed upper limit to experimental Answer 3C: Something else (e. g., some adaptive scheme, or no change at all compared to RFC 3390); this would imply a substantial change of draft-ietf-tcpm-initcwnd-01 Question 2: Maximum permitted initial congestion window? Answer 2A: 10 MSS for an MTU of 1500 byte as suggested by draft-ietf-tcpm-initcwnd-01 (other MTUs are still TBD) Answer 2B: Another value (please suggest and justify) Question 3: Adaptive solution as an alternative? Answer 3A: Adoption of draft-touch-tcpm-automatic-iw-01 as WG item heading towards experimental Answer 3B: No adoption These questions have partly been discussed so far (e. g., http://www.ietf.org/mail-archive/web/tcpm/current/msg06221.html), but in order to determine the working group consensus, additional feedback and opinions from the group would be very helpful. This also includes the question whether there are further possibilities to be considered. The chairs plan to allocate some meeting time in Quebec City for this charter item, but prior input on the list would be highly welcome. Thanks! Michael Scharf and David Borman (TCPM co-chairs) From wes@mti-systems.com Tue Jul 12 17:53:01 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86EF11E80D3 for ; Tue, 12 Jul 2011 17:53:01 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybuilTVCQm-w for ; Tue, 12 Jul 2011 17:53:01 -0700 (PDT) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACF411E80C7 for ; Tue, 12 Jul 2011 17:53:00 -0700 (PDT) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p6D0r0rK003463 for ; Tue, 12 Jul 2011 20:53:00 -0400 Authentication-Results: cm-omr3 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.71.64] ([174.130.71.64:4514] helo=[192.168.1.103]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 82/4D-28066-C6CEC1E4; Tue, 12 Jul 2011 20:53:00 -0400 Message-ID: <4E1CEC6C.7030607@mti-systems.com> Date: Tue, 12 Jul 2011 20:53:00 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: tcpm@ietf.org References: <133D9897FB9C5E4E9DF2779DC91E947C0654B57A@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C0654B57A@SLFSNX.rcs.alcatel-research.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Request for input regarding the initial window increase X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 00:53:01 -0000 My personal responses as a WG participant are below: On 7/12/2011 7:54 PM, SCHARF, Michael wrote: > > ... > > Question 1: Moving forward a fixed increase of the permitted TCP initial > congestion window (draft-ietf-tcpm-initcwnd-01)? > > Answer 1A: Fixed upper limit to proposed standard > Answer 2B: Fixed upper limit to experimental > Answer 3C: Something else (e. g., some adaptive scheme, or no change at > all compared to RFC 3390); this would imply a substantial change of > draft-ietf-tcpm-initcwnd-01 I think B (Experimental) is a conservative approach. I'm happy with that and scoping the "experiment" for general use on the Internet, with intent to come back and go to Proposed Standard at some point. Essentially, it already has close to that status ;). > Question 2: Maximum permitted initial congestion window? > > Answer 2A: 10 MSS for an MTU of 1500 byte as suggested by > draft-ietf-tcpm-initcwnd-01 (other MTUs are still TBD) > Answer 2B: Another value (please suggest and justify) I think 2A is appropriate due to the volume of analysis that used the same value (10MSS). Anything greater hasn't been looked at as much, and anything lesser sacrifices the intent. > Question 3: Adaptive solution as an alternative? > > Answer 3A: Adoption of draft-touch-tcpm-automatic-iw-01 as WG item > heading towards experimental > Answer 3B: No adoption I favor 3A, sort-of. I would rather see it generalized to explain how the same algorithm can be used for tuning SCTP and potentially a subset of CCIDs for DCCP. Otherwise we're begging someone to write more documents later in order to tell us how the same thing applies to those other protocols. -- Wes Eddy MTI Systems From hkchu@google.com Tue Jul 12 18:47:36 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A934D9E8014 for ; Tue, 12 Jul 2011 18:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9dpijZnOYHG for ; Tue, 12 Jul 2011 18:47:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 935DF9E8004 for ; Tue, 12 Jul 2011 18:47:35 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p6D1lYlV015895 for ; Tue, 12 Jul 2011 18:47:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310521654; bh=L3QwMEub0ALmX+U2T/1+ybNtJoc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=T4DGYJrc615kSF2hCnCrrAoI/xnbCvZf6ae1SbiMXesIkg85ZIbDUpNpsvNwzFkII J75MNwhoki5cbnm0UnHmQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=rc5cAjKA36byHwjIWmS7zbFBrQddBLWsukbFS+AQdOXwlKiztw2mQQQkYynOfbAf/ ot++puPfOri4uTuw2hIgQ== Received: from gyf1 (gyf1.prod.google.com [10.243.50.65]) by hpaq2.eem.corp.google.com with ESMTP id p6D1lWmB026789 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 12 Jul 2011 18:47:33 -0700 Received: by gyf1 with SMTP id 1so2625619gyf.37 for ; Tue, 12 Jul 2011 18:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dotMB0ToXtAKrT+7rMMSiY5S7RKRVxgOEHd4Vwz/Ze0=; b=KHbeBVEkaEBD54wKm6vwBzbhmi1JMX0ZAxXwjrSI5ErnBJ3/yOF3j8XTXv0LBwn1fJ 9WSWjw7phb6myclNAA9Q== MIME-Version: 1.0 Received: by 10.150.165.14 with SMTP id n14mr680298ybe.408.1310521652450; Tue, 12 Jul 2011 18:47:32 -0700 (PDT) Received: by 10.150.226.20 with HTTP; Tue, 12 Jul 2011 18:47:32 -0700 (PDT) In-Reply-To: <4E1CEC6C.7030607@mti-systems.com> References: <133D9897FB9C5E4E9DF2779DC91E947C0654B57A@SLFSNX.rcs.alcatel-research.de> <4E1CEC6C.7030607@mti-systems.com> Date: Tue, 12 Jul 2011 18:47:32 -0700 Message-ID: From: Jerry Chu To: Wesley Eddy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] Request for input regarding the initial window increase X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 01:47:36 -0000 On Tue, Jul 12, 2011 at 5:53 PM, Wesley Eddy wrote: > > My personal responses as a WG participant are below: > > On 7/12/2011 7:54 PM, SCHARF, Michael wrote: >> >> ... >> >> Question 1: Moving forward a fixed increase of the permitted TCP initial >> congestion window (draft-ietf-tcpm-initcwnd-01)? >> >> Answer 1A: Fixed upper limit to proposed standard >> Answer 2B: Fixed upper limit to experimental >> Answer 3C: Something else (e. g., some adaptive scheme, or no change at >> all compared to RFC 3390); this would imply a substantial change of >> draft-ietf-tcpm-initcwnd-01 > > I think B (Experimental) is a conservative approach. =A0I'm happy with > that and scoping the "experiment" for general use on the Internet, with I'm curious about how to scope an "experiment" for "general use". I didn't know one can have both at the same time... > > intent to come back and go to Proposed Standard at some point. > Essentially, it already has close to that status ;). Yes and our "very large" ;-) experiment with IW=3D10 has been ongoing for more than a year. I wonder how much more experiment is required for 1A, which is my preference, unless you have IW > 10 in mind. BTW, with Linux adopting IW=3D10 a few month back, the "experiment" has been getting even larger everyday. > > > >> Question 2: Maximum permitted initial congestion window? >> >> Answer 2A: 10 MSS for an MTU of 1500 byte as suggested by >> draft-ietf-tcpm-initcwnd-01 (other MTUs are still TBD) >> Answer 2B: Another value (please suggest and justify) > > I think 2A is appropriate due to the volume of analysis that used the > same value (10MSS). =A0Anything greater hasn't been looked at as much, > and anything lesser sacrifices the intent. Agreed. > > >> Question 3: Adaptive solution as an alternative? >> >> Answer 3A: Adoption of draft-touch-tcpm-automatic-iw-01 as WG item >> heading towards experimental >> Answer 3B: No adoption > > > I favor 3A, sort-of. =A0I would rather see it generalized to explain how = the same algorithm can be used for tuning SCTP and potentially a subset of = CCIDs for DCCP. =A0Otherwise we're begging someone to write more > documents later in order to tell us how the same thing applies to those > other protocols. +1. Jerry > > -- > Wes Eddy > MTI Systems > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From wes@mti-systems.com Wed Jul 13 06:06:18 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21C521F84D5 for ; Wed, 13 Jul 2011 06:06:17 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dt6MUZAzB+At for ; Wed, 13 Jul 2011 06:06:17 -0700 (PDT) Received: from omr2.networksolutionsemail.com (omr2.networksolutionsemail.com [205.178.146.52]) by ietfa.amsl.com (Postfix) with ESMTP id AE1F021F84CC for ; Wed, 13 Jul 2011 06:01:55 -0700 (PDT) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p6DD1t1O003612 for ; Wed, 13 Jul 2011 09:01:55 -0400 Authentication-Results: cm-omr12 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [107.46.38.28] ([107.46.38.28:44903] helo=[192.168.9.2]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 40/0D-24736-2479D1E4; Wed, 13 Jul 2011 09:01:55 -0400 Message-ID: <4E1D9742.607@mti-systems.com> Date: Wed, 13 Jul 2011 09:01:54 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Jerry Chu References: <133D9897FB9C5E4E9DF2779DC91E947C0654B57A@SLFSNX.rcs.alcatel-research.de> <4E1CEC6C.7030607@mti-systems.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] Request for input regarding the initial window increase X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 13:06:18 -0000 On 7/12/2011 9:47 PM, Jerry Chu wrote: > On Tue, Jul 12, 2011 at 5:53 PM, Wesley Eddy wrote: >> >> My personal responses as a WG participant are below: >> >> On 7/12/2011 7:54 PM, SCHARF, Michael wrote: >>> >>> ... >>> >>> Question 1: Moving forward a fixed increase of the permitted TCP initial >>> congestion window (draft-ietf-tcpm-initcwnd-01)? >>> >>> Answer 1A: Fixed upper limit to proposed standard >>> Answer 2B: Fixed upper limit to experimental >>> Answer 3C: Something else (e. g., some adaptive scheme, or no change at >>> all compared to RFC 3390); this would imply a substantial change of >>> draft-ietf-tcpm-initcwnd-01 >> >> I think B (Experimental) is a conservative approach. I'm happy with >> that and scoping the "experiment" for general use on the Internet, with > > I'm curious about how to scope an "experiment" for "general use". I didn't > know one can have both at the same time... > That means normal hosts on the Internet are intended to participate in the experiment if desired. In other words, it's not just to be limited to some testbed settings, within a corporate network, etc. I think that's appropriate, as Proposed Standard seems like it would imply that IW3 would go Obsolete, which I'm not sure is right yet. Or would IW3 and IW10 both coexist as PS? That seems confusing; IW10 as Experimental seems clear as it says we think it's perfectly reasonable to try out at large scale, but we also think IW3 is still a reasonable default. That's just my feeling; I think it's close to what some others have expressed, but am very curious what the consensus will be. -- Wes Eddy MTI Systems From hkchu@google.com Wed Jul 13 11:49:50 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC42F11E8138 for ; Wed, 13 Jul 2011 11:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWaKKG89P796 for ; Wed, 13 Jul 2011 11:49:50 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8771211E80B2 for ; Wed, 13 Jul 2011 11:49:46 -0700 (PDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p6DIniZL026741 for ; Wed, 13 Jul 2011 11:49:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310582985; bh=7H7vCrf0xy5+zhl2v8ljDvuj9go=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=JLTR2eEuNMcWxGzeoIBTtz3/PZKsfGLbIlqz/Q72nDkEcbUZgwLnnGeM6Kf/P/awc c+9rnzOd89m/Yusw2j8+g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=wSmex0mAa1TGMt9rNLa55a40a5t6nTWyd8B74ySNzwWfm88sBykZJm5qL6p+LOXUY A6Ijr4T9mEIS3+JWOBW5w== Received: from yia25 (yia25.prod.google.com [10.243.65.25]) by kpbe20.cbf.corp.google.com with ESMTP id p6DInVaU030456 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 13 Jul 2011 11:49:43 -0700 Received: by yia25 with SMTP id 25so3498777yia.18 for ; Wed, 13 Jul 2011 11:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T8g6kX9/I09uVXF/d0CLh9fRXSAJ+0VZBvJhuu5JPlY=; b=yjpqo5JSbFPfqdnO6oMIitTThlwCnDkHFWSTgtu+wDDqtOY1y7btB9x16+Jy0t6Vvo afQUwUYLsNp33tSy2Qug== MIME-Version: 1.0 Received: by 10.150.164.6 with SMTP id m6mr1635100ybe.351.1310582983236; Wed, 13 Jul 2011 11:49:43 -0700 (PDT) Received: by 10.150.226.20 with HTTP; Wed, 13 Jul 2011 11:49:43 -0700 (PDT) In-Reply-To: <4E1D9742.607@mti-systems.com> References: <133D9897FB9C5E4E9DF2779DC91E947C0654B57A@SLFSNX.rcs.alcatel-research.de> <4E1CEC6C.7030607@mti-systems.com> <4E1D9742.607@mti-systems.com> Date: Wed, 13 Jul 2011 11:49:43 -0700 Message-ID: From: Jerry Chu To: Wesley Eddy Content-Type: multipart/alternative; boundary=000e0cd5738c2a1ba304a7f7e1c2 X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] Request for input regarding the initial window increase X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 18:49:50 -0000 --000e0cd5738c2a1ba304a7f7e1c2 Content-Type: text/plain; charset=ISO-8859-1 Hi Wes, On Wed, Jul 13, 2011 at 6:01 AM, Wesley Eddy wrote: > On 7/12/2011 9:47 PM, Jerry Chu wrote: > >> On Tue, Jul 12, 2011 at 5:53 PM, Wesley Eddy wrote: >> >>> >>> My personal responses as a WG participant are below: >>> >>> On 7/12/2011 7:54 PM, SCHARF, Michael wrote: >>> >>>> >>>> ... >>>> >>>> Question 1: Moving forward a fixed increase of the permitted TCP initial >>>> congestion window (draft-ietf-tcpm-initcwnd-01)? >>>> >>>> Answer 1A: Fixed upper limit to proposed standard >>>> Answer 2B: Fixed upper limit to experimental >>>> Answer 3C: Something else (e. g., some adaptive scheme, or no change at >>>> all compared to RFC 3390); this would imply a substantial change of >>>> draft-ietf-tcpm-initcwnd-01 >>>> >>> >>> I think B (Experimental) is a conservative approach. I'm happy with >>> that and scoping the "experiment" for general use on the Internet, with >>> >> >> I'm curious about how to scope an "experiment" for "general use". I didn't >> know one can have both at the same time... >> >> > That means normal hosts on the Internet are intended to participate > in the experiment if desired. In other words, it's not just to be > limited to some testbed settings, within a corporate network, etc. > First, it has not been limited to just testbed or corporate network for more than a year. Second, to participate in the experiment the OSes running on the endhosts must support a larger IW to begin with. Without a Standard status I wonder how many OSes (with the exception of Linux) will provide the support; and if the support is indeed added but requires some complex configuration steps to turn it on, then I wonder how much of real participation it may draw. If the support is added and is also on by default will it still be compatible with the spirit of the "Experimental" status? We have been closely monitoring our deployment for over a year and have not noticed any issue (details can be found in the latest draft and paper referenced). I think it's about time to take the step forward to make IW10 a PS otherwise it may get stuck in Experimental forever (unless OSes all change their default to IW10 then it becomes moot). I think that's appropriate, as Proposed Standard seems like it would > imply that IW3 would go Obsolete, which I'm not sure is right yet. > Or would IW3 and IW10 both coexist as PS? That seems confusing; Note that in both RFC3390 and draft-ietf-tcpm-initcwnd-01.txt the IW number only serves as an upperbound and is OPTIONAL so the two docs are not really in direct conflict. Best, Jerry IW10 as Experimental seems clear as it says we think it's perfectly > reasonable to try out at large scale, but we also think IW3 is still > a reasonable default. > > That's just my feeling; I think it's close to what some others have > expressed, but am very curious what the consensus will be. > -- > Wes Eddy > MTI Systems > --000e0cd5738c2a1ba304a7f7e1c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Wes,

On Wed, Jul 13, 2011 at 6:01 AM, Wesley Eddy <wes@mti-systems.com><= /span> wrote:
On 7/12/2011 9:47 PM, Jerry Chu wrote:
On Tue, Jul 12, 2011 at 5:53 PM, Wesley Eddy<wes@mti-systems.com> =A0wrote:

My personal responses as a WG participant are below:

On 7/12/2011 7:54 PM, SCHARF, Michael wrote:

...

Question 1: Moving forward a fixed increase of the permitted TCP initial congestion window (draft-ietf-tcpm-initcwnd-01)?

Answer 1A: Fixed upper limit to proposed standard
Answer 2B: Fixed upper limit to experimental
Answer 3C: Something else (e. g., some adaptive scheme, or no change at
all compared to RFC 3390); this would imply a substantial change of
draft-ietf-tcpm-initcwnd-01

I think B (Experimental) is a conservative approach. =A0I'm happy with<= br> that and scoping the "experiment" for general use on the Internet= , with

I'm curious about how to scope an "experiment" for "gene= ral use". I didn't
know one can have both at the same time...


That means normal hosts on the Internet are intended to participate
in the experiment if desired. =A0In other words, it's not just to be limited to some testbed settings, within a corporate network, etc.

First, it has not been limited to just testbed = or corporate network for more
than=A0a year. Second, to participa= te in the experiment the OSes running on the
endhosts must support=A0a larger IW to begin with. Without a Standard = status
I wonder how many OSes (with the exception of Linux) will = provide the
support; and if the support is indeed added but requi= res some complex
configuration steps to=A0turn it on, then I wonder how much of real pa= rticipation
it may draw.=A0If the support is added and is also on= by default will it still be
compatible=A0with=A0the spirit of th= e "Experimental" status?

We have been closely monitoring our deployment for over= a year and have
not noticed any issue (details can be found in t= he latest draft and paper
referenced). I think it's about tim= e to take the step forward to make IW10
a PS otherwise it may get stuck in Experimental forever (unless=A0OSes= all
change their default to IW10 then it becomes moot).

I think that's appropriate, as Proposed Standard seems like it would imply that IW3 would go Obsolete, which I'm not sure is right yet.
Or would IW3 and IW10 both coexist as PS? =A0That seems confusing;

Note that in both RFC3390 and=A0draft-ietf-tcpm-ini= tcwnd-01.txt the IW
number only serves as an upperbound and is OP= TIONAL so the two
docs are not really=A0in direct conflict.

Bes= t,

Jerry

IW10 as Experimental seems clear as it says we think it's perfectly
reasonable to try out at large scale, but we also think IW3 is still
a reasonable default.

That's just my feeling; I think it's close to what some others have=
expressed, but am very curious what the consensus will be.=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;">
--
Wes Eddy
MTI Systems

--000e0cd5738c2a1ba304a7f7e1c2-- From touch@isi.edu Wed Jul 13 14:04:43 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A93421F8B09 for ; Wed, 13 Jul 2011 14:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.529 X-Spam-Level: X-Spam-Status: No, score=-103.529 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8hkfOVEjUry for ; Wed, 13 Jul 2011 14:04:42 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 782AD21F8B02 for ; Wed, 13 Jul 2011 14:04:42 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p6DL4GGg005628 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 13 Jul 2011 14:04:16 -0700 (PDT) Message-ID: <4E1E084F.6000000@isi.edu> Date: Wed, 13 Jul 2011 14:04:15 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Wesley Eddy References: <133D9897FB9C5E4E9DF2779DC91E947C0654B57A@SLFSNX.rcs.alcatel-research.de> <4E1CEC6C.7030607@mti-systems.com> In-Reply-To: <4E1CEC6C.7030607@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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] Request for input regarding the initial window increase X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 21:04:43 -0000 On 7/12/2011 5:53 PM, Wesley Eddy wrote: > My personal responses as a WG participant are below: > > On 7/12/2011 7:54 PM, SCHARF, Michael wrote: >> >> ... >> >> Question 1: Moving forward a fixed increase of the permitted TCP initial >> congestion window (draft-ietf-tcpm-initcwnd-01)? >> >> Answer 1A: Fixed upper limit to proposed standard >> Answer 2B: Fixed upper limit to experimental >> Answer 3C: Something else (e. g., some adaptive scheme, or no change at >> all compared to RFC 3390); this would imply a substantial change of >> draft-ietf-tcpm-initcwnd-01 > > I think B (Experimental) is a conservative approach. I'm happy with > that and scoping the "experiment" for general use on the Internet, with > intent to come back and go to Proposed Standard at some point. > Essentially, it already has close to that status ;). +1 I would like to also see some discussion of a metric to know whether this is working or not (i.e., it's been deployed, but just because we don't see a problem doesn't mean one isn't happening). >> Question 2: Maximum permitted initial congestion window? >> >> Answer 2A: 10 MSS for an MTU of 1500 byte as suggested by >> draft-ietf-tcpm-initcwnd-01 (other MTUs are still TBD) >> Answer 2B: Another value (please suggest and justify) > > I think 2A is appropriate due to the volume of analysis that used the > same value (10MSS). Anything greater hasn't been looked at as much, > and anything lesser sacrifices the intent. I think it should mirror how it was stated previously: M segments OR N bytes, whichever is *smaller*. As to the M and N, there is clearly a goal of 10 1500-byte packets (15,000 bytes). Compared to RFC 3390, that's 3.4x more bytes *and* 5x more segments (at 1500 bytes, 3390 would yield 2 MSS). The arguments in favor appear to be based on the 99% - or even 99.5% - case, and too much focused on current (and, IMO, likely ephemeral) transfer size measurements. I prefer to consider the increased variety of links and uses and trade safety for over-optimizing performance. I personally would be more comfortable with doubling the numbers from RFC 3390, i.e., "4 segments or 8760 bytes whichever is smaller", as well as adding "SHOULD round down to an even number of segments" (to avoid creating compressed ACK stalls). >> Question 3: Adaptive solution as an alternative? >> >> Answer 3A: Adoption of draft-touch-tcpm-automatic-iw-01 as WG item >> heading towards experimental >> Answer 3B: No adoption > > I favor 3A, sort-of. I would rather see it generalized to explain how > the same algorithm can be used for tuning SCTP and potentially a subset > of CCIDs for DCCP. Otherwise we're begging someone to write more > documents later in order to tell us how the same thing applies to those > other protocols. +1 on all points (FWIW, it was always intended to apply across all AIMD congestion control scenarios). Joe From hkchu@google.com Wed Jul 13 14:52:58 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C876B11E81C0 for ; Wed, 13 Jul 2011 14:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKO0NhDMhVjM for ; Wed, 13 Jul 2011 14:52:58 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 226E311E81AE for ; Wed, 13 Jul 2011 14:52:56 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id p6DLqtVD001354 for ; Wed, 13 Jul 2011 14:52:55 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310593976; bh=0GDEbdCAuWoGOXr6e/+avcN+e1U=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=HsOQdf6nxHQNAZ89+tR50RYltzEDp2MJ2b7Y1o30d2fIKKFNiY+R/mxG7ga4mWmso Lb0H2zjEDAGr+9INex3KQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=Ff8XZQE8zs0WZsCqCPEPfs6LFaczh2FVvCvJbKQuHDYMYhVm4F1QZYI3vqJWTaM0+ PJAWLOZ9IEaFpf2oFV0Jg== Received: from gwj17 (gwj17.prod.google.com [10.200.10.17]) by kpbe15.cbf.corp.google.com with ESMTP id p6DLqrkc014276 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 13 Jul 2011 14:52:54 -0700 Received: by gwj17 with SMTP id 17so2785403gwj.38 for ; Wed, 13 Jul 2011 14:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FBsW1Qq/KkAzA/+ghlq1v+3qjaanjRG5jG9LZa+O2VM=; b=B9gKbi9z7coC4y7bM4EivIhrvJSEkf5gHQfJHxtojD7OV5TI/G7yI47r9VbR/2gasW lnlgK50xsxv9FlV9OeuQ== MIME-Version: 1.0 Received: by 10.150.220.15 with SMTP id s15mr1880109ybg.66.1310593972115; Wed, 13 Jul 2011 14:52:52 -0700 (PDT) Received: by 10.150.226.20 with HTTP; Wed, 13 Jul 2011 14:52:51 -0700 (PDT) In-Reply-To: <4E1E084F.6000000@isi.edu> References: <133D9897FB9C5E4E9DF2779DC91E947C0654B57A@SLFSNX.rcs.alcatel-research.de> <4E1CEC6C.7030607@mti-systems.com> <4E1E084F.6000000@isi.edu> Date: Wed, 13 Jul 2011 14:52:51 -0700 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] Request for input regarding the initial window increase X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 21:52:58 -0000 Hi Joe, On Wed, Jul 13, 2011 at 2:04 PM, Joe Touch wrote: > > > On 7/12/2011 5:53 PM, Wesley Eddy wrote: >> >> My personal responses as a WG participant are below: >> >> On 7/12/2011 7:54 PM, SCHARF, Michael wrote: >>> >>> ... >>> >>> Question 1: Moving forward a fixed increase of the permitted TCP initial >>> congestion window (draft-ietf-tcpm-initcwnd-01)? >>> >>> Answer 1A: Fixed upper limit to proposed standard >>> Answer 2B: Fixed upper limit to experimental >>> Answer 3C: Something else (e. g., some adaptive scheme, or no change at >>> all compared to RFC 3390); this would imply a substantial change of >>> draft-ietf-tcpm-initcwnd-01 >> >> I think B (Experimental) is a conservative approach. I'm happy with >> that and scoping the "experiment" for general use on the Internet, with >> intent to come back and go to Proposed Standard at some point. >> Essentially, it already has close to that status ;). > > +1 > > I would like to also see some discussion of a metric to know whether this is > working or not (i.e., it's been deployed, but just because we don't see a > problem doesn't mean one isn't happening). > >>> Question 2: Maximum permitted initial congestion window? >>> >>> Answer 2A: 10 MSS for an MTU of 1500 byte as suggested by >>> draft-ietf-tcpm-initcwnd-01 (other MTUs are still TBD) >>> Answer 2B: Another value (please suggest and justify) >> >> I think 2A is appropriate due to the volume of analysis that used the >> same value (10MSS). Anything greater hasn't been looked at as much, >> and anything lesser sacrifices the intent. > > I think it should mirror how it was stated previously: M segments OR N > bytes, whichever is *smaller*. > > As to the M and N, there is clearly a goal of 10 1500-byte packets (15,000 > bytes). Compared to RFC 3390, that's 3.4x more bytes *and* 5x more segments > (at 1500 bytes, 3390 would yield 2 MSS). I am confused. I thought all the numbers in RFC3390 are based on MSS, not MTU, so it's 3.33x, # of bytes as well as segments. "Equivalently, the upper bound for the initial window size is based on the MSS, as follows: If (MSS <= 1095 bytes) then win <= 4 * MSS; If (1095 bytes < MSS < 2190 bytes) then win <= 4380; If (2190 bytes <= MSS) then win <= 2 * MSS; " So IW=10 may not have been as aggressive as you might have thought. Will that be enough to swing your vote :)? > > The arguments in favor appear to be based on the 99% - or even 99.5% - case, > and too much focused on current (and, IMO, likely ephemeral) transfer size > measurements. I prefer to consider the increased variety of links and uses > and trade safety for over-optimizing performance. draft-ietf-tcpm-initcwnd-01.txt already contains the following paragraph: "8. Mitigation of Negative Impact Much of the negative impact from an increase in the initial window is likely to be felt by users behind slow links with limited buffers. The negative impact can be mitigated by hosts directly connected to a low-speed link advertising a smaller initial receive window than 10 segments. This can be achieved either through manual configuration by the users, or through the host stack auto-detecting the low bandwidth links. More suggestions to improve the end-to-end performance of slow links can be found in RFC 3150 [RFC3150]. " It the above is the only road block to standard we can certainly try to expand on it. > > I personally would be more comfortable with doubling the numbers from RFC > 3390, i.e., "4 segments or 8760 bytes whichever is smaller", as well as > adding "SHOULD round down to an even number of segments" (to avoid creating > compressed ACK stalls). Again it should be "6 segments or 8760 bytes whichever is smaller". Jerry > >>> Question 3: Adaptive solution as an alternative? >>> >>> Answer 3A: Adoption of draft-touch-tcpm-automatic-iw-01 as WG item >>> heading towards experimental >>> Answer 3B: No adoption >> >> I favor 3A, sort-of. I would rather see it generalized to explain how >> the same algorithm can be used for tuning SCTP and potentially a subset >> of CCIDs for DCCP. Otherwise we're begging someone to write more >> documents later in order to tell us how the same thing applies to those >> other protocols. > > +1 on all points (FWIW, it was always intended to apply across all AIMD > congestion control scenarios). > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From touch@isi.edu Wed Jul 13 15:46:28 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E96611E8075 for ; Wed, 13 Jul 2011 15:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.411 X-Spam-Level: X-Spam-Status: No, score=-103.411 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miDAh1e98os3 for ; Wed, 13 Jul 2011 15:46:28 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECE311E81C4 for ; Wed, 13 Jul 2011 15:46:28 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p6DMkEfQ005116 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 13 Jul 2011 15:46:14 -0700 (PDT) Message-ID: <4E1E2036.3000504@isi.edu> Date: Wed, 13 Jul 2011 15:46:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Jerry Chu References: <133D9897FB9C5E4E9DF2779DC91E947C0654B57A@SLFSNX.rcs.alcatel-research.de> <4E1CEC6C.7030607@mti-systems.com> <4E1E084F.6000000@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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] Request for input regarding the initial window increase X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 22:46:28 -0000 Hi, Jerry, On 7/13/2011 2:52 PM, Jerry Chu wrote: > Hi Joe, > > On Wed, Jul 13, 2011 at 2:04 PM, Joe Touch wrote: ... >>>> Question 2: Maximum permitted initial congestion window? >>>> >>>> Answer 2A: 10 MSS for an MTU of 1500 byte as suggested by >>>> draft-ietf-tcpm-initcwnd-01 (other MTUs are still TBD) >>>> Answer 2B: Another value (please suggest and justify) >>> >>> I think 2A is appropriate due to the volume of analysis that used the >>> same value (10MSS). Anything greater hasn't been looked at as much, >>> and anything lesser sacrifices the intent. >> >> I think it should mirror how it was stated previously: M segments OR N >> bytes, whichever is *smaller*. >> >> As to the M and N, there is clearly a goal of 10 1500-byte packets (15,000 >> bytes). Compared to RFC 3390, that's 3.4x more bytes *and* 5x more segments >> (at 1500 bytes, 3390 would yield 2 MSS). > > I am confused. I thought all the numbers in RFC3390 are based on MSS, not > MTU, so it's 3.33x, # of bytes as well as segments. I was assuming that 3390 corrected for an odd number of segments (which - you are correct, of course - it does not). So in the 1500-byte MTU case, 3390 results in an odd number of segments, resulting in an ACK compression stall. ;-( ... > So IW=10 may not have been as aggressive as you might have thought. Will that > be enough to swing your vote :)? Still 3.33x vs. 2x. I prefer 2x. >> The arguments in favor appear to be based on the 99% - or even 99.5% - case, >> and too much focused on current (and, IMO, likely ephemeral) transfer size >> measurements. I prefer to consider the increased variety of links and uses >> and trade safety for over-optimizing performance. > > draft-ietf-tcpm-initcwnd-01.txt already contains the following paragraph: > "8. Mitigation of Negative Impact > > Much of the negative impact from an increase in the initial window is > likely to be felt by users behind slow links with limited buffers. > The negative impact can be mitigated by hosts directly connected to a > low-speed link advertising a smaller initial receive window than 10 > segments. This can be achieved either through manual configuration by > the users, or through the host stack auto-detecting the low bandwidth > links. > > More suggestions to improve the end-to-end performance of slow links > can be found in RFC 3150 [RFC3150]. > " > > It the above is the only road block to standard we can certainly try to expand > on it. It would be preferable, IMO, to have users behind fast links be the ones that required manual configuration to get better performance, rather than expecting the have-nots to do manual configuration to avoid being punished. >> I personally would be more comfortable with doubling the numbers from RFC >> 3390, i.e., "4 segments or 8760 bytes whichever is smaller", as well as >> adding "SHOULD round down to an even number of segments" (to avoid creating >> compressed ACK stalls). > > Again it should be "6 segments or 8760 bytes whichever is smaller". RFC 3390 says: (1) min (4*MSS, max (2*MSS, 4380 bytes)) So it should be (or at least I would prefer): (2) min (8*MSS, max (4*MSS, 8760 bytes)) This will result in 6 segments for the 1500-byte MTU case anyway. *IF* this is stated in terms of the current proposal, it should be more like the following: (3) min (10*MSS, 14600 bytes) However, again, I prefer the more conservative version (2) above. Joe From Michael.Scharf@alcatel-lucent.com Thu Jul 14 02:09:03 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6350421F8ABD; Thu, 14 Jul 2011 02:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3BP3hzLaM6X; Thu, 14 Jul 2011 02:09:02 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBD721F8A7E; Thu, 14 Jul 2011 02:08:59 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p6E98vDh006112; Thu, 14 Jul 2011 11:08:57 +0200 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, 14 Jul 2011 11:08:56 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0654B62C@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 81 TCPM draft agenda Thread-Index: AcxCBaj5dKAhB8juRKeTH8PCVYlDWw== From: "SCHARF, Michael" To: "TCP Maintenance and Minor Extensions WG" X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Cc: tcpm-chairs@ietf.org Subject: [tcpm] IETF 81 TCPM draft agenda X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 09:09:03 -0000 Dear all, I uploaded a draft agenda for the TCPM meeting in Quebec City according to the requests that I received so far: http://www.ietf.org/proceedings/81/agenda/tcpm.txt Unlike in the last meeting, we still have quite some spare time. Please let me know if I should have missed something, or if there are suggestions for further agenda items. Thanks! Michael From Michael.Tuexen@lurchi.franken.de Thu Jul 14 03:05:41 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCD721F86F4 for ; Thu, 14 Jul 2011 03:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VkyB9F4BWiu for ; Thu, 14 Jul 2011 03:05:41 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 83B9021F855B for ; Thu, 14 Jul 2011 03:05:40 -0700 (PDT) Received: from [IPv6:2001:638:506:21:224:36ff:feef:67d1] (unknown [IPv6:2001:638:506:21:224:36ff:feef:67d1]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id D1DBC1C0C0BD9; Thu, 14 Jul 2011 12:05:37 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <4E1CEC6C.7030607@mti-systems.com> Date: Thu, 14 Jul 2011 12:05:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <22AF3C11-3973-430D-BE3D-C4B452F5E6F3@lurchi.franken.de> References: <133D9897FB9C5E4E9DF2779DC91E947C0654B57A@SLFSNX.rcs.alcatel-research.de> <4E1CEC6C.7030607@mti-systems.com> To: Wesley Eddy X-Mailer: Apple Mail (2.1084) Cc: tcpm@ietf.org Subject: Re: [tcpm] Request for input regarding the initial window increase X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 10:05:41 -0000 On Jul 13, 2011, at 2:53 AM, Wesley Eddy wrote: > My personal responses as a WG participant are below: >=20 > On 7/12/2011 7:54 PM, SCHARF, Michael wrote: >>=20 >> ... >>=20 >> Question 1: Moving forward a fixed increase of the permitted TCP = initial >> congestion window (draft-ietf-tcpm-initcwnd-01)? >>=20 >> Answer 1A: Fixed upper limit to proposed standard >> Answer 2B: Fixed upper limit to experimental >> Answer 3C: Something else (e. g., some adaptive scheme, or no change = at >> all compared to RFC 3390); this would imply a substantial change of >> draft-ietf-tcpm-initcwnd-01 >=20 > I think B (Experimental) is a conservative approach. I'm happy with > that and scoping the "experiment" for general use on the Internet, = with > intent to come back and go to Proposed Standard at some point. > Essentially, it already has close to that status ;). >=20 >=20 >> Question 2: Maximum permitted initial congestion window? >>=20 >> Answer 2A: 10 MSS for an MTU of 1500 byte as suggested by >> draft-ietf-tcpm-initcwnd-01 (other MTUs are still TBD) >> Answer 2B: Another value (please suggest and justify) >=20 > I think 2A is appropriate due to the volume of analysis that used the > same value (10MSS). Anything greater hasn't been looked at as much, > and anything lesser sacrifices the intent. >=20 >=20 >> Question 3: Adaptive solution as an alternative? >>=20 >> Answer 3A: Adoption of draft-touch-tcpm-automatic-iw-01 as WG item >> heading towards experimental >> Answer 3B: No adoption >=20 >=20 > I favor 3A, sort-of. I would rather see it generalized to explain how = the same algorithm can be used for tuning SCTP and potentially a subset = of CCIDs for DCCP. Otherwise we're begging someone to write more > documents later in order to tell us how the same thing applies to = those > other protocols. I really would like to see the document covering TCP, SCTP, and DCCP. = The problem covers all transports having a TCP related CC, not only TCP. Best regards Michael >=20 > --=20 > Wes Eddy > MTI Systems > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From Michael.Scharf@alcatel-lucent.com Sun Jul 17 17:48:15 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA31121F893C for ; Sun, 17 Jul 2011 17:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.203 X-Spam-Level: X-Spam-Status: No, score=-6.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heDX4Vp7dBXB for ; Sun, 17 Jul 2011 17:48:15 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 1366D21F8915 for ; Sun, 17 Jul 2011 17:48:14 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p6I0mDQe018017 for ; Mon, 18 Jul 2011 02:48:13 +0200 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: Mon, 18 Jul 2011 02:48:10 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0654B72A@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for draft-ietf-tcpm-rfc3782-bis-02 Thread-Index: AcxE30Q8Xnk5mhX4Sl2ijPOGvE99yw== From: "SCHARF, Michael" To: "TCP Maintenance and Minor Extensions WG" X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Subject: [tcpm] WGLC for draft-ietf-tcpm-rfc3782-bis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 00:48:15 -0000 Dear all, we have the following charter milestone: Apr 2011 - Submit document updating the NewReno RFC 3782 to the IESG for publication as Proposed Standard Recently there have been no comments on draft-ietf-tcpm-rfc3782-bis, and the authors have no plans for further revisions. Therefore, this email begins a Working Group Last Call on draft-ietf-tcpm-rfc3782-bis-02 to close on August 5. As discussed at the IETF 80, the document is planned to go to Proposed Standard. Best regards Michael From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Jul 20 07:08:35 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD1421F86E8 for ; Wed, 20 Jul 2011 07:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.665 X-Spam-Level: X-Spam-Status: No, score=-0.665 tagged_above=-999 required=5 tests=[AWL=-1.316, BAYES_50=0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PTz3M3CGXRQ for ; Wed, 20 Jul 2011 07:08:35 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id DCA3B21F86BE for ; Wed, 20 Jul 2011 07:08:34 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id B4C60633B1; Wed, 20 Jul 2011 16:08:32 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id A458F59A8A; Wed, 20 Jul 2011 16:08:32 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: tcpm@ietf.org, "Scharf, Michael" Date: Wed, 20 Jul 2011 16:08:31 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <133D9897FB9C5E4E9DF2779DC91E947C0654B57A@SLFSNX.rcs.alcatel-research.de> <4E1CEC6C.7030607@mti-systems.com> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Disposition: inline Message-Id: <201107201608.31930.mkuehle@ikr.uni-stuttgart.de> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Request for input regarding the initial window increase X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 14:08:35 -0000 Hi Jerry, first of all, sorry I'm late to response here... please see inline. > Yes and our "very large" ;-) experiment with IW=10 has been ongoing for > more than a year. I wonder how much more experiment is required for 1A, > which is my preference, unless you have IW > 10 in mind. > > BTW, with Linux adopting IW=10 a few month back, the "experiment" has > been getting even larger everyday. Okay, there have been large scale experiments with IW=10 but did you do any experiments on any other value? Maybe 9 or 11 is much better, but we never recognized..? Mirja From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Jul 20 07:10:16 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4504421F89BA for ; Wed, 20 Jul 2011 07:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_40=-0.185, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2BEAAnPjOWQ for ; Wed, 20 Jul 2011 07:10:15 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id A93D921F88DD for ; Wed, 20 Jul 2011 07:10:15 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 0694C633B2; Wed, 20 Jul 2011 16:10:01 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id EBAC159A8A; Wed, 20 Jul 2011 16:10:00 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: tcpm@ietf.org Date: Wed, 20 Jul 2011 16:10:00 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <133D9897FB9C5E4E9DF2779DC91E947C0654B57A@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C0654B57A@SLFSNX.rcs.alcatel-research.de> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201107201610.00237.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [tcpm] Request for input regarding the initial window increase X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 14:10:16 -0000 Hi again, to sum up, here my option to the questions below > Question 1: Moving forward a fixed increase of the permitted TCP initial > congestion window (draft-ietf-tcpm-initcwnd-01)? > > Answer 1A: Fixed upper limit to proposed standard > Answer 2B: Fixed upper limit to experimental > Answer 3C: Something else (e. g., some adaptive scheme, or no change at > all compared to RFC 3390); this would imply a substantial change of > draft-ietf-tcpm-initcwnd-01 2B > Question 2: Maximum permitted initial congestion window? > > Answer 2A: 10 MSS for an MTU of 1500 byte as suggested by > draft-ietf-tcpm-initcwnd-01 (other MTUs are still TBD) > Answer 2B: Another value (please suggest and justify) 2B, all least there should be done some investigation on other values than 10 before we go for 10 > Question 3: Adaptive solution as an alternative? > > Answer 3A: Adoption of draft-touch-tcpm-automatic-iw-01 as WG item > heading towards experimental > Answer 3B: No adoption I guess 3B, mostly the senders which send a lot of data are servers of a company. Those servers can be changed more or less easily... But I don't think there should be a fixed value for all flow which is not changeable. I guess there should be a socket option or something like this. Such that the application could change the IW for certain transmissions. Mirja From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Jul 20 07:10:16 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A9F21F88DD for ; Wed, 20 Jul 2011 07:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[AWL=-0.856, BAYES_40=-0.185, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZKNF7lIq6Mu for ; Wed, 20 Jul 2011 07:10:16 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 921DB21F87D9 for ; Wed, 20 Jul 2011 07:10:15 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 61E85633B1; Wed, 20 Jul 2011 16:09:55 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 5534759A8A; Wed, 20 Jul 2011 16:09:55 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: tcpm@ietf.org, "Scharf, Michael" Date: Wed, 20 Jul 2011 16:09:54 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <133D9897FB9C5E4E9DF2779DC91E947C0654B57A@SLFSNX.rcs.alcatel-research.de> <4E1D9742.607@mti-systems.com> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Disposition: inline Message-Id: <201107201609.54694.mirja.kuehlewind@ikr.uni-stuttgart.de> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Request for input regarding the initial window increase X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 14:10:16 -0000 Hi again, > Second, to participate in the experiment the OSes running on the > endhosts must support a larger IW to begin with. Without a Standard status > I wonder how many OSes (with the exception of Linux) will provide the > support; and if the support is indeed added but requires some complex > configuration steps to turn it on, then I wonder how much of real > participation it may draw. The initial (sending) window needs only needs to be changed at sender side, which usually is a server under control of a large company. If you mean that the initial receive window needs to be increased as well, that's true. But that's a different story. I'm happy to increase the initial receiver window (if the access link of the receiver is large enough), even on standard track. That does not mean we have to increase the initial sending window in the same standard doc as well. I would see the IW increase as experimental as well. Furthermore I would not make a general recommendation for ever transmission. For large flow there is basically no speed-up when increasing the window from 3 to 10. So why to risk to loss more packets or disturb other flows...? An IW of 10 gives most benefit to flow with have about 10 packets (if the link is large enough and not overly full)... Mirja From hkchu@google.com Wed Jul 20 10:15:30 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494B521F8640 for ; Wed, 20 Jul 2011 10:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.676 X-Spam-Level: X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42EraaLPru9T for ; Wed, 20 Jul 2011 10:15:29 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 522F321F863E for ; Wed, 20 Jul 2011 10:15:29 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p6KHFRXc018427 for ; Wed, 20 Jul 2011 10:15:27 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311182127; bh=ATDBw6Ky8eK5meJL3KEifFsXolc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=OWJ/RCWua/vWW+MS9Q25DXZEzSCgJbqzw51225nuT2cl04j62B6z2LrcYS/i1q+OH Uwpqpz1SP57DPet9cv5rg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=Ra5xNeHBB7JHDef4cI8ik4ojzJILtx0/hWrkOiX5K0KhVxcc19yHS3OU5o88xtAhZ ztKe0O44uB5LEsMhxSqrQ== Received: from ywt2 (ywt2.prod.google.com [10.192.20.2]) by hpaq2.eem.corp.google.com with ESMTP id p6KHF1TW002921 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 20 Jul 2011 10:15:25 -0700 Received: by ywt2 with SMTP id 2so220900ywt.30 for ; Wed, 20 Jul 2011 10:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Dcg+POs4GSr4fnIEI25IhjSlXBcuowOsnM0VPG54iCI=; b=iqjBTLuhUzHuiO9DF/wFInOT07d8rveeLRe7grHHPtJMYtsV0sa348yRWJ3wCQ3Eir jVViF2S5FF6LdD6Fu6rA== MIME-Version: 1.0 Received: by 10.150.202.7 with SMTP id z7mr4851134ybf.237.1311182125462; Wed, 20 Jul 2011 10:15:25 -0700 (PDT) Received: by 10.150.226.20 with HTTP; Wed, 20 Jul 2011 10:15:25 -0700 (PDT) In-Reply-To: <201107201608.31930.mkuehle@ikr.uni-stuttgart.de> References: <133D9897FB9C5E4E9DF2779DC91E947C0654B57A@SLFSNX.rcs.alcatel-research.de> <4E1CEC6C.7030607@mti-systems.com> <201107201608.31930.mkuehle@ikr.uni-stuttgart.de> Date: Wed, 20 Jul 2011 10:15:25 -0700 Message-ID: From: Jerry Chu To: =?ISO-8859-1?Q?Mirja_K=FChlewind?= Content-Type: multipart/alternative; boundary=000e0cd4865ad2f67204a8836076 X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] Request for input regarding the initial window increase X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 17:15:30 -0000 --000e0cd4865ad2f67204a8836076 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2011 at 7:08 AM, Mirja K=FChlewind < mirja.kuehlewind@ikr.uni-stuttgart.de> wrote: > Hi Jerry, > > first of all, sorry I'm late to response here... please see inline. > > > Yes and our "very large" ;-) experiment with IW=3D10 has been ongoing f= or > > more than a year. I wonder how much more experiment is required for 1A, > > which is my preference, unless you have IW > 10 in mind. > > > > BTW, with Linux adopting IW=3D10 a few month back, the "experiment" has > > been getting even larger everyday. > Okay, there have been large scale experiments with IW=3D10 but did you do= any > experiments on any other value? Maybe 9 or 11 is much better, but we neve= r > recognized..? > First an even number is much preferred to avoid delayed ack. Second, we did try different IW values. See our SIGCOMM CCR paper "An Argument for Increasing TCP's Initial Congestion Window", Figure 2. Fro= m our experiments IW16 seems to the optimal value but we decided to be conservative and picked 10. Jerry > > Mirja > --000e0cd4865ad2f67204a8836076 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2011 at 7:08 AM, Mirja K=FChlewind <mirja.kuehlewind@ikr= .uni-stuttgart.de> wrote:
Hi Jerry,

first of all, sorry I'm late to response here... please see inline.

> Yes and our "very large" ;-) experiment with IW=3D10 has bee= n ongoing for
> more than a year. I wonder how much more experiment is required for 1A= ,
> which is my preference, unless you have IW > 10 in mind.
>
> BTW, with Linux adopting IW=3D10 a few month back, the "experimen= t" has
> been getting even larger everyday.
Okay, there have been large scale experiments with IW=3D10 but did yo= u do any
experiments on any other value? Maybe 9 or 11 is much better, but we never<= br> recognized..?

First an even number is m= uch preferred to avoid delayed ack. Second, we did try
different = IW values. See our SIGCOMM CCR paper
"An Argument for Increa= sing TCP's Initial Congestion Window", Figure 2. From
our experiments IW16 seems to the optimal value but we decided to be c= onservative
and picked 10.

Jerry
=A0

Mirja

--000e0cd4865ad2f67204a8836076-- From hkchu@google.com Wed Jul 20 10:41:15 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B0521F8576 for ; Wed, 20 Jul 2011 10:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.676 X-Spam-Level: X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sv6JqjRnOmDF for ; Wed, 20 Jul 2011 10:41:14 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 74B0321F856A for ; Wed, 20 Jul 2011 10:41:14 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p6KHfDic022213 for ; Wed, 20 Jul 2011 10:41:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311183673; bh=VZybNc8xzO3yXgln3xMAuksMjiE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=RmSS3AstSjiaB9c9TOz/NbPYzGKbdaK5ZiBDTi1vx2iR6db3TrpPffiK/j4KxJMkx EiOwwwx9E+Wadt5iEJmCQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=Ggbr1Cn7YEEDcUqwr2pwnDWIwHqMPTZ+GMRVF5/goulKYvXdpXdBaPVedawt6ODz7 pURP8D69ce62z6wvC6VeA== Received: from ywt2 (ywt2.prod.google.com [10.192.20.2]) by hpaq2.eem.corp.google.com with ESMTP id p6KHeZtw000405 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 20 Jul 2011 10:41:12 -0700 Received: by ywt2 with SMTP id 2so290877ywt.16 for ; Wed, 20 Jul 2011 10:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G59FHlSgwy66krpzXU1X9yc9cMAHrGvfU+9MC60wRZg=; b=bf7cpUGSyWpxcEzsSlC+rk5n+esXA8gthkw4McCe+jzRIknGpVOWNoG14lNzEUDtRg 7+7bBNKp1XkHo8WT/Njg== MIME-Version: 1.0 Received: by 10.150.236.3 with SMTP id j3mr8315668ybh.294.1311182895469; Wed, 20 Jul 2011 10:28:15 -0700 (PDT) Received: by 10.150.226.20 with HTTP; Wed, 20 Jul 2011 10:28:15 -0700 (PDT) In-Reply-To: <201107201609.54694.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <133D9897FB9C5E4E9DF2779DC91E947C0654B57A@SLFSNX.rcs.alcatel-research.de> <4E1D9742.607@mti-systems.com> <201107201609.54694.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Wed, 20 Jul 2011 10:28:15 -0700 Message-ID: From: Jerry Chu To: Mirja Kuehlewind Content-Type: multipart/alternative; boundary=000e0cd290f8b854ee04a8838ed2 X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] Request for input regarding the initial window increase X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 17:41:15 -0000 --000e0cd290f8b854ee04a8838ed2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 20, 2011 at 7:09 AM, Mirja Kuehlewind < mirja.kuehlewind@ikr.uni-stuttgart.de> wrote: > Hi again, > > > Second, to participate in the experiment the OSes running on the > > endhosts must support a larger IW to begin with. Without a Standard > status > > I wonder how many OSes (with the exception of Linux) will provide the > > support; and if the support is indeed added but requires some complex > > configuration steps to turn it on, then I wonder how much of real > > participation it may draw. > The initial (sending) window needs only needs to be changed at sender side, > which usually is a server under control of a large company. > If you mean that the initial receive window needs to be increased as well, > that's true. But that's a different story. I'm happy to increase the > initial > receiver window (if the access link of the receiver is large enough), even > on > standard track. That does not mean we have to increase the initial sending > window in the same standard doc as well. > No, what I meant is some OSes hardwire IW3 in their code. Others require some configuration steps to change IW. Without a standard status it may be difficult to enable more IW10 experiment, a chicken&egg problem. > I would see the IW increase as experimental as well. Furthermore I would > not > make a general recommendation for ever transmission. For large flow there > is > basically no speed-up when increasing the window from 3 to 10. So why to > risk What's the risk here for large flows? The startup period is very small compared to the lifetime of the connection so whatever IW value is, the benefit is negligible and the impact is negligible too. Jerry > to loss more packets or disturb other flows...? An IW of 10 gives most > benefit > to flow with have about 10 packets (if the link is large enough and not > overly full)... > > Mirja > --000e0cd290f8b854ee04a8838ed2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2011 at 7:09 AM, Mirja Kuehlewind <mirja.kuehlewind@ikr.= uni-stuttgart.de> wrote:
Hi again,

> Second, to participate in the experiment the OSes running on the
> endhosts must support a larger IW to begin with. Without a Standard st= atus
> I wonder how many OSes (with the exception of Linux) will provide the<= br> > support; and if the support is indeed added but requires some complex<= br> > configuration steps to turn it on, then I wonder how much of real
> participation it may draw.
The initial (sending) window needs only needs to be changed at sender= side,
which usually is a server under control of a large company.
If you mean that the initial receive window needs to be increased as well,<= br> that's true. But that's a different story. I'm happy to increas= e the initial
receiver window (if the access link of the receiver is large enough), even = on
standard track. That does not mean we have to increase the initial sending<= br> window in the same standard doc as well.

No, what I meant is some OSes hardwire IW3 in their code. Others require = some
configuration steps to change IW. Without a standard status = it may be difficult to
enable more IW10 experiment, a chicken&egg problem.

=

I would see the IW increase as experimental as well. Furthermore I would no= t
make a general recommendation for ever transmission. For large flow there i= s
basically no speed-up when increasing the window from 3 to 10. So why to ri= sk

What's the risk here for large flows= ? The startup period is very small compared to
the lifetime of th= e connection so whatever IW value is, the benefit is negligible
and the impact is negligible too.

Jerry
=
=A0
=A0
to loss more packets or disturb other flows...? An IW of 10 gives most bene= fit
to flow with have about 10 packets (if the link is large enough and not
overly full)...

Mirja

--000e0cd290f8b854ee04a8838ed2-- From hkchu@google.com Wed Jul 20 13:15:19 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C8821F84FD for ; Wed, 20 Jul 2011 13:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.902 X-Spam-Level: X-Spam-Status: No, score=-105.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwgGjRYlGjmn for ; Wed, 20 Jul 2011 13:15:16 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 994A821F8A4D for ; Wed, 20 Jul 2011 13:15:15 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p6KKFEO8004345 for ; Wed, 20 Jul 2011 13:15:14 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311192914; bh=Pfk2Ze/1ETvR/+rgPsLXXo9wMY4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=GQqYowp2Gq0sIOvBoYeaxfi2uOFL9QCB/m1jnu+mRGh5RcEtztHJXUQuYEQSSuvbT bgh2y8DqG9nZQjIP59LdQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=s69kZZY3KoyoALxvxqrsnGIVQ4RV7+f7xnLa/VhDLOqXP/rnRjrZnG5nVI+1Crzj9 rQ+vsgLEVYeIDvjtZ44sw== Received: from yie19 (yie19.prod.google.com [10.243.66.19]) by hpaq12.eem.corp.google.com with ESMTP id p6KKF8fX007730 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 20 Jul 2011 13:15:13 -0700 Received: by yie19 with SMTP id 19so446365yie.11 for ; Wed, 20 Jul 2011 13:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=uJhvuRoW6sR7xYYtDRybLglJpPmQr95TG8pUDY4GM9U=; b=aXbwqkq3w2IKwckmQc8irPWFhRQto2P3mKAYLvEG2FAkG6dmM+YMPLuFhyKdB/m6Fl YjmZNTnTo37hIEYdqdsA== MIME-Version: 1.0 Received: by 10.150.202.7 with SMTP id z7mr5059600ybf.237.1311192913209; Wed, 20 Jul 2011 13:15:13 -0700 (PDT) Received: by 10.150.226.20 with HTTP; Wed, 20 Jul 2011 13:15:12 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Jul 2011 13:15:12 -0700 Message-ID: From: Jerry Chu To: "tcpm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: David Borman Subject: Re: [tcpm] upcoming consensus call on IW10 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 20:15:20 -0000 Just want to correct the perception by some folks that IW10 has only been studied/tested on Google's properties. The large experiment we have conducted over the past yeas is not the only one that convinced us IW10 should become a standard. There have been numerous other studies of the effect of IW10 on 1) slow or highly multiplexed links, 2) mobile/wirele= ss network, 3) the fairness question. All results show the negative impact of IW10 to be very limited, e.g., some slow links under very heavy load (which perform poorly even under IW3), or some wireless link types under certain traffic pattern. The link below contains all the test results: http://code.google.com/speed/protocols/tcpm-IW10.html Note the can always find some cases and show IW10 hurts. The key question is, how bad it is and how prevailing the case is. I'm sure there were negative impacts when IW was increased from 1 to 3 a decade ago but that didn't stop IW3 from becoming a standard. I believe we have done sufficient due-diligence, equal or more than what was done when IW3 was standardized. So it's about time for us to make IW10 a standard and move on (e.g., to work on something else more interesting like auto scale IW). Thanks, Jerry On Mon, Jun 6, 2011 at 4:53 AM, Jerry Chu wrote: > > Folks, > > It's been a while since our last IW related discussion/debate, and > it's getting close for the WG to decide on the status of our IW10 > proposal at the upcoming meeting in Quebec City. To get ready for > a consensus call, we have produced a major revision of the draft to > include all the up-to-date information for your peruse below. > > We believe our IW10 proposal is ready for standardization now, > considering the following facts: > > 1. We have been experimenting with IW10 in a very large scale for > more than 9 months by now, and have observed its positive performance > impact consistently with no issue reported so far. > > 2. We have conducted a number of testbed studies to address concerns, > mainly on IW10's impact on slow links or other flows with smaller > IW. All the results show little or no negative impact from IW10, with > the only exception being some extreme overload cases where both IW10 > and IW3 perform terribly. The full testbed results can be found at > http://research.csc.ncsu.edu/netsrv/?q=3Dcontent/iw10 > > 3. An informal poll by Mark Allman early this year seemed to show > the majority of people responding to the poll favored a simple, > static increase of IW right away. > > 4. The latest Linux kernel has adopted 10 as the default initial > congestion window size. > > Once again, we believe a modest, static increase of IW to 10 is the > best, simplest, timely solution to a serious web performance problem > with little downside. We appreciate the value of two other related > proposals by M. Allman and J. Touch respectively, but believe, due > to their complexity (especially the one by Joe), they are best suited > for experiemental (e.g., likely need to refine the suggested formula), > and will best serve to carve out a growh path for IW beyond 10. > > Comments and suggestions on how to move things forward are welcomed. > Also a complete set of IW10 related papers and past presentations > can be found at http://code.google.com/speed/protocols/tcpm-IW10.html > > Best, > > Jerry on behalf of all co-authors > > On Thu, Apr 14, 2011 at 6:00 PM, wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the TCP Maintenance and Minor Extensions W= orking Group of the IETF. > > > > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Increasing TCP's Initial Win= dow > > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : J. Chu, et al. > > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-tcpm-initcwnd-01.tx= t > > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 20 > > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-04-14 > > > > This document proposes an increase in the permitted TCP initial > > window (IW) from between 2 and 4 segments, as specified in RFC 3390, > > to 10 segments. It discusses the motivation behind the increase, the > > advantages and disadvantages of the higher initial window, and > > presents results from several large scale experiments showing that > > the higher initial window improves the overall performance of many > > web services without risking congestion collapse. The document closes > > with a discussion of a list of concerns, and some results from recent > > studies to address the concerns. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-initcwnd-01.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. > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > From michawe@ifi.uio.no Wed Jul 20 13:56:38 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CEB21F8AA8 for ; Wed, 20 Jul 2011 13:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG+Z3ira+acC for ; Wed, 20 Jul 2011 13:56:34 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6C821F8681 for ; Wed, 20 Jul 2011 13:56:33 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Qjdol-0003eN-8R for tcpm@ietf.org; Wed, 20 Jul 2011 22:56:31 +0200 Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.199]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.76) (envelope-from ) id 1Qjdok-0007N1-JJ for tcpm@ietf.org; Wed, 20 Jul 2011 22:56:31 +0200 Message-Id: <47C8B0CD-014C-467E-B71C-86A400E92C03@ifi.uio.no> From: Michael Welzl To: tcpm 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 v936) Date: Wed, 20 Jul 2011 22:56:08 +0200 References: X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 4 sum rcpts/h 8 sum msgs/h 6 total rcpts 11110 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 129A35835335425B1B4A25034900982362B44BD7 X-UiO-SPAM-Test: remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 1539 max/h 18 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [tcpm] upcoming consensus call on IW10 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 20:56:38 -0000 I agree. On Jul 20, 2011, at 10:15 PM, Jerry Chu wrote: > Just want to correct the perception by some folks that IW10 has only > been studied/tested on Google's properties. The large experiment we > have > conducted over the past yeas is not the only one that convinced us > IW10 > should become a standard. There have been numerous other studies of > the effect of IW10 on 1) slow or highly multiplexed links, 2) mobile/ > wireless > network, 3) the fairness question. All results show the negative > impact of > IW10 to be very limited, e.g., some slow links under very heavy load > (which > perform poorly even under IW3), or some wireless link types under > certain > traffic pattern. > > The link below contains all the test results: > http://code.google.com/speed/protocols/tcpm-IW10.html > > Note the can always find some cases and show IW10 hurts. The key > question is, how bad it is and how prevailing the case is. I'm sure > there > were negative impacts when IW was increased from 1 to 3 a decade ago > but that didn't stop IW3 from becoming a standard. > > I believe we have done sufficient due-diligence, equal or more than > what > was done when IW3 was standardized. So it's about time for us to make > IW10 a standard and move on (e.g., to work on something else more > interesting like auto scale IW). > > Thanks, > > Jerry > > On Mon, Jun 6, 2011 at 4:53 AM, Jerry Chu wrote: >> >> Folks, >> >> It's been a while since our last IW related discussion/debate, and >> it's getting close for the WG to decide on the status of our IW10 >> proposal at the upcoming meeting in Quebec City. To get ready for >> a consensus call, we have produced a major revision of the draft to >> include all the up-to-date information for your peruse below. >> >> We believe our IW10 proposal is ready for standardization now, >> considering the following facts: >> >> 1. We have been experimenting with IW10 in a very large scale for >> more than 9 months by now, and have observed its positive performance >> impact consistently with no issue reported so far. >> >> 2. We have conducted a number of testbed studies to address concerns, >> mainly on IW10's impact on slow links or other flows with smaller >> IW. All the results show little or no negative impact from IW10, with >> the only exception being some extreme overload cases where both IW10 >> and IW3 perform terribly. The full testbed results can be found at >> http://research.csc.ncsu.edu/netsrv/?q=content/iw10 >> >> 3. An informal poll by Mark Allman early this year seemed to show >> the majority of people responding to the poll favored a simple, >> static increase of IW right away. >> >> 4. The latest Linux kernel has adopted 10 as the default initial >> congestion window size. >> >> Once again, we believe a modest, static increase of IW to 10 is the >> best, simplest, timely solution to a serious web performance problem >> with little downside. We appreciate the value of two other related >> proposals by M. Allman and J. Touch respectively, but believe, due >> to their complexity (especially the one by Joe), they are best suited >> for experiemental (e.g., likely need to refine the suggested >> formula), >> and will best serve to carve out a growh path for IW beyond 10. >> >> Comments and suggestions on how to move things forward are welcomed. >> Also a complete set of IW10 related papers and past presentations >> can be found at http://code.google.com/speed/protocols/tcpm-IW10.html >> >> Best, >> >> Jerry on behalf of all co-authors >> >> On Thu, Apr 14, 2011 at 6:00 PM, wrote: >>> >>> 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 : Increasing TCP's Initial Window >>> Author(s) : J. Chu, et al. >>> Filename : draft-ietf-tcpm-initcwnd-01.txt >>> Pages : 20 >>> Date : 2011-04-14 >>> >>> This document proposes an increase in the permitted TCP initial >>> window (IW) from between 2 and 4 segments, as specified in RFC 3390, >>> to 10 segments. It discusses the motivation behind the increase, the >>> advantages and disadvantages of the higher initial window, and >>> presents results from several large scale experiments showing that >>> the higher initial window improves the overall performance of many >>> web services without risking congestion collapse. The document >>> closes >>> with a discussion of a list of concerns, and some results from >>> recent >>> studies to address the concerns. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-initcwnd-01.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. >>> >>> >>> _______________________________________________ >>> 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 rs@netapp.com Thu Jul 21 01:22:32 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786AF21F8B60 for ; Thu, 21 Jul 2011 01:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvtllULUxofG for ; Thu, 21 Jul 2011 01:22:31 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by ietfa.amsl.com (Postfix) with ESMTP id 91B8D21F85E3 for ; Thu, 21 Jul 2011 01:22:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.67,240,1309762800"; d="scan'208";a="263681971" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 21 Jul 2011 01:22:29 -0700 Received: from ldcrsexc2-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p6L8MSXX004221; Thu, 21 Jul 2011 01:22:29 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jul 2011 09:22:28 +0100 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 Jul 2011 09:21:53 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0F572964@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <47C8B0CD-014C-467E-B71C-86A400E92C03@ifi.uio.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] upcoming consensus call on IW10 Thread-Index: AcxHH7bWfrzfh/SMSIW3KTQ7lfnnigAX0vJg References: <47C8B0CD-014C-467E-B71C-86A400E92C03@ifi.uio.no> From: "Scheffenegger, Richard" To: "tcpm" X-OriginalArrivalTime: 21 Jul 2011 08:22:28.0958 (UTC) FILETIME=[546A67E0:01CC477F] Subject: Re: [tcpm] upcoming consensus call on IW10 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 08:22:32 -0000 I also support StdTrack for IW10. Richard Scheffenegger > -----Original Message----- > From: Michael Welzl [mailto:michawe@ifi.uio.no] > Sent: Mittwoch, 20. Juli 2011 22:56 > To: tcpm=09 > Subject: Re: [tcpm] upcoming consensus call on IW10 >=20 > I agree. >=20 >=20 > On Jul 20, 2011, at 10:15 PM, Jerry Chu wrote: >=20 > > Just want to correct the perception by some folks that IW10 has only > > been studied/tested on Google's properties. The large experiment we > > have > > conducted over the past yeas is not the only one that convinced us > > IW10 > > should become a standard. There have been numerous other studies of > > the effect of IW10 on 1) slow or highly multiplexed links, 2) mobile/ > > wireless > > network, 3) the fairness question. All results show the negative > > impact of > > IW10 to be very limited, e.g., some slow links under very heavy load > > (which > > perform poorly even under IW3), or some wireless link types under > > certain > > traffic pattern. > > > > The link below contains all the test results: > > http://code.google.com/speed/protocols/tcpm-IW10.html > > > > Note the can always find some cases and show IW10 hurts. The key > > question is, how bad it is and how prevailing the case is. I'm sure > > there > > were negative impacts when IW was increased from 1 to 3 a decade ago > > but that didn't stop IW3 from becoming a standard. > > > > I believe we have done sufficient due-diligence, equal or more than > > what > > was done when IW3 was standardized. So it's about time for us to make > > IW10 a standard and move on (e.g., to work on something else more > > interesting like auto scale IW). > > > > Thanks, > > > > Jerry > > > > On Mon, Jun 6, 2011 at 4:53 AM, Jerry Chu wrote: > >> > >> Folks, > >> > >> It's been a while since our last IW related discussion/debate, and > >> it's getting close for the WG to decide on the status of our IW10 > >> proposal at the upcoming meeting in Quebec City. To get ready for > >> a consensus call, we have produced a major revision of the draft to > >> include all the up-to-date information for your peruse below. > >> > >> We believe our IW10 proposal is ready for standardization now, > >> considering the following facts: > >> > >> 1. We have been experimenting with IW10 in a very large scale for > >> more than 9 months by now, and have observed its positive > performance > >> impact consistently with no issue reported so far. > >> > >> 2. We have conducted a number of testbed studies to address > concerns, > >> mainly on IW10's impact on slow links or other flows with smaller > >> IW. All the results show little or no negative impact from IW10, > with > >> the only exception being some extreme overload cases where both IW10 > >> and IW3 perform terribly. The full testbed results can be found at > >> http://research.csc.ncsu.edu/netsrv/?q=3Dcontent/iw10 > >> > >> 3. An informal poll by Mark Allman early this year seemed to show > >> the majority of people responding to the poll favored a simple, > >> static increase of IW right away. > >> > >> 4. The latest Linux kernel has adopted 10 as the default initial > >> congestion window size. > >> > >> Once again, we believe a modest, static increase of IW to 10 is the > >> best, simplest, timely solution to a serious web performance problem > >> with little downside. We appreciate the value of two other related > >> proposals by M. Allman and J. Touch respectively, but believe, due > >> to their complexity (especially the one by Joe), they are best > suited > >> for experiemental (e.g., likely need to refine the suggested > >> formula), > >> and will best serve to carve out a growh path for IW beyond 10. > >> > >> Comments and suggestions on how to move things forward are welcomed. > >> Also a complete set of IW10 related papers and past presentations > >> can be found at http://code.google.com/speed/protocols/tcpm- > IW10.html > >> > >> Best, > >> > >> Jerry on behalf of all co-authors > >> > >> On Thu, Apr 14, 2011 at 6:00 PM, wrote: > >>> > >>> 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 : Increasing TCP's Initial Window > >>> Author(s) : J. Chu, et al. > >>> Filename : draft-ietf-tcpm-initcwnd-01.txt > >>> Pages : 20 > >>> Date : 2011-04-14 > >>> > >>> This document proposes an increase in the permitted TCP initial > >>> window (IW) from between 2 and 4 segments, as specified in RFC > 3390, > >>> to 10 segments. It discusses the motivation behind the increase, > the > >>> advantages and disadvantages of the higher initial window, and > >>> presents results from several large scale experiments showing that > >>> the higher initial window improves the overall performance of many > >>> web services without risking congestion collapse. The document > >>> closes > >>> with a discussion of a list of concerns, and some results from > >>> recent > >>> studies to address the concerns. > >>> > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-initcwnd-01.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. > >>> > >>> > >>> _______________________________________________ > >>> 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 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From mirja.kuehlewind@ikr.uni-stuttgart.de Thu Jul 21 01:54:45 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D04921F8BA3 for ; Thu, 21 Jul 2011 01:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXvDZ+pEGcvU for ; Thu, 21 Jul 2011 01:54:45 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2B521F8BA1 for ; Thu, 21 Jul 2011 01:54:44 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 40704633B2; Thu, 21 Jul 2011 10:54:40 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 2A5BA59A8A; Thu, 21 Jul 2011 10:54:40 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: Jerry Chu Date: Thu, 21 Jul 2011 10:54:39 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <133D9897FB9C5E4E9DF2779DC91E947C0654B57A@SLFSNX.rcs.alcatel-research.de> <201107201608.31930.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201107211054.39474.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: tcpm@ietf.org Subject: Re: [tcpm] Request for input regarding the initial window increase X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 08:54:45 -0000 Hi jerry, see inline... On Wednesday 20 July 2011 19:15:25 Jerry Chu wrote: > On Wed, Jul 20, 2011 at 7:08 AM, Mirja K=FChlewind < > > mirja.kuehlewind@ikr.uni-stuttgart.de> wrote: > > Hi Jerry, > > > > first of all, sorry I'm late to response here... please see inline. > > > > > Yes and our "very large" ;-) experiment with IW=3D10 has been ongoing= for > > > more than a year. I wonder how much more experiment is required for 1= A, > > > which is my preference, unless you have IW > 10 in mind. > > > > > > BTW, with Linux adopting IW=3D10 a few month back, the "experiment" h= as > > > been getting even larger everyday. > > > > Okay, there have been large scale experiments with IW=3D10 but did you = do > > any experiments on any other value? Maybe 9 or 11 is much better, but we > > never recognized..? > > First an even number is much preferred to avoid delayed ack. Second, we d= id > try > different IW values. See our SIGCOMM CCR paper > "An Argument for Increasing TCP's Initial Congestion Window", Figure 2. > From our experiments IW16 seems to the optimal value but we decided to be > conservative > and picked 10. I only took a brief look at the paper (will read it more deeply later on). = As=20 far as I understand the IW of 16 seems to be the best fit for Google search= =2E=20 Which makes sense because a Google search response has usually less than 16= =20 packets and thus all data can be transmitted at once.=20 A student of mine is doing some investigation about the IW. For now I would= =20 say that the right value depends very much on the traffic characteristic/fl= ow=20 size and also on the scenario we are looking at e.g. buffersizes.=20 I believe that IW of 10 is a very good value for Google search responses (= in=20 most scenarios). But I would wanne recommend IW of 10 for every kind of=20 transmission in very scenario in a standard. Mirja From mallman@icir.org Thu Jul 21 05:20:28 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D1821F8B3A for ; Thu, 21 Jul 2011 05:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BioUhsXgjwLP for ; Thu, 21 Jul 2011 05:20:27 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id E343B21F8B47 for ; Thu, 21 Jul 2011 05:20:27 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p6LCKOVN019919; Thu, 21 Jul 2011 05:20:24 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6360644F0C68; Thu, 21 Jul 2011 08:20:24 -0400 (EDT) To: Mirja Kuehlewind From: Mark Allman In-Reply-To: <201107211054.39474.mirja.kuehlewind@ikr.uni-stuttgart.de> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Car Phone MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma6533-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 21 Jul 2011 08:20:24 -0400 Sender: mallman@icir.org Message-Id: <20110721122024.6360644F0C68@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] Request for input regarding the initial window increase X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jul 2011 12:20:28 -0000 ----------ma6533-1 Content-Type: text/plain Content-Disposition: inline > A student of mine is doing some investigation about the IW. For now I > would say that the right value depends very much on the traffic > characteristic/flow size and also on the scenario we are looking at > e.g. buffersizes. I think it is **well understood** that the "right value" depends on many things and changes over time. > I believe that IW of 10 is a very good value for Google search > responses (in most scenarios). But I would wanne recommend IW of 10 > for every kind of transmission in very scenario in a standard. I can't parse this. Two things: - The spec doesn't say everyone *has* to use an IW of 10. It says you can use an IW up to 10. If you find that 7 works best for you, use it. You're always free to be more conservative. - There is no global "optimal" IW. One network might find 10 works best, another 15, another 8, etc. TCP's cwnd adapts to observed network conditions. The IW is just a place to start. We'd like that place to start to work and not cause problems in the vast majority of the cases. But, given the heterogeneous nature of the network there is no global optimal. This issue has been studied a whole bunch. The IETF proceedings are full of presentations. Those presentations point to reports and papers. We do not have complete knowledge here. We never will. There is always "one more study" that can be done. At some point we have to decide that the marginal utility of another study is low and so we don't need to wait any longer. IMHO. allman ----------ma6533-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk4oGYgACgkQWyrrWs4yIs6p4ACfeMFeOOIGcXEyjrbqv48O70qr HBcAn2wgIUYXdBBGqe/KNC84c28q+AAo =V2Ud -----END PGP SIGNATURE----- ----------ma6533-1-- From Michael.Scharf@alcatel-lucent.com Mon Jul 25 14:19:40 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B969C21F84E7 for ; Mon, 25 Jul 2011 14:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YsXV5Jx-YxT for ; Mon, 25 Jul 2011 14:19:40 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id DE0C721F84DF for ; Mon, 25 Jul 2011 14:19:39 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p6PLJcGw031207 for ; Mon, 25 Jul 2011 23:19:38 +0200 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: Mon, 25 Jul 2011 23:19:36 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0654BA90@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG status on July 25, 2011 Thread-Index: AcxLEI5Eo4yaufXOT/m6eIv+U3i+QA== From: "SCHARF, Michael" To: "TCP Maintenance and Minor Extensions WG" X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Subject: [tcpm] WG status on July 25, 2011 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 21:19:40 -0000 Hello, below is a snapshot of TCPM status from the chairs prior to the IETF 81 meeting. As usual, we may have made mistakes, so please correct us, if needed. We have an ongoing WGLC for draft-ietf-tcpm-rfc3782-bis, which hasn't triggered any feedback so far. Please have a look at that draft. Please also note that the authors of draft-mathis-tcpm-proportional-rate-reduction and draft-touch-tcpm-automatic-iw ask for WG adaption. The chairs plan to ask for feedback on that in tomorrow's meeting. Thanks! Michael and David (TCPM co-chairs) Recent RFCs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC 6093 - On the Implementation of the TCP Urgent Mechanism (January 2011) RFC 6191 - Reducing the TIME-WAIT State Using TCP Timestamps (April 2011) RFC 6247 - Moving the Undeployed TCP Extensions RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1379, RFC1644 and RFC1693 to Historic Status=20 (May 2011) RFC 6298 - Computing TCP's Retransmission Timer (June 2011) =20 WG Items Nearing RFC Publication =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Clarification of sender behavior in persist condition=20 draft-ietf-tcpm-persist Milestone Target: Informational Status: Revised ID needed after IESG evaluation WG Items in WGLC or being revised after WGLC =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MSS Option draft-ietf-tcpm-tcpmss Milestone Target: Proposed Standard in July 2009 Status: Action with David Borman 1948bis draft-ietf-tcpm-rfc1948bis Milestone Target: Proposed Standard until September 2011 Status: WGLC completed Action: Next step is PROTO writeup The NewReno Modification to TCP's Fast Recovery Algorithm draft-ietf-tcpm-rfc3782-bis Milestone Target: Proposed Standard in April 2011 Status: Ongoing WGLC Action: WGLC until August 5, 2011 Active WG Items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1323bis draft-ietf-tcpm-1323bis Milestone Target: Proposed Standard in July 2009 Status: Needs revision Action: Revise & WGLC (action with David Borman) TCP Security draft-ietf-tcpm-tcp-security Milestone Target: BCP in August 2010 Status: Content needs work, draft expired Action: Action with author to address review comments SACK Entry / RFC 3517bis draft-blanton-tcpm-3517bis Milestone Target: Proposed Standard in October 2010 Status: Probably ready for WGLC Action: WGLC soon? Increasing the Initial Window draft-ietf-tcpm-initcwnd Milestone Target: August 2011 to determine intended status September 2011 to publish document Status: Under active discussion / review Action: Determine intended status Documents Under a Poll to Become WG Items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Proportional Rate Reduction for TCP draft-mathis-tcpm-proportional-rate-reduction Status: Presented at IETF 80, discussion on the list Action: WG adoption? Automating the Initial Window in TCP draft-touch-tcpm-automatic-iw Status: Discussion on the list Action: WG adoption? Active Internet-Drafts =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D draft-allman-tcpm-rto-consider draft-cheng-tcpm-fastopen draft-fairhurst-tcpm-newcwv draft-nishida-tcpm-rescue-retransmission draft-scheffenegger-tcpm-timestamp-negotiation draft-yourtchenko-tcp-loic (+ many expired Internet-Drafts) From Michael.Scharf@alcatel-lucent.com Wed Jul 27 09:52:22 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D05021F8B0E for ; Wed, 27 Jul 2011 09:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.214 X-Spam-Level: X-Spam-Status: No, score=-6.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdIK5Rh6zvuG for ; Wed, 27 Jul 2011 09:52:22 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id AAB7B21F8515 for ; Wed, 27 Jul 2011 09:52:21 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p6RGqKET005997 for ; Wed, 27 Jul 2011 18:52:20 +0200 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: Wed, 27 Jul 2011 18:52:17 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0654BBCD@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG adoption of draft-mathis-tcpm-proportional-rate-reduction-01 Thread-Index: AcxMfYsnRiD35StKTKysXoGRQHKUgA== From: "SCHARF, Michael" To: "TCP Maintenance and Minor Extensions WG" X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Subject: [tcpm] WG adoption of draft-mathis-tcpm-proportional-rate-reduction-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jul 2011 16:52:22 -0000 Dear all, the sense of the room in yesterday's TCPM meeting was to adopt draft-mathis-tcpm-proportional-rate-reduction-01 as WG item, heading towards experimental. I'd like to verify on the mailing list that this is the WG consensus. If you have concerns that this draft should not be adopted, please speak up in the next two weeks. Thanks Michael From Michael.Scharf@alcatel-lucent.com Wed Jul 27 10:01:30 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D3721F8BBB for ; Wed, 27 Jul 2011 10:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vA+lKXSd2xOE for ; Wed, 27 Jul 2011 10:01:29 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 833D621F8BBA for ; Wed, 27 Jul 2011 10:01:29 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p6RH1SiC006643 for ; Wed, 27 Jul 2011 19:01:28 +0200 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: Wed, 27 Jul 2011 19:01:25 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0654BBCE@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for feedback on WG adoption of draft-cheng-tcpm-fastopen-00 Thread-Index: AcxMftHhRh6TGMezQ/qhSNavyXljYA== From: "SCHARF, Michael" To: "TCP Maintenance and Minor Extensions WG" X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Subject: [tcpm] Request for feedback on WG adoption of draft-cheng-tcpm-fastopen-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jul 2011 17:01:30 -0000 Dear all, in yesterday's TCPM meeting there was some support for WG adoption of draft-cheng-tcpm-fastopen-00, heading towards experimental. In order to determine the WG consensus, the chairs ask for additional feedback on that draft. Please provide feedback whether you find this draft useful or not, and whether you think that it should become a WG item. Also, please let us know if there should be technical issues that are not addressed so far by the draft and that would require further discussion or analysis. Thanks Michael From william.allen.simpson@gmail.com Sun Jul 31 17:59:11 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E0921F87D3 for ; Sun, 31 Jul 2011 17:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.312 X-Spam-Level: X-Spam-Status: No, score=-3.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoNTRv1qFB4t for ; Sun, 31 Jul 2011 17:59:11 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0768721F87C7 for ; Sun, 31 Jul 2011 17:59:10 -0700 (PDT) Received: by iye7 with SMTP id 7so7485747iye.31 for ; Sun, 31 Jul 2011 17:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=TRXSibnHNxJ1rKJ69tGMJPQrn9cao9DWTmVijjT1Ouk=; b=Z+nTNyTdaZ55FRsM07z2teG0TrzYnQUttSNmppSzYRJymKl/c4o4++/SycahrFtiI9 he3JLw6kPgHuaYMRMUbtiCQyEXanrTdQIUF5VqAoIwhFr+YkXzf08L49uW0Ds6OLhO0+ 2TL+Zdmc9YwocLFXSAu9o9YjX02CVOLLYNszs= Received: by 10.231.21.15 with SMTP id h15mr2546768ibb.76.1312160355711; Sun, 31 Jul 2011 17:59:15 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id c2sm3005956ibd.22.2011.07.31.17.59.14 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 31 Jul 2011 17:59:14 -0700 (PDT) Message-ID: <4E35FA61.4070109@gmail.com> Date: Sun, 31 Jul 2011 20:59:13 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: tcpm@ietf.org References: <133D9897FB9C5E4E9DF2779DC91E947C0654BBCD@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C0654BBCD@SLFSNX.rcs.alcatel-research.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] WG adoption of draft-mathis-tcpm-proportional-rate-reduction-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2011 00:59:11 -0000 Listening remotely to the WG meeting, it sounded interesting. I haven't had a chance to actually study the draft yet, but downloaded it during the meeting and skimmed it. I don't understand why 2 algorithms would be required to be implemented, not sufficient information in a fairly wordy document. Still, seems exactly the kind of thing this WG does. +1 From william.allen.simpson@gmail.com Sun Jul 31 18:10:57 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEBE21F8588 for ; Sun, 31 Jul 2011 18:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.369 X-Spam-Level: X-Spam-Status: No, score=-3.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dO4xnVJ6twUR for ; Sun, 31 Jul 2011 18:10:56 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC5A21F856A for ; Sun, 31 Jul 2011 18:10:56 -0700 (PDT) Received: by iye7 with SMTP id 7so7496448iye.31 for ; Sun, 31 Jul 2011 18:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=h7NvpEPc1Xt9nSAi1sHaH3S+RDzsidMrEDekIyglDUw=; b=k+r8NeWVJaHvIiugz80XyTxdZh3cRib54uff7zYrnl7vCBeEQuTYJX6Q0/Tt8BaTc8 CQN+ct98uapBYfMAAu3LQKuyXsPPOSFDT2sTw8sejUtUmHZjxhRyLBWgwqP5qrra1/o/ OUfOY38D3hONhVfvF/hPKYbtx4CHCLbiXoF/Q= Received: by 10.231.92.196 with SMTP id s4mr2640751ibm.10.1312161061237; Sun, 31 Jul 2011 18:11:01 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id vj5sm6037950icb.11.2011.07.31.18.10.59 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 31 Jul 2011 18:11:00 -0700 (PDT) Message-ID: <4E35FD22.50006@gmail.com> Date: Sun, 31 Jul 2011 21:10:58 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: TCP Maintenance and Minor Extensions WG References: <133D9897FB9C5E4E9DF2779DC91E947C0654BBCE@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C0654BBCE@SLFSNX.rcs.alcatel-research.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Request for feedback on WG adoption of draft-cheng-tcpm-fastopen-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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 Aug 2011 01:10:57 -0000 On 7/27/11 1:01 PM, SCHARF, Michael wrote: > In order to determine the WG consensus, the chairs ask for additional > feedback on that draft. Please provide feedback whether you find this > draft useful or not, and whether you think that it should become a WG > item. > Please note that I've previously stated that this is a really bad idea! I was so irritated by this idea that I publicly posted an alternative (that had been privately baking for some time). It was forwarded to be published as Experimental some time ago -- still awaiting IESG review. I don't know how/why this was reconsidered at yet another meeting, as there were no updates fixing anything that was raised previously. Most conferences (or working groups) don't allow multiple presentations of the same paper. > Also, please let us know if there should be technical issues that are > not addressed so far by the draft and that would require further > discussion or analysis. > I could re-post my objections again, but really it boils down to: 1) insecure, demonstrates very poor knowledge of security principles. 2) doesn't work with commonly deployed middleboxen, degrades badly.