From rs@netapp.com Sun Aug 1 05:16:51 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80843A6B64 for ; Sun, 1 Aug 2010 05:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[AWL=-0.858, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJMJPIav0igg for ; Sun, 1 Aug 2010 05:16:50 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 6E1E83A6B04 for ; Sun, 1 Aug 2010 05:16:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,297,1278313200"; d="scan'208";a="194548521" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 01 Aug 2010 05:17:16 -0700 Received: from amsrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o71CGIug015919; Sun, 1 Aug 2010 05:16:33 -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); Sun, 1 Aug 2010 14:16:18 +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: Sun, 1 Aug 2010 13:14:18 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A09C48990@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Increasing TCP's Initial Congestion Window Thread-Index: AcsuZ9fhyIGPAvf4TNya4gZPk3DChQDCRMtQ References: From: "Scheffenegger, Richard" To: "Nandita Dukkipati" , "Matthew Mathis" X-OriginalArrivalTime: 01 Aug 2010 12:16:18.0761 (UTC) FILETIME=[5898F390:01CB3173] Cc: Arvind Jain , tcpm@ietf.org, David Borman Subject: Re: [tcpm] Increasing TCP's Initial Congestion Window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2010 12:16:52 -0000 Hi Nandita, Matt, =20 As mentioned in the session of ICCRG WG (and to not loose this item from discussion here at TCPM): I think it would be good, to break out the results you have gathered so far (flow completion time in high percentiles, across multiple regions) also into SACK vs non-SACK flows. Furthermore, as you explained, IW10 (IW16) has only been verified in your DC with a SACK-enabled sender, which follows Matt's original intention of using SACK information to recover from lost retransmissions. No other stack (that I'm familiar with; opensolaris, {free,open,net}bsd, windows, aix, hpux, is currently doing that, afaik). My concern here is, that an umbrella recommendation without any strong remarks about that fact, will led to implementatiors of other stacks to increase the IW accordingly. However, the ensuing burst loss will probably cancel out any gains due to the possibility of fast recovery. (This is why I would like to see the flow-competion time for non-SACK flows broken out from your numbers). Don't understand me wrong here - I feel absolutely positive that SACK enabled stacks should be encouraged to make use of the information contained within SACK, to recover fast from lost retransmissions, and that most stacks should nowadays always use SACK. However, the Linux Stack is the only one which is currently doing this (even though there are simple means by which any SACK stack could be enabled to gain much of the functionality without the fancy scoreboard implementation of Linux; I think, even the lwIP SACK patch could be made to do that under a majority of cases). Perhaps you should write a seperate draft on that aspect, to extend RFC2018... Richard Scheffenegger=20 From lastewart@swin.edu.au Tue Aug 3 01:19:28 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04B8D3A67DA; Tue, 3 Aug 2010 01:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dozcjAP4mxzb; Tue, 3 Aug 2010 01:19:24 -0700 (PDT) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by core3.amsl.com (Postfix) with ESMTP id 209613A6767; Tue, 3 Aug 2010 01:19:23 -0700 (PDT) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 3A0727E8CE; Tue, 3 Aug 2010 18:19:50 +1000 (EST) Message-ID: <4C57D125.3010706@swin.edu.au> Date: Tue, 03 Aug 2010 18:19:49 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100726 Thunderbird/3.0.6 MIME-Version: 1.0 To: iccrg@cs.ucl.ac.uk, end2end-interest@postel.org, freebsd-net@freebsd.org, tmrg-interest@ICSI.Berkeley.EDU, ledbat@ietf.org, multipathtcp@ietf.org, tcpm@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: David Hayes , grenville armitage Subject: [tcpm] Software for FreeBSD TCP R&D X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 08:19:28 -0000 Hi all, (apologies for any duplicates you receive and please trim the CC list appropriately if you reply to this email) We're pleased to announce the release of a substantial set of new and updated BSD licenced software for TCP experimentation and research using FreeBSD: - "CAIA-Hamilton Delay" Congestion Control Algorithm v0.1 (new) - "Hamilton Delay" Congestion Control Algorithm v0.2 (update) - Vegas Congestion Control Algorithm v0.2 (update) - H-TCP Congestion Control Algorithm v0.12 (update) - CUBIC Congestion Control Algorithm v0.10 (update) - Statistical Information For TCP Research (SIFTR) v1.2.3 (update) - Enhanced Round Trip Time (ERTT) Khelp Module v0.2 (update) - Khelp Framework for FreeBSD v0.1.1 (update) - Modular TCP Congestion Control for FreeBSD v0.10.0 (update) A more detailed summary of the various tools/patches is included at the end of this email. Everything mentioned above along with other papers, patches and software relevant/useful for protocol analysis, debugging and experimental research is available from: http://caia.swin.edu.au/urp/newtcp/tools.html The software was developed as part of the NewTCP research project at Swinburne University's Centre for Advanced Internet Architectures, made possible in part by a grant from the Cisco University Research Program Fund at Community Foundation Silicon Valley. Testing and development was further assisted by a grant from the FreeBSD Foundation. We welcome any feedback and hope you enjoy playing with the code and tools. Cheers, Lawrence Stewart, David Hayes and Grenville Armitage http://caia.swin.edu.au NB: "CAIA-Hamilton Delay" and "Hamilton Delay" are our working names for algorithms which do not have established names in the literature. "CAIA-Hamilton Delay" Congestion Control Algorithm v0.1 [1,2] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements an experimental delay based congestion control algorithm proposed by the Hamilton Institute [3] but with modifications made by CAIA [4]. It builds on Hamilton's initial proposal by adding tolerance to non-congestion related losses and still aims to allow delay- and loss-based algorithms to fairly coexist. "Hamilton Delay" Congestion Control Algorithm v0.2 [5,6] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements an experimental delay based congestion control algorithm proposed by the Hamilton Institute [3]. It provides a first step toward the ability of delay based algorithms to fairly coexist with loss based algorithms. Vegas Congestion Control Algorithm v0.2 [7,8] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements the Vegas delay-based congestion control algorithm [9]. H-TCP Congestion Control Algorithm v0.12 [10,11] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements the H-TCP loss based TCP congestion control algorithm [12]. CUBIC Congestion Control Algorithm v0.10 [13,14] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements the CUBIC loss based TCP congestion control algorithm [15]. CUBIC is the current default algorithm used by Linux. Statistical Information For TCP Research (SIFTR) v1.2.3 [16,17] ---------------------------------------------------------------------- A FreeBSD 6/7/8/9 kernel module that logs a range of statistics on active TCP connections to a log file. It provides the ability to make highly granular measurements of TCP connection state, aimed at system administrators, developers and researchers. NB: SIFTR has been imported into FreeBSD's "head" svn branch (a.k.a. 9-CURRENT) as revision 209662 and will be backported to 8-STABLE in time for 8.2-RELEASE. Enhanced Round Trip Time (ERTT) Khelp Module v0.2 [18,19] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that provides enhanced RTT measurements for use by delay and rate based TCP congestion control algorithms. Robust estimates of RTT are provided even when the receiver uses delayed acknowledgements, TCP segmentation offload (TSO) or Selective Acknowledgements (SACK). This module is required by the delay based congestion control algorithms. Khelp Framework for FreeBSD v0.1.1 [20,21] ---------------------------------------------------------------------- A FreeBSD kernel patch that provides support for generic kernel modules known as "helpers" to hook into arbitrary points within the kernel and provide service(s) to the running system. This forms the foundation for the ERTT Khelp module. Modular TCP Congestion Control for FreeBSD v0.10.0 [22,23] ------------------------------------------------- This revision of the modular TCP congestion control framework patch provides a current snapshot of the project's development branch. Some fairly major changes and refactoring have gone into this release, along with numerous tweaks, bug fixes and enhancements to support the new delay based congestion control algorithms we have been working on. In theory, the framework now also supports sharing of congestion control algorithms between congestion aware transport protocols like TCP and SCTP, though this integration work is yet to be done. [1] http://caia.swin.edu.au/urp/newtcp/tools/cc_chd-0.1.tar.gz [2] http://caia.swin.edu.au/urp/newtcp/tools/cc_chd-readme-0.1.txt [3] L. Budzisz, R. Stanojevic, R. Shorten, and F. Baker, "A strategy for fair coexistence of loss and delay-based congestion control algorithms", IEEE Commun. Lett., vol. 13, no. 7, pp. 555-557, Jul. 2009. [4] D. A. Hayes and G. Armitage, "Improved coexistence and loss tolerance for delay based TCP congestion control", in Proceedings of 35th Annual IEEE Conference on Local Computer Networks (LCN 2010), Denver, Colorado, USA, 11-14 October 2010. [5] http://caia.swin.edu.au/urp/newtcp/tools/cc_hd-0.2.tar.gz [6] http://caia.swin.edu.au/urp/newtcp/tools/cc_hd-readme-0.2.txt [7] http://caia.swin.edu.au/urp/newtcp/tools/cc_vegas-0.2.tar.gz [8] http://caia.swin.edu.au/urp/newtcp/tools/cc_vegas-readme-0.2.txt [9] L. S. Brakmo and L. L. Peterson, "TCP Vegas: end to end congestion avoidance on a global internet", IEEE J. Sel. Areas Commun., vol. 13, no. 8, pp. 1465-1480, Oct. 1995. [10] http://caia.swin.edu.au/urp/newtcp/tools/cc_htcp-0.12.tar.gz [11] http://caia.swin.edu.au/urp/newtcp/tools/cc_htcp-readme-0.12.txt [12] D. Leith, R. Shorten, "H-TCP: TCP for high-speed and long-distance networks", in Second International Workshop on Protocols for Fast Long-Distance Networks, Argonne, Illinois USA, February 2004. [13] http://caia.swin.edu.au/urp/newtcp/tools/cc_cubic-0.10.tar.gz [14] http://caia.swin.edu.au/urp/newtcp/tools/cc_cubic-readme-0.10.txt [15] I. Rhee, L. Xu, S. Ha, "CUBIC for Fast Long-Distance Networks", Internet Draft, draft-rhee-tcpm-cubic-02.txt, August 2008. [16] http://caia.swin.edu.au/urp/newtcp/tools/siftr-1.2.3.tar.gz [17] http://caia.swin.edu.au/urp/newtcp/tools/siftr-readme-1.2.3.txt [18] http://caia.swin.edu.au/urp/newtcp/tools/h_ertt-0.2.tar.gz [19] http://caia.swin.edu.au/urp/newtcp/tools/h_ertt-readme-0.2.txt [20] http://caia.swin.edu.au/urp/newtcp/tools/caia_khelp_framework_v0.1.1_9.x.r209905.patch [21] http://caia.swin.edu.au/urp/newtcp/tools/khelp-readme-0.1.1.txt [22] http://caia.swin.edu.au/urp/newtcp/tools/caia_modularcc_v0.10.0_9.x.r209905.patch [23] http://caia.swin.edu.au/urp/newtcp/tools/modularcc-readme-0.10.0.txt From mattmathis@google.com Wed Aug 4 13:39:27 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84453A68E1 for ; Wed, 4 Aug 2010 13:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.922 X-Spam-Level: X-Spam-Status: No, score=-103.922 tagged_above=-999 required=5 tests=[AWL=2.056, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v--pYWQaBmnY for ; Wed, 4 Aug 2010 13:39:24 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 381D23A6959 for ; Wed, 4 Aug 2010 13:39:24 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o74KdraI012711 for ; Wed, 4 Aug 2010 13:39:53 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280954393; bh=TOS5Ma0yD/4NeRKQZX5G4YMomwo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=tmrkII7OPoMcTlDNOe8QJhryeLb0XyXcBc3jevw9dx1EniALLlZ8Cpna1bhyrlrSh k1bXKXkNrTGluywTv6qCA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=b8ke36tMaQcSE4uN6nya8JGF66mpbKYM87pT5tjBRmCd5W5E2R0XcvspetHCNDFIn YLXl+oNltQdaX+3uWbmzw== Received: from eydd26 (eydd26.prod.google.com [10.208.30.26]) by wpaz24.hot.corp.google.com with ESMTP id o74KdpmI005974 for ; Wed, 4 Aug 2010 13:39:51 -0700 Received: by eydd26 with SMTP id d26so2498952eyd.12 for ; Wed, 04 Aug 2010 13:39:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.33.73 with SMTP id g9mr7067766ebd.46.1280954391093; Wed, 04 Aug 2010 13:39:51 -0700 (PDT) Received: by 10.213.114.146 with HTTP; Wed, 4 Aug 2010 13:39:51 -0700 (PDT) In-Reply-To: <5FDC413D5FA246468C200652D63E627A09C48990@LDCMVEXC1-PRD.hq.netapp.com> References: <5FDC413D5FA246468C200652D63E627A09C48990@LDCMVEXC1-PRD.hq.netapp.com> Date: Wed, 4 Aug 2010 16:39:51 -0400 Message-ID: From: Matt Mathis To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Arvind Jain , tcpm@ietf.org, David Borman Subject: Re: [tcpm] Increasing TCP's Initial Congestion Window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 20:39:27 -0000 Although I think this is an important point and does need to be followed up, it is actually inverted relative to the question at hand. Content providers who are using non-Linux might find some conditions under which raising IW reduces their performance. If so they have grounds to be more cautious about raising IW. In either case, SACK is (nearly always) work conserving, so the inability to retransmit lost retransmissions is extremely unlikely to cause additional pain for IW3 users (the fairness question). If we had done the experimentation with non-Linux, then the possibility exists that the inability to recover from lost retransmissions would be protecting IW3 users from our traffic, and the results couldn't be trusted to apply to Linux. (I guess this argument does still apply to any other bugs in the Linux TCP recovery code). Thanks, --MM-- On Sun, Aug 1, 2010 at 8:14 AM, Scheffenegger, Richard wrot= e: > Hi Nandita, Matt, > > As mentioned in the session of ICCRG WG (and to not loose this item from > discussion here at TCPM): > > > I think it would be good, to break out the results you have gathered so > far (flow completion time in high percentiles, across multiple regions) > also into SACK vs non-SACK flows. > > Furthermore, as you explained, IW10 (IW16) has only been verified in > your DC with a SACK-enabled sender, which follows Matt's original > intention of using SACK information to recover from lost > retransmissions. No other stack (that I'm familiar with; opensolaris, > {free,open,net}bsd, windows, aix, hpux, is currently doing that, afaik). > > > My concern here is, that an umbrella recommendation without any strong > remarks about that fact, will led to implementatiors of other stacks to > increase the IW accordingly. > > However, the ensuing burst loss will probably cancel out any gains due > to the possibility of fast recovery. (This is why I would like to see > the flow-competion time for non-SACK flows broken out from your > numbers). > > > Don't understand me wrong here - I feel absolutely positive that SACK > enabled stacks should be encouraged to make use of the information > contained within SACK, to recover fast from lost retransmissions, and > that most stacks should nowadays always use SACK. > > However, the Linux Stack is the only one which is currently doing this > (even though there are simple means by which any SACK stack could be > enabled to gain much of the functionality without the fancy scoreboard > implementation of Linux; I think, even the lwIP SACK patch could be made > to do that under a majority of cases). > > Perhaps you should write a seperate draft on that aspect, to extend > RFC2018... > > > Richard Scheffenegger > > --=20 --MM-- The best way to predict the future is to create it. =A0- Peter Drucker From rs@netapp.com Wed Aug 4 16:18:16 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDD7F3A6AB8 for ; Wed, 4 Aug 2010 16:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGSZfugp8+Ug for ; Wed, 4 Aug 2010 16:18:15 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 509AB3A6AB7 for ; Wed, 4 Aug 2010 16:18:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,318,1278313200"; d="scan'208";a="196505775" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 04 Aug 2010 16:18:44 -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 o74NHlQG028106; Wed, 4 Aug 2010 16:18:02 -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, 5 Aug 2010 01:17:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Aug 2010 00:17:45 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A09C49672@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Increasing TCP's Initial Congestion Window Thread-Index: Acs0FUNlMv1mfVkcRiGJJh+O5kmVWgAFFWKw References: <5FDC413D5FA246468C200652D63E627A09C48990@LDCMVEXC1-PRD.hq.netapp.com> From: "Scheffenegger, Richard" To: "Matt Mathis" X-OriginalArrivalTime: 04 Aug 2010 23:17:47.0615 (UTC) FILETIME=[403CB6F0:01CB342B] Cc: Arvind Jain , tcpm@ietf.org, David Borman Subject: Re: [tcpm] Increasing TCP's Initial Congestion Window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 23:18:17 -0000 Hi Matt, I believe the "inability to retransmit lost retransmissions", which is = the current default behavior (except for Linux), DOES permanently cause = every receiver pain in the form of lengthy RTO recoveries and long flow = completion times. And not necessarily only during slow start and the = initial few segments of the flow, but also during steady state, when = some other flow's burst causes this effect for some victim flow. Or, put differently, IW10 may increase that problem (due to a higher = probability of lost retransmissions) over IW3 - and you'd be actually = penalizing IW10 flows (running into RTO) and the this proposal may see = the same fate as ECN deployment. (Due to some broken algorithms/implementations somewhere else, a very = good idea would be blamed). Therefore I would think, had you done your expirimentation with a = "standard" SACK stack, you would have never bothered writing an I-D, as = you wouldn't have seen any merit. At least that is what I would have = expected as the outcome... Thus I would like to see some strong recommendations, or an add-on RFC = to 2018 /5681, to explicitly recommend lost retransmission detected = *before* IW10 is implemented in a stack... (Perhaps you should have been more insistent back then on how to deal = with the wealth of info given by SACK to the sender ;) ). Richard Scheffenegger =20 > -----Original Message----- > From: Matt Mathis [mailto:mattmathis@google.com]=20 > Sent: Mittwoch, 4. August 2010 22:40 > To: Scheffenegger, Richard > Cc: Nandita Dukkipati; tcpm@ietf.org; David Borman; Arvind=20 > Jain; Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] > Subject: Re: [tcpm] Increasing TCP's Initial Congestion Window >=20 > Although I think this is an important point and does need to=20 > be followed up, it is actually inverted relative to the=20 > question at hand. >=20 > Content providers who are using non-Linux might find some=20 > conditions under which raising IW reduces their performance. =20 > If so they have grounds to be more cautious about raising IW.=20 > In either case, SACK is (nearly always) work conserving, so=20 > the inability to retransmit lost retransmissions is extremely=20 > unlikely to cause additional pain for IW3 users (the fairness=20 > question). >=20 > If we had done the experimentation with non-Linux, then the=20 > possibility exists that the inability to recover from lost=20 > retransmissions would be protecting IW3 users from our=20 > traffic, and the results couldn't be trusted to apply to Linux. >=20 > (I guess this argument does still apply to any other bugs in=20 > the Linux TCP recovery code). >=20 > Thanks, > --MM-- >=20 > On Sun, Aug 1, 2010 at 8:14 AM, Scheffenegger, Richard=20 > wrote: > > Hi Nandita, Matt, > > > > As mentioned in the session of ICCRG WG (and to not loose this item=20 > > from discussion here at TCPM): > > > > > > I think it would be good, to break out the results you have=20 > gathered=20 > > so far (flow completion time in high percentiles, across multiple=20 > > regions) also into SACK vs non-SACK flows. > > > > Furthermore, as you explained, IW10 (IW16) has only been=20 > verified in=20 > > your DC with a SACK-enabled sender, which follows Matt's original=20 > > intention of using SACK information to recover from lost=20 > > retransmissions. No other stack (that I'm familiar with;=20 > opensolaris,=20 > > {free,open,net}bsd, windows, aix, hpux, is currently doing=20 > that, afaik). > > > > > > My concern here is, that an umbrella recommendation without=20 > any strong=20 > > remarks about that fact, will led to implementatiors of=20 > other stacks=20 > > to increase the IW accordingly. > > > > However, the ensuing burst loss will probably cancel out=20 > any gains due=20 > > to the possibility of fast recovery. (This is why I would=20 > like to see=20 > > the flow-competion time for non-SACK flows broken out from your=20 > > numbers). > > > > > > Don't understand me wrong here - I feel absolutely positive=20 > that SACK=20 > > enabled stacks should be encouraged to make use of the information=20 > > contained within SACK, to recover fast from lost=20 > retransmissions, and=20 > > that most stacks should nowadays always use SACK. > > > > However, the Linux Stack is the only one which is currently=20 > doing this=20 > > (even though there are simple means by which any SACK stack=20 > could be=20 > > enabled to gain much of the functionality without the fancy=20 > scoreboard=20 > > implementation of Linux; I think, even the lwIP SACK patch could be=20 > > made to do that under a majority of cases). > > > > Perhaps you should write a seperate draft on that aspect, to extend=20 > > RFC2018... > > > > > > Richard Scheffenegger > > > > >=20 >=20 >=20 > -- > --MM-- > The best way to predict the future is to create it. =A0- Peter Drucker >=20 From mattmathis@google.com Wed Aug 4 16:59:03 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B09D3A6AC6 for ; Wed, 4 Aug 2010 16:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.949 X-Spam-Level: X-Spam-Status: No, score=-104.949 tagged_above=-999 required=5 tests=[AWL=1.028, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCBqDaLOliWR for ; Wed, 4 Aug 2010 16:59:02 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 9D3303A696B for ; Wed, 4 Aug 2010 16:59:01 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o74NxU3U029689 for ; Wed, 4 Aug 2010 16:59:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280966371; bh=D87GkG/ifJAc7Lp5ZTc8fbxMVSg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=sOez3dOCjjJV9zJ4MRRS8k+khVFGO9IppmA9maXoKCF2fgVTi3ofasIAUr+P5bV8/ McWRk8rSkqJVA1wcINBcw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=OP0FClIxlW6oyvC5ZmEpAlzR4y3ySK5OJp5HMRTSJPrEOfnYGZzdShqJt0Qb858+J 0nMPhXShl9kGwyR3IDWHg== Received: from eyh6 (eyh6.prod.google.com [10.208.8.6]) by kpbe14.cbf.corp.google.com with ESMTP id o74NxSfm024150 for ; Wed, 4 Aug 2010 16:59:29 -0700 Received: by eyh6 with SMTP id 6so2918587eyh.41 for ; Wed, 04 Aug 2010 16:59:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.27.143 with SMTP id i15mr7194460ebc.62.1280966368519; Wed, 04 Aug 2010 16:59:28 -0700 (PDT) Received: by 10.213.114.146 with HTTP; Wed, 4 Aug 2010 16:59:28 -0700 (PDT) In-Reply-To: <5FDC413D5FA246468C200652D63E627A09C49672@LDCMVEXC1-PRD.hq.netapp.com> References: <5FDC413D5FA246468C200652D63E627A09C48990@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A09C49672@LDCMVEXC1-PRD.hq.netapp.com> Date: Wed, 4 Aug 2010 19:59:28 -0400 Message-ID: From: Matt Mathis To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Arvind Jain , tcpm@ietf.org, David Borman Subject: Re: [tcpm] Increasing TCP's Initial Congestion Window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 23:59:03 -0000 On Wed, Aug 4, 2010 at 7:17 PM, Scheffenegger, Richard wrot= e: > I believe the "inability to retransmit lost retransmissions", which is th= e current default behavior (except for Linux), DOES permanently cause every= receiver pain in the form of lengthy RTO recoveries and long flow completi= on times. And not necessarily only during slow start and the initial few se= gments of the flow, but also during steady state, when some other flow's bu= rst causes this effect for some victim flow. > Point taken, although the WG concern is mostly about what happens to somebody else's flows. Content providers should always regression test new OS rollouts, and if by raising IW they hurt themselves (say because their web page opens 83 concurrent connections), they should fix something. Yes, it is possible with a different stack we would have chosen a different number, and we don't know if the details of the SACK implementation affect our results much. > Or, put differently, IW10 may increase that problem (due to a higher prob= ability of lost retransmissions) over IW3 - and you'd be actually penalizin= g IW10 flows (running into RTO) and the this proposal may see the same fate= as ECN deployment. > It is not the same as ECN at all, because it permits up to IW10 - users (content providers, OS vendors) can choose their own values. There should be a sweet spot at 5 or 6 as well (because Fast Retransmit starts working), which is actually a logical intermediate step for a large content provider or OS vendor who wants to do something, but is extra cautious or otherwise not totally confident of the measurement studies. > (Due to some broken algorithms/implementations somewhere else, a very goo= d idea would be blamed). > > Therefore I would think, had you done your expirimentation with a "standa= rd" SACK stack, you would have never bothered writing an I-D, as you wouldn= 't have seen any merit. At least that is what I would have expected as the = outcome... > > > Thus I would like to see some strong recommendations, or an add-on RFC to= 2018 /5681, to explicitly recommend lost retransmission detected *before* = IW10 is implemented in a stack... > > (Perhaps you should have been more insistent back then on how to deal wit= h the wealth of info given by SACK to the sender ;) ). > I actually abandoned the ID for a reason. Here at Google, I am considering re-opening it. 2581/5681 actually forbid the correct answer, which I could not argue when we dropped the FACK ID. Now I can make a better argument.... It would get ugly because it conflicts with many existing standards. And Fred would not be very happy at all. (Search for mathis congestion control easter egg ) Thanks, --MM-- From mallman@icir.org Thu Aug 12 06:16:48 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E6EC3A686E for ; Thu, 12 Aug 2010 06:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.02 X-Spam-Level: X-Spam-Status: No, score=-105.02 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi2YSo97naNf for ; Thu, 12 Aug 2010 06:16:47 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id F080F3A682A for ; Thu, 12 Aug 2010 06:16:46 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o7CDHNA4004177 for ; Thu, 12 Aug 2010 06:17:23 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 5F20C19BBD5D for ; Thu, 12 Aug 2010 09:17:23 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Lightning Crashes MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma62560-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 12 Aug 2010 09:17:23 -0400 Sender: mallman@icir.org Message-Id: <20100812131723.5F20C19BBD5D@lawyers.icir.org> Subject: [tcpm] reset: seeding RTO in 3WHS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 13:16:48 -0000 ----------ma62560-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- I have just read through the thread on seeding the RTO during the 3WHS when using larger initial windows. The notes I sent a few weeks back still apply in my mind. But, I think there is a big picture issue we need to puzzle through before we consider when to seed the RTO ... Whether we seed in the 3WHS or the first flight of data seems immaterial if we reduce the default initial RTO from 3sec to 1sec (a proposal that is out there in draft-paxson-tcpm-rfc2988bis-00.txt). I.e., regardless of whether you seed in the 3WHS or not the RTO is going to end up in the same place when transmitting the first data segment. So, it seems to me that before we try to puzzle through this seeding business we should figure out if we just want to make the change to the default value. If we do then lets forget this seeding business. If we don't then we can consider whether this seeding in the 3WHS is a good idea or not. My two bits ... allman -- Mark Allman -- ICSI -- http://www.icir.org/mallman/ ----------ma62560-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkxj9GMACgkQWyrrWs4yIs6vvQCbBBlc+wm0ttIqkpvz5ZdiUuxM /OYAnAqfuwmqhaq1+3Z55MM5wt8yUksg =5YcE -----END PGP SIGNATURE----- ----------ma62560-1-- From hkchu@google.com Thu Aug 12 09:15:38 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BE063A67FC for ; Thu, 12 Aug 2010 09:15:38 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5rHzDPZ6PXO for ; Thu, 12 Aug 2010 09:15:37 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id A50263A682A for ; Thu, 12 Aug 2010 09:15:36 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id o7CGGC4r028745 for ; Thu, 12 Aug 2010 09:16:12 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1281629773; bh=gQFVV0iSmsa/QxYm/ua0XS2kFXo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=SEt6rsgjZdvRh6P0BNNjAKdedOUuWM8ym1gb+l3XeQFkI+OGEoACMBvgpbYr0c7vh T2D96k0q/EBmlAFhTAAKA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=ki1B59JeTO0jLCPT9ZMqx6XC/dzN7w22JI2rKICWqx8cEvxHuC+ulc7V2Hy4v3mNi 5hXyQ5X9ph9Ww3it45mYg== Received: from qwa26 (qwa26.prod.google.com [10.241.193.26]) by hpaq1.eem.corp.google.com with ESMTP id o7CGGB7M031598 for ; Thu, 12 Aug 2010 09:16:11 -0700 Received: by qwa26 with SMTP id 26so1839898qwa.23 for ; Thu, 12 Aug 2010 09:16:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.11.9 with SMTP id r9mr113857qar.180.1281629770751; Thu, 12 Aug 2010 09:16:10 -0700 (PDT) Received: by 10.229.92.196 with HTTP; Thu, 12 Aug 2010 09:16:10 -0700 (PDT) In-Reply-To: <20100812131723.5F20C19BBD5D@lawyers.icir.org> References: <20100812131723.5F20C19BBD5D@lawyers.icir.org> Date: Thu, 12 Aug 2010 09:16:10 -0700 Message-ID: From: Jerry Chu To: mallman@icir.org 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] reset: seeding RTO in 3WHS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 16:15:38 -0000 Mark, On Thu, Aug 12, 2010 at 6:17 AM, Mark Allman wrote: > > Folks- > > I have just read through the thread on seeding the RTO during the 3WHS > when using larger initial windows. =A0The notes I sent a few weeks back > still apply in my mind. =A0But, I think there is a big picture issue we > need to puzzle through before we consider when to seed the RTO ... > > Whether we seed in the 3WHS or the first flight of data seems immaterial > if we reduce the default initial RTO from 3sec to 1sec (a proposal that > is out there in draft-paxson-tcpm-rfc2988bis-00.txt). =A0I.e., regardless > of whether you seed in the 3WHS or not the RTO is going to end up in the > same place when transmitting the first data segment. > > So, it seems to me that before we try to puzzle through this seeding > business we should figure out if we just want to make the change to the > default value. =A0If we do then lets forget this seeding business. =A0If = we > don't then we can consider whether this seeding in the 3WHS is a good > idea or not. Agreed 100%. So the question really is if the WG is ready to adopt draft-paxson-tcpm-rfc2988bis-00.txt. I think the only outstanding question = on the initRTO=3D1sec proposal is why not try to reduce minRTO as well and I was asking why the two things need to go together (see my 6/28/10 email). Since you have done some study on the overall impact of minRTO perhaps you can share your thought on this? Thanks, Jerry > > My two bits ... > > allman > > > -- > Mark Allman -- ICSI -- http://www.icir.org/mallman/ > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > From wesley.m.eddy@nasa.gov Thu Aug 12 09:48:02 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A9D43A6934 for ; Thu, 12 Aug 2010 09:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.266 X-Spam-Level: X-Spam-Status: No, score=-106.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlBxmSH3JxhG for ; Thu, 12 Aug 2010 09:48:01 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 0E16E3A67C0 for ; Thu, 12 Aug 2010 09:48:00 -0700 (PDT) Received: from ndjsppt05.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id E07843289E4 for ; Thu, 12 Aug 2010 11:48:37 -0500 (CDT) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt05.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o7CGmbnt023075 for ; Thu, 12 Aug 2010 11:48:37 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Thu, 12 Aug 2010 11:48:37 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Thu, 12 Aug 2010 11:48:36 -0500 Thread-Topic: TCP persist timer min and max values (specified in RFC?) Thread-Index: Acs6M4mEoUquCmIZQg63dL6zCv3ZUAACn2pw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-08-12_09:2010-08-12, 2010-08-12, 1970-01-01 signatures=0 Subject: [tcpm] FW: TCP persist timer min and max values (specified in RFC?) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 16:48:02 -0000 Asked on the IETF main list; kevin is at kfall@cs.berkeley.edu for replies: >-----Original Message----- >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of >Kevin Fall >Sent: Wednesday, August 11, 2010 10:31 PM >To: ietf@ietf.org >Subject: TCP persist timer min and max values (specified in RFC?) > > >Quick and simple question--- > >I'm trying to determine whether the range for the TCP persist timer >([5,60] seconds commonly) is specified by RFC, or instead more of a >historical artifact based on implementation. If it is specified by RFC, >could somebody please point me at it? > >thanks, >- K >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf From mallman@icir.org Thu Aug 12 13:15:18 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C18EB3A68DB for ; Thu, 12 Aug 2010 13:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSFZNS0eiBh0 for ; Thu, 12 Aug 2010 13:15:17 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 947F73A68CF for ; Thu, 12 Aug 2010 13:15:17 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o7CKFpwJ006022; Thu, 12 Aug 2010 13:15:51 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6F09719C5CDE; Thu, 12 Aug 2010 16:15:51 -0400 (EDT) To: Jerry Chu From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Lightning Crashes MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma22134-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 12 Aug 2010 16:15:50 -0400 Sender: mallman@icir.org Message-Id: <20100812201551.6F09719C5CDE@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] reset: seeding RTO in 3WHS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 20:15:18 -0000 ----------ma22134-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Jerry- > I think the only outstanding question on the initRTO=1sec proposal is > why not try to reduce minRTO as well and I was asking why the two > things need to go together (see my 6/28/10 email). > > Since you have done some study on the overall impact of minRTO perhaps > you can share your thought on this? I have done so previously (Feb/2010 and at other times) and just went and grabbed the text. Basically, I think changing the initial RTO (as in our draft) is fine, but the min seems like a much murkier situation to me. So, I'd rather not block on changing the min to see the initial RTO changed. The old text: One problem with the minimum is we don't know what to set it at [*]. The finding in [AP99] is that as you reduce the min you take more spurious timeouts. The tradeoff seemed fundamental to us. But, given our methodology (trace driven simulation) we could not really tell the impact of the spurious timeouts. So, we just sought to minimize them in the spec. I know some TCP implementations are being pretty aggressive with the min these days. But, it is not at all clear to me whether this is a net win or net lose. I.e., is the win in terms of peppiness to needed retransmits still a win when it is played against the consequences of a spurious transmit (i.e., setting cwnd = 1)? Perhaps there is a sweet spot that is < 1sec whereby this tradeoff better balances and we should be using that. But, it'd take a big experiment to show that, I think. [*] Maybe there is work that I just don't know about and if so I'd like to be pointed at it. Also in that Feb email was a wondering I have off-and-on had ... Another thing I have wondered about from time to time .... Much like Early Retransmit could we have some sort of early RTO when the cwnd size is small? When the window size is small it seems that the downside of making a bad rexmt decision is not as bad as when the cwnd is large so it might pay in terms of responsiveness to RTO sooner. Also, as the cwnd gets larger we have better loss recovery techniques that should come into play that can repair lots of loss without involving the RTO and so perhaps by being overly aggressive in the RTO we just hurt ourselves. Finally, as the cwnd gets bigger that means we are transferring more data. And, the longer a connection goes the less important the fine-grained responsiveness matters. Just a random thought ... (Note, I would not advocate that for inclusion in an 2988bis. If there was interest in working this out then that'd seem to me to be something experimental at first.) allman ----------ma22134-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkxkVnYACgkQWyrrWs4yIs7qtgCeIC0eRa+qD01wz0TAC2JOOdQx wtsAn2YGWh1dzYDhhBpiQqTSEygUlW5P =028z -----END PGP SIGNATURE----- ----------ma22134-1-- From alexander.zimmermann@comsys.rwth-aachen.de Fri Aug 13 01:42:24 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2410B3A6993 for ; Fri, 13 Aug 2010 01:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGYzOKPIhfxO for ; Fri, 13 Aug 2010 01:42:23 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 254203A698E for ; Fri, 13 Aug 2010 01:42:23 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L730051M1JNPJ90@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Fri, 13 Aug 2010 10:42:59 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.55,362,1278280800"; d="sig'?scan'208";a="68697836" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Fri, 13 Aug 2010 10:42:59 +0200 Received: from [137.226.12.62] ([unknown] [137.226.12.62]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L73006UF1JNMH10@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Fri, 13 Aug 2010 10:42:59 +0200 (CEST) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-2-586584888 From: Alexander Zimmermann In-reply-to: <20100812201551.6F09719C5CDE@lawyers.icir.org> Date: Fri, 13 Aug 2010 10:42:59 +0200 Content-transfer-encoding: 7bit Message-id: <15B3F34B-5FE6-4B57-8276-076C941FEB34@comsys.rwth-aachen.de> References: <20100812201551.6F09719C5CDE@lawyers.icir.org> To: " Allman" , Jerry Chu X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] reset: seeding RTO in 3WHS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 08:42:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2-586584888 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Jerry, I had the same discussion with Mark a while ago, whether or not ever we should include the reducing minRTO stuff into the 2988bis doc or not. Mark persuaded my that it is better to do not do so in order to not block the doc. However, since feb, nothing is happened... So I think we should decide NOW if the WG would like to adopt the doc as it is (without minRTO adjustment) or not. Alex Am 12.08.2010 um 22:15 schrieb Mark Allman: > > Jerry- > >> I think the only outstanding question on the initRTO=1sec proposal is >> why not try to reduce minRTO as well and I was asking why the two >> things need to go together (see my 6/28/10 email). >> >> Since you have done some study on the overall impact of minRTO perhaps >> you can share your thought on this? > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-2-586584888 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkxlBZMACgkQdyiq39b9uS6HVACff6f8rs78ek3FQkQ55xazC8Sz rAAAoNZaQ64idZTD6hb1HWeOrDmeRMyM =7eFW -----END PGP SIGNATURE----- --Apple-Mail-2-586584888-- From fernando.gont.netbook.win@gmail.com Fri Aug 13 05:47:22 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747A33A6817; Fri, 13 Aug 2010 05:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arpJelYIoy+V; Fri, 13 Aug 2010 05:47:21 -0700 (PDT) Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.213.194]) by core3.amsl.com (Postfix) with ESMTP id 21AEF3A69FB; Fri, 13 Aug 2010 05:47:19 -0700 (PDT) Received: by yxj4 with SMTP id 4so110935yxj.1 for ; Fri, 13 Aug 2010 05:47:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=vFPHtdABY5OHFYBDjNfhR8Zv6wuVgsVtU73xn9CLLa4=; b=oQaQpqGIWEs6roW8riEafBMhuMcsoxQyyq3KO5JYFwoNFEmQtZbXnHgLSiu+w9QF1Y WvbH4eQ+y5vSXo7wGqEHLle97jLu7k2FwZR5l2Z68tldlAd/4uOPt8UqYnYR19SZFAA0 0nBAZqEU5acb0WMlqJTcBoCCkdfpYJdTHuZew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=cEq4BoAhX+GHx7SnpxtD7n4Fwo6I94udjVFOwSoel7/6t5/V7gnv54TUTHzWuMIo3K 7ONNpYXlL+Gz1pLE+NmzIvooKEtFgx743m3yxLOjgShPvvWzz8N/oAYGU9/xYu018Yjq 26pDECexn0cwAypJEdwbMe91LX5kVD3q80WPU= Received: by 10.151.63.23 with SMTP id q23mr1986885ybk.133.1281703675188; Fri, 13 Aug 2010 05:47:55 -0700 (PDT) Received: from [192.168.2.3] ([190.245.181.90]) by mx.google.com with ESMTPS id q25sm2856018ybk.6.2010.08.13.05.47.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Aug 2010 05:47:54 -0700 (PDT) Sender: Fernando Gont Message-ID: <4C653EED.4040501@gont.com.ar> Date: Fri, 13 Aug 2010 09:47:41 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Kevin Fall References: <76A3AD79-4A1E-49E2-A94C-6D0FA915DA93@cs.berkeley.edu> In-Reply-To: <76A3AD79-4A1E-49E2-A94C-6D0FA915DA93@cs.berkeley.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , ietf@ietf.org Subject: Re: [tcpm] TCP persist timer min and max values (specified in RFC?) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 12:47:22 -0000 Kevin Fall wrote: > I'm trying to determine whether the range for the TCP persist timer > ([5,60] seconds commonly) is specified by RFC, or instead more of a > historical artifact based on implementation. If it is specified by > RFC, could somebody please point me at it? >From Section 4.2.2.17 of RFC 1122: > The transmitting host SHOULD send the first zero-window > probe when a zero window has existed for the retransmission > timeout period (see Section 4.2.2.15), and SHOULD increase > exponentially the interval between successive probes. > > DISCUSSION: > This procedure minimizes delay if the zero-window > condition is due to a lost ACK segment containing a > window-opening update. Exponential backoff is > recommended, possibly with some maximum interval not > specified here. This procedure is similar to that of > the retransmission algorithm, and it may be possible to > combine the two procedures in the implementation. Then from Section 4.2.3.1 of the same RFC: > The recommended upper and lower bounds on the RTO are known > to be inadequate on large internets. The lower bound SHOULD > be measured in fractions of a second (to accommodate high > speed LANs) and the upper bound should be 2*MSL, i.e., 240 > seconds. Thus that the range *is* specified by the RFC (not hardcoded, but derived from the RTO). Regarding the upper limit of the RTO (and hence the persist timer), in theory it is derived from the MSL, which in turn is derived from the recommended TTL (60). However, most implementations use different values for the TTL (either 255 or a power of of 2, such as 64 or 128). This, together with the fact that the TTL is assumed to be a hop limit (rather than a time count) might leave some room for using a different upper limit for the RTO (and hence the persist timer). Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From ycheng@google.com Mon Aug 16 12:31:21 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C7693A6896 for ; Mon, 16 Aug 2010 12:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.232 X-Spam-Level: X-Spam-Status: No, score=-104.232 tagged_above=-999 required=5 tests=[AWL=-0.855, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJ7rECsfC3p1 for ; Mon, 16 Aug 2010 12:31:20 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1E7123A682E for ; Mon, 16 Aug 2010 12:31:20 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id o7GJVtmH029218 for ; Mon, 16 Aug 2010 12:31:55 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1281987115; bh=tII3EWAenSVq8meHmOOQayLP6Hs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=hKrCTugUywl9F3TJq/6+rh0KzdEJryubDLdi0uLGACxI7azhF1/kCo9Hzs7ScfkSx 7nPThe0j4lZ/UGnqNOFkw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=oyEgkj7XAraW8PzJZ+q5Y3X4VaYcFEdMgcGr4zBcRSYr0OVzmhbxlSCa7Ii3rLEE2 aHiIJYL+KqHi/ka40i8Sg== Received: from vws15 (vws15.prod.google.com [10.241.21.143]) by wpaz29.hot.corp.google.com with ESMTP id o7GJVsEg028495 for ; Mon, 16 Aug 2010 12:31:54 -0700 Received: by vws15 with SMTP id 15so4279936vws.12 for ; Mon, 16 Aug 2010 12:31:54 -0700 (PDT) Received: by 10.220.75.200 with SMTP id z8mr3475137vcj.57.1281987114284; Mon, 16 Aug 2010 12:31:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.83.10 with HTTP; Mon, 16 Aug 2010 12:31:34 -0700 (PDT) In-Reply-To: <5FDC413D5FA246468C200652D63E627A09C49672@LDCMVEXC1-PRD.hq.netapp.com> References: <5FDC413D5FA246468C200652D63E627A09C48990@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A09C49672@LDCMVEXC1-PRD.hq.netapp.com> From: Yuchung Cheng Date: Mon, 16 Aug 2010 12:31:34 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Arvind Jain , tcpm@ietf.org, David Borman , Matt Mathis Subject: Re: [tcpm] Increasing TCP's Initial Congestion Window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 19:31:21 -0000 Hi Richard, We monitor the "lost retransmissions" reported by Linux (LINUX_MIB_TCPLOSTRETRANSMIT). They consist of less than <0.5% of all retransmissions in both IW3 and IW10 flows in our experiments. Therefore I don't think this feature is critical. Yuchung On Wed, Aug 4, 2010 at 4:17 PM, Scheffenegger, Richard wrot= e: > > Hi Matt, > > > I believe the "inability to retransmit lost retransmissions", which is th= e current default behavior (except for Linux), DOES permanently cause every= receiver pain in the form of lengthy RTO recoveries and long flow completi= on times. And not necessarily only during slow start and the initial few se= gments of the flow, but also during steady state, when some other flow's bu= rst causes this effect for some victim flow. > > Or, put differently, IW10 may increase that problem (due to a higher prob= ability of lost retransmissions) over IW3 - and you'd be actually penalizin= g IW10 flows (running into RTO) and the this proposal may see the same fate= as ECN deployment. > > (Due to some broken algorithms/implementations somewhere else, a very goo= d idea would be blamed). > > Therefore I would think, had you done your expirimentation with a "standa= rd" SACK stack, you would have never bothered writing an I-D, as you wouldn= 't have seen any merit. At least that is what I would have expected as the = outcome... > > > Thus I would like to see some strong recommendations, or an add-on RFC to= 2018 /5681, to explicitly recommend lost retransmission detected *before* = IW10 is implemented in a stack... > > (Perhaps you should have been more insistent back then on how to deal wit= h the wealth of info given by SACK to the sender ;) ). > > > Richard Scheffenegger > > > > >> -----Original Message----- >> From: Matt Mathis [mailto:mattmathis@google.com] >> Sent: Mittwoch, 4. August 2010 22:40 >> To: Scheffenegger, Richard >> Cc: Nandita Dukkipati; tcpm@ietf.org; David Borman; Arvind >> Jain; Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >> Subject: Re: [tcpm] Increasing TCP's Initial Congestion Window >> >> Although I think this is an important point and does need to >> be followed up, it is actually inverted relative to the >> question at hand. >> >> Content providers who are using non-Linux might find some >> conditions under which raising IW reduces their performance. >> If so they have grounds to be more cautious about raising IW. >> In either case, SACK is (nearly always) work conserving, so >> the inability to retransmit lost retransmissions is extremely >> unlikely to cause additional pain for IW3 users (the fairness >> question). >> >> If we had done the experimentation with non-Linux, then the >> possibility exists that the inability to recover from lost >> retransmissions would be protecting IW3 users from our >> traffic, and the results couldn't be trusted to apply to Linux. >> >> (I guess this argument does still apply to any other bugs in >> the Linux TCP recovery code). >> >> Thanks, >> --MM-- >> >> On Sun, Aug 1, 2010 at 8:14 AM, Scheffenegger, Richard >> wrote: >> > Hi Nandita, Matt, >> > >> > As mentioned in the session of ICCRG WG (and to not loose this item >> > from discussion here at TCPM): >> > >> > >> > I think it would be good, to break out the results you have >> gathered >> > so far (flow completion time in high percentiles, across multiple >> > regions) also into SACK vs non-SACK flows. >> > >> > Furthermore, as you explained, IW10 (IW16) has only been >> verified in >> > your DC with a SACK-enabled sender, which follows Matt's original >> > intention of using SACK information to recover from lost >> > retransmissions. No other stack (that I'm familiar with; >> opensolaris, >> > {free,open,net}bsd, windows, aix, hpux, is currently doing >> that, afaik). >> > >> > >> > My concern here is, that an umbrella recommendation without >> any strong >> > remarks about that fact, will led to implementatiors of >> other stacks >> > to increase the IW accordingly. >> > >> > However, the ensuing burst loss will probably cancel out >> any gains due >> > to the possibility of fast recovery. (This is why I would >> like to see >> > the flow-competion time for non-SACK flows broken out from your >> > numbers). >> > >> > >> > Don't understand me wrong here - I feel absolutely positive >> that SACK >> > enabled stacks should be encouraged to make use of the information >> > contained within SACK, to recover fast from lost >> retransmissions, and >> > that most stacks should nowadays always use SACK. >> > >> > However, the Linux Stack is the only one which is currently >> doing this >> > (even though there are simple means by which any SACK stack >> could be >> > enabled to gain much of the functionality without the fancy >> scoreboard >> > implementation of Linux; I think, even the lwIP SACK patch could be >> > made to do that under a majority of cases). >> > >> > Perhaps you should write a seperate draft on that aspect, to extend >> > RFC2018... >> > >> > >> > Richard Scheffenegger >> > >> > >> >> >> >> -- >> --MM-- >> The best way to predict the future is to create it. =A0- Peter Drucker >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From wesley.m.eddy@nasa.gov Tue Aug 17 08:10:22 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAE613A6A99 for ; Tue, 17 Aug 2010 08:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.314 X-Spam-Level: X-Spam-Status: No, score=-106.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6xLr+BlQc2c for ; Tue, 17 Aug 2010 08:10:16 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id 1A27C3A67FA for ; Tue, 17 Aug 2010 08:10:16 -0700 (PDT) Received: from ndjsppt05.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 6F43F1087B1; Tue, 17 Aug 2010 10:10:51 -0500 (CDT) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt05.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o7HFAmo2010081; Tue, 17 Aug 2010 10:10:51 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi; Tue, 17 Aug 2010 10:10:49 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Joe Touch , "tcpm@ietf.org" Date: Tue, 17 Aug 2010 10:10:48 -0500 Thread-Topic: [tcpm] Increasing TCP's Initial Congestion Window Thread-Index: AcsvAnL0mS3haQ3HRsq0IE8ZxzQ1pAPGlv3w Message-ID: References: <4C514CD6.6090409@isi.edu> In-Reply-To: <4C514CD6.6090409@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-08-17_07:2010-08-17, 2010-08-17, 1970-01-01 signatures=0 Cc: Arvind Jain , Mathis Subject: Re: [tcpm] Increasing TCP's Initial Congestion Window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 15:10:22 -0000 >-----Original Message----- >From: Joe Touch [mailto:touch@isi.edu] >Sent: Thursday, July 29, 2010 5:42 AM >To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >Cc: Nandita Dukkipati; tcpm@ietf.org; David Borman; Arvind Jain; Mathis; >Matthew@core3.amsl.com >Subject: Re: [tcpm] Increasing TCP's Initial Congestion Window > > > >On 7/23/2010 12:37 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >wrote: >... >> David and I just talked about this and propose to add a milestone to >> the charter for late 2011, if the working group agrees, to publish >> this document on increasing TCP's initial window, based on the large >> amount of discussion both in the meetings and on the list. If anyone >> would object to this, please let us know in the next 2 weeks. >> >> One thing I still don't understand, is how we know that the intended >> status for standards track is appropriate at this point ... from >> talking to David it sounds like the working group can determine that >> after deciding to adopt it, and we don't have to have it decided ahead >> of time. > >I don't think that's appropriate process. We need to decide when we >adopt an item what its intended status will be, IMO. > >Otherwise, it's too early to consider adopting it as a work item IMO. >(that's not to say we can't continue to discuss it, though). Hi Joe, I checked with Lars on the process question of whether we can adopt documents with undetermined target status. He indicated that it would be reasonable to add a milestone to determine what the appropriate level to publish the potential document at is, followed by a milestone to actually publish the document a short time later. I propose that the first milestone to determine status between Experimental and Proposed Standard could have a cutoff-date at which time it would default to the lower option (Experimental) if there isn't clear consensus and comfort with Proposed Standard at that time. This assumes there were no problems discovered with deployment at that level in the meantime. If so, those problems would probably get documented as Informational. Experimental is an appropriate default since it has nearly been deployed at that level already. The main question I have, and would like feedback from the authors and the rest of the working group on, is how far ahead to set that first milestone to determine status? Do we need to think about this for a year (i.e. 3 more meetings)? Shorter? Longer? I would guess after determining the publication track, we'd only spend a month touching up the document and last calling it for the 2nd milestone to publish the document. Any feedback on this would be appreciated. -- Wes Eddy MTI Systems From hkchu@google.com Tue Aug 17 14:49:57 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF4B13A6838 for ; Tue, 17 Aug 2010 14:49:57 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXkDIZU3L84g for ; Tue, 17 Aug 2010 14:49:56 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 798B83A67F3 for ; Tue, 17 Aug 2010 14:49:56 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id o7HLoUw1027931 for ; Tue, 17 Aug 2010 14:50:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1282081830; bh=OUCzdA1CIezlVYQlXUH6y33/OG8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=OFPBmJVPyTxfNDUZoRXvWSoZIhe5CMnDtLqItM6nLDL8GOQMXY8GmsO7vAkNMsUAI rwxB1ia0CkfQ/kvATwo/Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=Da/T3HIxWHPCteuYQhXKOsovwWOazcPLcTahTjcLMNK1Pvc9es2bC80R8ZgvVILFk 6vXiIhPBJgIhVLDPKbYMg== Received: from gxk20 (gxk20.prod.google.com [10.202.11.20]) by wpaz13.hot.corp.google.com with ESMTP id o7HLoTmR004069 for ; Tue, 17 Aug 2010 14:50:29 -0700 Received: by gxk20 with SMTP id 20so2894794gxk.3 for ; Tue, 17 Aug 2010 14:50:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.58.20 with SMTP id g20mr7742790yba.24.1282081828882; Tue, 17 Aug 2010 14:50:28 -0700 (PDT) Received: by 10.151.100.7 with HTTP; Tue, 17 Aug 2010 14:50:28 -0700 (PDT) In-Reply-To: <15B3F34B-5FE6-4B57-8276-076C941FEB34@comsys.rwth-aachen.de> References: <20100812201551.6F09719C5CDE@lawyers.icir.org> <15B3F34B-5FE6-4B57-8276-076C941FEB34@comsys.rwth-aachen.de> Date: Tue, 17 Aug 2010 14:50:28 -0700 Message-ID: From: Jerry Chu To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" , David Borman Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "tcpm@ietf.org Extensions" , Vern Paxson , " Allman" Subject: Re: [tcpm] reset: seeding RTO in 3WHS X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 21:49:58 -0000 Wes & David, It looks like 2988bis is ready for adoption as a WG item. Please let us know what to do next. Notat that besides reducing minRTO, a couple of other issues have been brought up and discussed, one from Gorry Fairhurst on the implication of SYN RTO expiry, the other from Markku on slow links with a larger IW. We (Mark/Vern/I) will revise the draft to capture both discussions in the near future. Thanks, Jerry On Fri, Aug 13, 2010 at 1:42 AM, Alexander Zimmermann wrote: > > Hi Jerry, > > I had the same discussion with Mark a while ago, whether or not ever > we should include the reducing minRTO stuff into the 2988bis doc or > not. Mark persuaded my that it is better to do not do so in order to > not block the doc. > > However, since feb, nothing is happened... So I think we should decide > NOW if the WG would like to adopt the doc as it is (without minRTO > adjustment) or not. > > Alex > > Am 12.08.2010 um 22:15 schrieb Mark Allman: > > > > > Jerry- > > > >> I think the only outstanding question on the initRTO=1sec proposal is > >> why not try to reduce minRTO as well and I was asking why the two > >> things need to go together (see my 6/28/10 email). > >> > >> Since you have done some study on the overall impact of minRTO perhaps > >> you can share your thought on this? > > > > > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > From hkchu@google.com Tue Aug 17 23:11:25 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D846C3A68F3 for ; Tue, 17 Aug 2010 23:11:25 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsdAH77ne9CQ for ; Tue, 17 Aug 2010 23:11:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C2E303A6A02 for ; Tue, 17 Aug 2010 23:11:22 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o7I6Bv7t003633 for ; Tue, 17 Aug 2010 23:11:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1282111917; bh=RuSbfp4LqxS+hvK2m//uyx/0cSg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=BH5kdRRSTHg1RpNan/hIDicQMpS26I0lZkPfVeiH2617yEpGkOdXT5A2dmIsov3Yg k7j4V8Ble8rr8XhNRoWdw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=HhrerHVMv8mahMa76zVx5c+uqcj3KpZ3fO0bYr4saxCoScPbzz/xJckHnBX84UHYZ z8oNwApJhAzYTnvz8LOlQ== Received: from gwj17 (gwj17.prod.google.com [10.200.10.17]) by wpaz24.hot.corp.google.com with ESMTP id o7I6Busu006524 for ; Tue, 17 Aug 2010 23:11:57 -0700 Received: by gwj17 with SMTP id 17so59851gwj.19 for ; Tue, 17 Aug 2010 23:11:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.41.7 with SMTP id t7mr8391555ybj.140.1282111916508; Tue, 17 Aug 2010 23:11:56 -0700 (PDT) Received: by 10.151.100.7 with HTTP; Tue, 17 Aug 2010 23:11:56 -0700 (PDT) In-Reply-To: References: <4C514CD6.6090409@isi.edu> Date: Tue, 17 Aug 2010 23:11:56 -0700 Message-ID: From: Jerry Chu To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Arvind Jain , "tcpm@ietf.org" , Joe Touch , Mathis Subject: Re: [tcpm] Increasing TCP's Initial Congestion Window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 06:11:26 -0000 Hi Wes, Thanks for trying to move this forward quickly. The two-milestone approach sounds very reasonable to us. Regarding what the appropriate time line might be for the first milestone, I think this mostly depends on how many concerns we have successfully addressed vs how many still remaining. It also depends on how much help folks on this list are willing to provide to cover the remaining concerns. To answer the question it may help to recount what we've gotten so far: 1. Results from a number of large scale experiments at Google's data centers presented at IETF/Anaheim. http://www.ietf.org/proceedings/77/slides/tcpm-4.pdf 2. Details from the above published in A SIGCOMM CCR paper in July. http://ccr.sigcomm.org/online/?q=3Dnode/621 3. "A Simulation Study on Increasing TCP's IW" presented at ICCRG/Maastricht by Ilpo Jarvinen on the effect of IW10 over wireless links= . 4. Some fairness study by Michael Scharf as part of his PhD thesis that was sent to the ICCRG list on 7/25/10. 5. Results from another round of experiments plus a testbed study by us in an attempt to study and address concerns raised at Anaheim. http://www.ietf.org/proceedings/78/slides/iccrg-3.pdf Since our presentation was the last one at the ICCRG meeting and the meeting adjourned shortly after, plus it was the last day of the IETF week, we did not receive much feedback on how our data address, or even just partially alleviate the concern on how IW10 flows affect other flows with a smaller IW, for example. (There was some suggestion related to our testbed. But unfortunately we have lost our intern back to school so not much has been done since.) Thus it will be helpful if people can throw feedbacks/comments/suggestions at us now on our results so far so we can better sense where we are at right now and how much further we need to go to get to Proposed Standard. Thanks, Jerry On Tue, Aug 17, 2010 at 8:10 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: >>-----Original Message----- >>From: Joe Touch [mailto:touch@isi.edu] >>Sent: Thursday, July 29, 2010 5:42 AM >>To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >>Cc: Nandita Dukkipati; tcpm@ietf.org; David Borman; Arvind Jain; Mathis; >>Matthew@core3.amsl.com >>Subject: Re: [tcpm] Increasing TCP's Initial Congestion Window >> >> >> >>On 7/23/2010 12:37 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >>wrote: >>... >>> David and I just talked about this and propose to add a milestone to >>> the charter for late 2011, if the working group agrees, to publish >>> this document on increasing TCP's initial window, based on the large >>> amount of discussion both in the meetings and on the list. =A0If anyone >>> would object to this, please let us know in the next 2 weeks. >>> >>> One thing I still don't understand, is how we know that the intended >>> status for standards track is appropriate at this point ... from >>> talking to David it sounds like the working group can determine that >>> after deciding to adopt it, and we don't have to have it decided ahead >>> of time. >> >>I don't think that's appropriate process. We need to decide when we >>adopt an item what its intended status will be, IMO. >> >>Otherwise, it's too early to consider adopting it as a work item IMO. >>(that's not to say we can't continue to discuss it, though). > > > Hi Joe, I checked with Lars on the process question of whether we > can adopt documents with undetermined target status. =A0He indicated > that it would be reasonable to add a milestone to determine what > the appropriate level to publish the potential document at is, followed > by a milestone to actually publish the document a short time later. > > I propose that the first milestone to determine status between > Experimental and Proposed Standard could have a cutoff-date at which > time it would default to the lower option (Experimental) if there > isn't clear consensus and comfort with Proposed Standard at that time. > This assumes there were no problems discovered with deployment at that > level in the meantime. =A0If so, those problems would probably get > documented as Informational. =A0Experimental is an appropriate default > since it has nearly been deployed at that level already. > > The main question I have, and would like feedback from the authors and > the rest of the working group on, is how far ahead to set that first > milestone to determine status? =A0Do we need to think about this for a > year (i.e. 3 more meetings)? =A0Shorter? =A0Longer? =A0I would guess afte= r > determining the publication track, we'd only spend a month touching up > the document and last calling it for the 2nd milestone to publish the > document. > > Any feedback on this would be appreciated. > > -- > Wes Eddy > MTI Systems > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From wesley.m.eddy@nasa.gov Thu Aug 19 18:40:58 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417E43A67E2 for ; Thu, 19 Aug 2010 18:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.605 X-Spam-Level: X-Spam-Status: No, score=-105.605 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvuLRl84vEP3 for ; Thu, 19 Aug 2010 18:40:57 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id 5D6383A6838 for ; Thu, 19 Aug 2010 18:40:57 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id D0DCF261245 for ; Thu, 19 Aug 2010 20:41:31 -0500 (CDT) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o7K1fVbO007969 for ; Thu, 19 Aug 2010 20:41:31 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Thu, 19 Aug 2010 20:41:31 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Thu, 19 Aug 2010 20:41:31 -0500 Thread-Topic: initiating WGLC for draft-eggert-tcpm-historicize Thread-Index: AQHLQAjQWCMkn2RB+kSu1V5POWQ5cg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-08-19_11:2010-08-19, 2010-08-19, 1970-01-01 signatures=0 Subject: [tcpm] initiating WGLC for draft-eggert-tcpm-historicize X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 01:40:58 -0000 Following up on the earlier thread to adopt draft-eggert-tcpm-historicize a= s a TCPM working group item, there seems to be positive support and no obje= ction to the document itself, though there was a lot of discussion on the a= lternate checksum option going forward. Based on the nature of this document (not a technical spec, just cleaning u= p the status of other documents), the authors and chairs think we can just = do a one-month working group last call in order to complete this activity. The document can be found at: http://tools.ietf.org/html/draft-eggert-tcpm-historicize-00 Please review it, and send your comments, concerns, and critiques to the TC= PM list by September 17. If this is too soon, and you think more time is w= arranted, this would be a fair comment to raise as well. Thanks in advance.= From pekkas@netcore.fi Thu Aug 19 22:50:49 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB2103A6A4C for ; Thu, 19 Aug 2010 22:50:48 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIHO4A0FTwOx for ; Thu, 19 Aug 2010 22:50:45 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id EEA763A69CC for ; Thu, 19 Aug 2010 22:50:44 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id o7K5p9Tk003108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Aug 2010 08:51:09 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id o7K5p8jE003105; Fri, 20 Aug 2010 08:51:09 +0300 Date: Fri, 20 Aug 2010 08:51:08 +0300 (EEST) From: Pekka Savola To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.96.1 at otso.netcore.fi X-Virus-Status: Clean Cc: "tcpm@ietf.org" Subject: Re: [tcpm] initiating WGLC for draft-eggert-tcpm-historicize X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 05:50:49 -0000 On Thu, 19 Aug 2010, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > Please review it, and send your comments, concerns, and critiques to > the TCPM list by September 17. If this is too soon, and you think > more time is warranted, this would be a fair comment to raise as > well. Support. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From root@core3.amsl.com Mon Aug 23 12:15:04 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 141743A6A95; Mon, 23 Aug 2010 12:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100823191504.141743A6A95@core3.amsl.com> Date: Mon, 23 Aug 2010 12:15:03 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-urgent-data-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:15:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : On the implementation of the TCP urgent mechanism Author(s) : F. Gont, A. Yourtchenko Filename : draft-ietf-tcpm-urgent-data-06.txt Pages : 13 Date : 2010-08-23 This document analyzes how current TCP implementations process TCP urgent indications, and how the behavior of some widely-deployed middle-boxes affect how urgent indications are processed by end systems. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, provides advice to applications that make use of the urgent mechanism, and raises awareness about the reliability of TCP urgent indications in the current Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-urgent-data-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-urgent-data-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-23120840.I-D@ietf.org> --NextPart-- From viniciusromao@gmail.com Tue Aug 24 07:30:11 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1AF63A6B0A for ; Tue, 24 Aug 2010 07:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.902 X-Spam-Level: X-Spam-Status: No, score=0.902 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsVweVHu0ExC for ; Tue, 24 Aug 2010 07:30:10 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 2F4173A6AFC for ; Tue, 24 Aug 2010 07:30:08 -0700 (PDT) Received: by pvg7 with SMTP id 7so3124907pvg.31 for ; Tue, 24 Aug 2010 07:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=fQFqdJ/x61DkzfaanJcnUTy8Vw9wOy6vSajG44NkFSs=; b=U3DI69epsgax14kk45Jf59RZPzodcHqbdIX80NDPnp9VG5zDZc/yTFmOkx5GkuTRft CXXGggDc/0g9p8HgZP4gcJLJhOGj32Xg82wpIo+PdAoNs5EFDFuz7owSlF8lpuLkSLkp BWFXBiGy1nrG6fcmdkzaOvxJ/0eNrPsFgLihY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZaLj834SIs85yDgCyi0C4iODFVe4SCEGzqipn0gETwbRgKmXTaQBVRJneVdqbXC0yG rJ4pLhOCihNNKCeqon/YHNRPqebYLWuOnxLh71Vb2YYYoiui8j6ETYbB41KQ3gTDCujQ G7q0RZN2IlLM9T5f4uKySnQU2qccwjlakhSJI= MIME-Version: 1.0 Received: by 10.142.147.7 with SMTP id u7mr5634150wfd.218.1282660240454; Tue, 24 Aug 2010 07:30:40 -0700 (PDT) Received: by 10.142.253.7 with HTTP; Tue, 24 Aug 2010 07:30:40 -0700 (PDT) Date: Tue, 24 Aug 2010 11:30:40 -0300 Message-ID: From: =?ISO-8859-1?Q?Vinicius_Rom=E3o?= To: tcpm@ietf.org Content-Type: multipart/alternative; boundary=000e0cd2281efff3d3048e929bd3 Subject: [tcpm] TCP window max size? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 14:34:44 -0000 --000e0cd2281efff3d3048e929bd3 Content-Type: text/plain; charset=ISO-8859-1 Hi Fellows. (Apologies if this is not the correct forum to this e-mail, but the tcplw WG and list are already concluded.) The RFC-1323 specifies the TCP Window Scale Option. It states that the maximum window size is 2^30 (1Gbyte), please see the last paragraph in the page 10. It limits the shift.count <= 14, this way the requirement above is guaranteed. Note that the maximum window size is one-quarter of the TCP sequence number space (2^32 = 4Gbyte). However the references below indicate that a Sliding Window protocol works properly if the maximum window size is at most half of the sequence number space available. The key is insure that once the receiver advances its window, the new range of valid sequence numbers does not overlap with the old one. In this case the maximum window size of TCP could be 2Gbyte instead of 1Gbyte. Even with a window length of 2Gbyte it does not seem possible to duplicate sequence numbers in the same window by overlap or segment/ack losses. Duplicates are still possible due earlier packet incarnations, however they must be handled by the Maximum Segment Lifetime or PAWS extension. I would be grateful it someone could explain me or recommend a reference to understand the reason why the TCP window max size is limited to 1Gbyte (2^30) instead 2Gb(2^31). Thank you for any help you can provide. Vinicius M. Romao References: 1 - Tanenbaum, Andrew. Computer Networks. 4Ed. Prentice Hall Pub, 2002. Section: 3.4.3 A Protocol Using Selective Repeat. 2 - Peterson, Larry, and Davie, Bruce. Computer networks: A Systems Approach. 3Ed. Boston: Morgan Kaufmann Pub, 2003. 104-105. Section: 2.5.2 Sliding Window. --000e0cd2281efff3d3048e929bd3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Fellows.

(Apologies if this is not the correct forum to this e-ma= il, but the tcplw WG and list are already concluded.)

The RFC-1323 s= pecifies the TCP Window Scale Option. It states that the maximum window siz= e is 2^30 (1Gbyte), please see the last paragraph in the page 10. It limits= the shift.count <=3D 14, this way the requirement above is guaranteed. = Note that the maximum window size is one-quarter of the TCP sequence number= space (2^32 =3D 4Gbyte).

However the references below indicate that a Sliding Window protocol wo= rks properly if the maximum window size is at most half of the sequence num= ber space available. The key is insure that once the receiver advances its = window, the new range of valid sequence numbers does not overlap with the o= ld one.

In this case the maximum window size of TCP could be 2Gbyte instead of = 1Gbyte. Even with a window length of 2Gbyte it does not seem possible to du= plicate sequence numbers in the same window by overlap or segment/ack losse= s. Duplicates are still possible due earlier packet incarnations, however t= hey must be handled by the Maximum Segment Lifetime or PAWS extension.

I would be grateful it someone could explain me or recommend a referenc= e to understand the reason why the TCP window max size is limited to 1Gbyte= (2^30) instead 2Gb(2^31).

Thank you for any help you can provide.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Vinicius M. Romao


References:
1 - Tanenbaum, Andrew. Computer Networks. 4Ed. Prent= ice Hall Pub, 2002. Section: 3.4.3 A Protocol Using Selective Repeat.
2 - Peterson, Larry, and Davie, Bruce. Computer networks: A Systems Appro= ach. 3Ed. Boston: Morgan Kaufmann Pub, 2003. 104-105. Section: 2.5.2 Slidin= g Window.

--000e0cd2281efff3d3048e929bd3-- From wesley.m.eddy@nasa.gov Tue Aug 24 13:39:02 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194913A6A7A for ; Tue, 24 Aug 2010 13:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.388 X-Spam-Level: X-Spam-Status: No, score=-106.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9iLB311UeCy for ; Tue, 24 Aug 2010 13:38:59 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 836BD3A6A72 for ; Tue, 24 Aug 2010 13:37:31 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 8DAF5328A2D for ; Tue, 24 Aug 2010 15:38:03 -0500 (CDT) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o7OKaLuA005116 for ; Tue, 24 Aug 2010 15:38:02 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Tue, 24 Aug 2010 15:37:34 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Tue, 24 Aug 2010 15:37:31 -0500 Thread-Topic: revising and advancing NewReno Thread-Index: ActDzCypvxaNx+lqSJaaVsfulPElMQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: 2Sg= AKu3 Bg+Z CXVI DLXV EdjZ E3D6 E9WC E97J FYjc FddJ HDzR H2gm H5YB H68n IMor; 1; dABjAHAAbQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {F38731CB-5334-4EA3-93B3-F13087D1D73D}; dwBlAHMAbABlAHkALgBtAC4AZQBkAGQAeQBAAG4AYQBzAGEALgBnAG8AdgA=; Tue, 24 Aug 2010 20:37:31 GMT; cgBlAHYAaQBzAGkAbgBnACAAYQBuAGQAIABhAGQAdgBhAG4AYwBpAG4AZwAgAE4AZQB3AFIAZQBuAG8A x-cr-puzzleid: {F38731CB-5334-4EA3-93B3-F13087D1D73D} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-08-24_10:2010-08-24, 2010-08-24, 1970-01-01 signatures=0 Subject: [tcpm] revising and advancing NewReno X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 20:39:03 -0000 X-List-Received-Date: Tue, 24 Aug 2010 20:39:03 -0000 Based on Yoshifumi's work on NewReno in: http://tools.ietf.org/html/draft-nishida-newreno-modification-02 combined with the existing Errata to RFC 3782, the possibility of doing a revision to RFC 3782 has been proposed with the editors from that document. None were opposed, and the prospect of also advancing NewReno from Proposed Standard to Draft Standard as part of the revision was raised. Two questions to poll the working group on are: 1 - Would anyone in the working group be opposed to TCPM taking on a revision to RFC 3782 as a working group item? 2 - Does advancing NewReno to Draft Standard seem agreeable? -- Wes Eddy MTI Systems From david.borman@windriver.com Tue Aug 24 14:21:56 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53D993A6A64 for ; Tue, 24 Aug 2010 14:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.099 X-Spam-Level: X-Spam-Status: No, score=-100.099 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQ4IuyNMCkgF for ; Tue, 24 Aug 2010 14:21:55 -0700 (PDT) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 6F42E3A690F for ; Tue, 24 Aug 2010 14:21:54 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id o7OLMPhj007489; Tue, 24 Aug 2010 14:22:25 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Aug 2010 14:22:25 -0700 Received: from [172.25.34.59] ([172.25.34.59]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Aug 2010 14:22:24 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: David Borman In-Reply-To: Date: Tue, 24 Aug 2010 16:22:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <512991AB-CB0C-4A49-994E-644276299BFD@windriver.com> References: To: =?iso-8859-1?Q?Vinicius_Rom=E3o?= X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 24 Aug 2010 21:22:25.0334 (UTC) FILETIME=[727F7560:01CB43D2] Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP window max size? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 21:21:56 -0000 This reasoning is explained in RFC 1323, section 2.3, at the bottom of page 10 and the top of page 11: TCP determines if a data segment is "old" or "new" by testing whether its sequence number is within 2**31 bytes of the left edge of the window, and if it is not, discarding the data as "old". To insure that new data is never mistakenly considered old and vice- versa, the left edge of the sender's window has to be at most 2**31 away from the right edge of the receiver's window. Similarly with the sender's right edge and receiver's left edge. Since the right and left edges of either the sender's or receiver's window differ by the window size, and since the sender and receiver windows can be out of phase by at most the window size, the above constraints imply that 2 * the max window size must be less than 2**31, or max window < 2**30 Since the max window is 2**S (where S is the scaling shift count) times at most 2**16 - 1 (the maximum unscaled window), the maximum window is guaranteed to be < 2*30 if S <=3D 14. Thus, the shift count must be limited to 14 (which allows windows of 2**30 =3D 1 Gbyte)... -David Borman On Aug 24, 2010, at 9:30 AM, Vinicius Rom=E3o wrote: > Hi Fellows. >=20 > (Apologies if this is not the correct forum to this e-mail, but the = tcplw WG > and list are already concluded.) >=20 > The RFC-1323 specifies the TCP Window Scale Option. It states that the > maximum window size is 2^30 (1Gbyte), please see the last paragraph in = the > page 10. It limits the shift.count <=3D 14, this way the requirement = above is > guaranteed. Note that the maximum window size is one-quarter of the = TCP > sequence number space (2^32 =3D 4Gbyte). >=20 > However the references below indicate that a Sliding Window protocol = works > properly if the maximum window size is at most half of the sequence = number > space available. The key is insure that once the receiver advances its > window, the new range of valid sequence numbers does not overlap with = the > old one. >=20 > In this case the maximum window size of TCP could be 2Gbyte instead of > 1Gbyte. Even with a window length of 2Gbyte it does not seem possible = to > duplicate sequence numbers in the same window by overlap or = segment/ack > losses. Duplicates are still possible due earlier packet incarnations, > however they must be handled by the Maximum Segment Lifetime or PAWS > extension. >=20 > I would be grateful it someone could explain me or recommend a = reference to > understand the reason why the TCP window max size is limited to 1Gbyte > (2^30) instead 2Gb(2^31). >=20 > Thank you for any help you can provide. >=20 > Vinicius M. Romao >=20 >=20 > References: > 1 - Tanenbaum, Andrew. Computer Networks. 4Ed. Prentice Hall Pub, = 2002. > Section: 3.4.3 A Protocol Using Selective Repeat. >=20 > 2 - Peterson, Larry, and Davie, Bruce. Computer networks: A Systems > Approach. 3Ed. Boston: Morgan Kaufmann Pub, 2003. 104-105. Section: = 2.5.2 > Sliding Window. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From david.borman@windriver.com Tue Aug 24 15:07:20 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72ED83A6835 for ; Tue, 24 Aug 2010 15:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2002qhP3YZ-1 for ; Tue, 24 Aug 2010 15:07:19 -0700 (PDT) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 615DD3A67B2 for ; Tue, 24 Aug 2010 15:07:19 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id o7OM7o6d016415; Tue, 24 Aug 2010 15:07:50 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Aug 2010 15:07:49 -0700 Received: from [172.25.34.59] ([172.25.34.59]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Aug 2010 15:07:49 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: David Borman In-Reply-To: <512991AB-CB0C-4A49-994E-644276299BFD@windriver.com> Date: Tue, 24 Aug 2010 17:07:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0D0CEA97-722C-4329-86E9-BFDFDC01E04A@windriver.com> References: <512991AB-CB0C-4A49-994E-644276299BFD@windriver.com> To: =?iso-8859-1?Q?Vinicius_Rom=E3o?= X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 24 Aug 2010 22:07:49.0855 (UTC) FILETIME=[CA705EF0:01CB43D8] Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] TCP window max size? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 22:07:20 -0000 On Aug 24, 2010, at 4:22 PM, David Borman wrote: > This reasoning is explained in RFC 1323, section 2.3, at the bottom of > page 10 and the top of page 11: >=20 > TCP determines if a data segment is "old" or "new" by testing > whether its sequence number is within 2**31 bytes of the left edge > of the window, and if it is not, discarding the data as "old". To > insure that new data is never mistakenly considered old and vice- > versa, the left edge of the sender's window has to be at most > 2**31 away from the right edge of the receiver's window. > Similarly with the sender's right edge and receiver's left edge. > Since the right and left edges of either the sender's or > receiver's window differ by the window size, and since the sender > and receiver windows can be out of phase by at most the window > size, the above constraints imply that 2 * the max window size > must be less than 2**31, or >=20 > max window < 2**30 >=20 > Since the max window is 2**S (where S is the scaling shift count) > times at most 2**16 - 1 (the maximum unscaled window), the maximum > window is guaranteed to be < 2*30 if S <=3D 14. Thus, the shift > count must be limited to 14 (which allows windows of 2**30 =3D 1 > Gbyte)... And what I forgot to ask was whether you or someone else disagreed with this logic, but this is why it is 14. However, even if the logic is faulty, the max value will remain at 14, the only way to change it would be via a new TCP option number. But mostly the place for trouble is at the boundary conditions, and if you had a 2^31 window and the sender/receiver windows were fully skewed, any outstanding packet from before left edge of the senders window could show up at the receiver and be viewed as new data at the right edge of the receivers window, which would be a bad thing. 1) Sender has a full 2^31 window of unacknowledged data, receiver is a full 2^31 ahead of the sender. 2) Sender retransmits a packet at left edge of it's window. 3) In-transit Ack from Receiver arrives, acks all data, and advances window by 2^31. 4) Sender sends a new packet. 5) New packet gets reordered in transit with the retransmitted packet. 6) New packet arrives, and receiver advances window. 7) Retransmitted packet arrives, and it now appears to be at the right edge of the receivers window as new data. A 2^14 max window keeps things well away from those boundary conditions. >=20 > -David Borman >=20 > On Aug 24, 2010, at 9:30 AM, Vinicius Rom=E3o wrote: >=20 >> Hi Fellows. >>=20 >> (Apologies if this is not the correct forum to this e-mail, but the = tcplw WG >> and list are already concluded.) >>=20 >> The RFC-1323 specifies the TCP Window Scale Option. It states that = the >> maximum window size is 2^30 (1Gbyte), please see the last paragraph = in the >> page 10. It limits the shift.count <=3D 14, this way the requirement = above is >> guaranteed. Note that the maximum window size is one-quarter of the = TCP >> sequence number space (2^32 =3D 4Gbyte). >>=20 >> However the references below indicate that a Sliding Window protocol = works >> properly if the maximum window size is at most half of the sequence = number >> space available. The key is insure that once the receiver advances = its >> window, the new range of valid sequence numbers does not overlap with = the >> old one. >>=20 >> In this case the maximum window size of TCP could be 2Gbyte instead = of >> 1Gbyte. Even with a window length of 2Gbyte it does not seem possible = to >> duplicate sequence numbers in the same window by overlap or = segment/ack >> losses. Duplicates are still possible due earlier packet = incarnations, >> however they must be handled by the Maximum Segment Lifetime or PAWS >> extension. >>=20 >> I would be grateful it someone could explain me or recommend a = reference to >> understand the reason why the TCP window max size is limited to = 1Gbyte >> (2^30) instead 2Gb(2^31). >>=20 >> Thank you for any help you can provide. >>=20 >> Vinicius M. Romao >>=20 >>=20 >> References: >> 1 - Tanenbaum, Andrew. Computer Networks. 4Ed. Prentice Hall Pub, = 2002. >> Section: 3.4.3 A Protocol Using Selective Repeat. >>=20 >> 2 - Peterson, Larry, and Davie, Bruce. Computer networks: A Systems >> Approach. 3Ed. Boston: Morgan Kaufmann Pub, 2003. 104-105. Section: = 2.5.2 >> Sliding Window. >> _______________________________________________ >> 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 viniciusromao@gmail.com Tue Aug 24 19:44:17 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F38223A6948 for ; Tue, 24 Aug 2010 19:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.737 X-Spam-Level: X-Spam-Status: No, score=-0.737 tagged_above=-999 required=5 tests=[AWL=0.961, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXQo3vh69aW9 for ; Tue, 24 Aug 2010 19:44:15 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 41EB63A67FB for ; Tue, 24 Aug 2010 19:44:15 -0700 (PDT) Received: by pwi1 with SMTP id 1so140718pwi.31 for ; Tue, 24 Aug 2010 19:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=kS3PtqhvBAAzu4xi1CPm4+Z/qCM1AzRtO14+dhesfgg=; b=bWHE7dRQnUQKuzrLjr21n/MDlQUjDwpkQVBziVDoP71nBKN/+YCt5a4GOr8YGbEHYH aJ8FaVeEItgH/eCqClEyClf66Il2erpvxKRYNdycGr03PHnUwPk77jrV9jMgKHpSliy4 qmYWHl7QHKjM9gQo+xwyBISGUnhAuWqn7SoPE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kgOVZcOjeOXBtB7TYucnIf61i3ztZWvNvZZSJw+4YxEsHnmunIUXDVs+JsOTqJETcs 7baoR8N7KRp4JnCOKZhjzY7WNalPuiCx0BEcLdMUPsSJhnphgYaUkGSQgberA8woucRn yN6nkKUk9D2vGtTIRLnYA5lCXeaL7zqEiN8OU= MIME-Version: 1.0 Received: by 10.142.147.7 with SMTP id u7mr6372393wfd.218.1282704288209; Tue, 24 Aug 2010 19:44:48 -0700 (PDT) Received: by 10.142.253.7 with HTTP; Tue, 24 Aug 2010 19:44:48 -0700 (PDT) In-Reply-To: <0D0CEA97-722C-4329-86E9-BFDFDC01E04A@windriver.com> References: <512991AB-CB0C-4A49-994E-644276299BFD@windriver.com> <0D0CEA97-722C-4329-86E9-BFDFDC01E04A@windriver.com> Date: Tue, 24 Aug 2010 23:44:48 -0300 Message-ID: From: =?ISO-8859-1?Q?Vinicius_Rom=E3o?= To: David Borman Content-Type: multipart/alternative; boundary=000e0cd2281e735d5b048e9cdda7 Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] TCP window max size? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 02:44:17 -0000 --000e0cd2281e735d5b048e9cdda7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Borman, Thank you very much for your clarifications. After reading your explanation, I agree that 1Gbyte is the best choice to the TCP window max size. Thanks. Vinicius M. Romao 2010/8/24 David Borman > > On Aug 24, 2010, at 4:22 PM, David Borman wrote: > > > This reasoning is explained in RFC 1323, section 2.3, at the bottom of > > page 10 and the top of page 11: > > > > TCP determines if a data segment is "old" or "new" by testing > > whether its sequence number is within 2**31 bytes of the left edge > > of the window, and if it is not, discarding the data as "old". To > > insure that new data is never mistakenly considered old and vice- > > versa, the left edge of the sender's window has to be at most > > 2**31 away from the right edge of the receiver's window. > > Similarly with the sender's right edge and receiver's left edge. > > Since the right and left edges of either the sender's or > > receiver's window differ by the window size, and since the sender > > and receiver windows can be out of phase by at most the window > > size, the above constraints imply that 2 * the max window size > > must be less than 2**31, or > > > > max window < 2**30 > > > > Since the max window is 2**S (where S is the scaling shift count) > > times at most 2**16 - 1 (the maximum unscaled window), the maximum > > window is guaranteed to be < 2*30 if S <=3D 14. Thus, the shift > > count must be limited to 14 (which allows windows of 2**30 =3D 1 > > Gbyte)... > > And what I forgot to ask was whether you or someone else disagreed with > this logic, but this is why it is 14. However, even if the logic is > faulty, the max value will remain at 14, the only way to change it would > be via a new TCP option number. > > But mostly the place for trouble is at the boundary conditions, and if > you had a 2^31 window and the sender/receiver windows were fully skewed, > any outstanding packet from before left edge of the senders window could > show up at the receiver and be viewed as new data at the right edge of > the receivers window, which would be a bad thing. > > 1) Sender has a full 2^31 window of unacknowledged data, > receiver is a full 2^31 ahead of the sender. > 2) Sender retransmits a packet at left edge of it's window. > 3) In-transit Ack from Receiver arrives, acks all data, and > advances window by 2^31. > 4) Sender sends a new packet. > 5) New packet gets reordered in transit with the retransmitted packet. > 6) New packet arrives, and receiver advances window. > 7) Retransmitted packet arrives, and it now appears to be at the > right edge of the receivers window as new data. > > A 2^14 max window keeps things well away from those boundary conditions. > > > > > > -David Borman > > > > On Aug 24, 2010, at 9:30 AM, Vinicius Rom=E3o wrote: > > > >> Hi Fellows. > >> > >> (Apologies if this is not the correct forum to this e-mail, but the > tcplw WG > >> and list are already concluded.) > >> > >> The RFC-1323 specifies the TCP Window Scale Option. It states that the > >> maximum window size is 2^30 (1Gbyte), please see the last paragraph in > the > >> page 10. It limits the shift.count <=3D 14, this way the requirement a= bove > is > >> guaranteed. Note that the maximum window size is one-quarter of the TC= P > >> sequence number space (2^32 =3D 4Gbyte). > >> > >> However the references below indicate that a Sliding Window protocol > works > >> properly if the maximum window size is at most half of the sequence > number > >> space available. The key is insure that once the receiver advances its > >> window, the new range of valid sequence numbers does not overlap with > the > >> old one. > >> > >> In this case the maximum window size of TCP could be 2Gbyte instead of > >> 1Gbyte. Even with a window length of 2Gbyte it does not seem possible = to > >> duplicate sequence numbers in the same window by overlap or segment/ac= k > >> losses. Duplicates are still possible due earlier packet incarnations, > >> however they must be handled by the Maximum Segment Lifetime or PAWS > >> extension. > >> > >> I would be grateful it someone could explain me or recommend a referen= ce > to > >> understand the reason why the TCP window max size is limited to 1Gbyte > >> (2^30) instead 2Gb(2^31). > >> > >> Thank you for any help you can provide. > >> > >> Vinicius M. Romao > >> > >> > >> References: > >> 1 - Tanenbaum, Andrew. Computer Networks. 4Ed. Prentice Hall Pub, 2002= . > >> Section: 3.4.3 A Protocol Using Selective Repeat. > >> > >> 2 - Peterson, Larry, and Davie, Bruce. Computer networks: A Systems > >> Approach. 3Ed. Boston: Morgan Kaufmann Pub, 2003. 104-105. Section: > 2.5.2 > >> Sliding Window. > >> _______________________________________________ > >> 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 > > --000e0cd2281e735d5b048e9cdda7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0=A0 Borman,

Thank you very much for your clarifications.
After reading your explanation, I agree that 1Gbyte is the best choice= to the TCP window max size.

Thanks.

Vinicius M. Romao
2010/8/24 David Borman <david.borman@windriver.com&g= t;

On Aug 24, 2010, at 4:22 PM, David Borman wrote:

> This reasoning is explained in RFC 1323, section 2.3, at the bottom of=
> page 10 and the top of page 11:
>
> =A0 =A0TCP determines if a data segment is "old" or "ne= w" by testing
> =A0 =A0whether its sequence number is within 2**31 bytes of the left e= dge
> =A0 =A0of the window, and if it is not, discarding the data as "o= ld". =A0To
> =A0 =A0insure that new data is never mistakenly considered old and vic= e-
> =A0 =A0versa, the left edge of the sender's window has to be at mo= st
> =A0 =A02**31 away from the right edge of the receiver's window. > =A0 =A0Similarly with the sender's right edge and receiver's l= eft edge.
> =A0 =A0Since the right and left edges of either the sender's or > =A0 =A0receiver's window differ by the window size, and since the = sender
> =A0 =A0and receiver windows can be out of phase by at most the window<= br> > =A0 =A0size, the above constraints imply that 2 * the max window size<= br> > =A0 =A0must be less than 2**31, or
>
> =A0 =A0 =A0 =A0 max window < 2**30
>
> =A0 =A0Since the max window is 2**S (where S is the scaling shift coun= t)
> =A0 =A0times at most 2**16 - 1 (the maximum unscaled window), the maxi= mum
> =A0 =A0window is guaranteed to be < 2*30 if S <=3D 14. =A0Thus, = the shift
> =A0 =A0count must be limited to 14 (which allows windows of 2**30 =3D = 1
> =A0 =A0Gbyte)...

And what I forgot to ask was whether you or someone else disagreed wi= th
this logic, but this is why it is 14. =A0However, even if the logic is
faulty, the max value will remain at 14, the only way to change it would be via a new TCP option number.

But mostly the place for trouble is at the boundary conditions, and if
you had a 2^31 window and the sender/receiver windows were fully skewed, any outstanding packet from before left edge of the senders window could show up at the receiver and be viewed as new data at the right edge of
the receivers window, which would be a bad thing.

1) Sender has a full 2^31 window of unacknowledged data,
=A0 receiver is a full 2^31 ahead of the sender.
2) Sender retransmits a packet at left edge of it's window.
3) In-transit Ack from Receiver arrives, acks all data, and
=A0 advances window by 2^31.
4) Sender sends a new packet.
5) New packet gets reordered in transit with the retransmitted packet.
6) New packet arrives, and receiver advances window.
7) Retransmitted packet arrives, and it now appears to be at the
=A0 right edge of the receivers window as new data.

A 2^14 max window keeps things well away from those boundary conditions.


>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -David Borman
>
> On Aug 24, 2010, at 9:30 AM, Vinicius Rom=E3o wrote:
>
>> Hi Fellows.
>>
>> (Apologies if this is not the correct forum to this e-mail, but th= e tcplw WG
>> and list are already concluded.)
>>
>> The RFC-1323 specifies the TCP Window Scale Option. It states that= the
>> maximum window size is 2^30 (1Gbyte), please see the last paragrap= h in the
>> page 10. It limits the shift.count <=3D 14, this way the requir= ement above is
>> guaranteed. Note that the maximum window size is one-quarter of th= e TCP
>> sequence number space (2^32 =3D 4Gbyte).
>>
>> However the references below indicate that a Sliding Window protoc= ol works
>> properly if the maximum window size is at most half of the sequenc= e number
>> space available. The key is insure that once the receiver advances= its
>> window, the new range of valid sequence numbers does not overlap w= ith the
>> old one.
>>
>> In this case the maximum window size of TCP could be 2Gbyte instea= d of
>> 1Gbyte. Even with a window length of 2Gbyte it does not seem possi= ble to
>> duplicate sequence numbers in the same window by overlap or segmen= t/ack
>> losses. Duplicates are still possible due earlier packet incarnati= ons,
>> however they must be handled by the Maximum Segment Lifetime or PA= WS
>> extension.
>>
>> I would be grateful it someone could explain me or recommend a ref= erence to
>> understand the reason why the TCP window max size is limited to 1G= byte
>> (2^30) instead 2Gb(2^31).
>>
>> Thank you for any help you can provide.
>>
>> =A0 =A0 =A0 =A0Vinicius M. Romao
>>
>>
>> References:
>> 1 - Tanenbaum, Andrew. Computer Networks. 4Ed. Prentice Hall Pub, = 2002.
>> Section: 3.4.3 A Protocol Using Selective Repeat.
>>
>> 2 - Peterson, Larry, and Davie, Bruce. Computer networks: A System= s
>> Approach. 3Ed. Boston: Morgan Kaufmann Pub, 2003. 104-105. Section= : 2.5.2
>> Sliding Window.
>> _______________________________________________
>> 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


--000e0cd2281e735d5b048e9cdda7-- From lars.eggert@nokia.com Wed Aug 25 00:26:42 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FB7F3A6827 for ; Wed, 25 Aug 2010 00:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.954 X-Spam-Level: X-Spam-Status: No, score=-103.954 tagged_above=-999 required=5 tests=[AWL=-1.355, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzyqLxf9Fp92 for ; Wed, 25 Aug 2010 00:26:41 -0700 (PDT) Received: from mgw-sa02.nokia.com (mgw-sa02.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id E1C4D3A67F7 for ; Wed, 25 Aug 2010 00:26:38 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o7P7N2cJ002451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Aug 2010 10:23:03 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-67--528660094; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Wed, 25 Aug 2010 10:26:57 +0300 Message-Id: References: To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" X-Mailer: Apple Mail (2.1081) X-Nokia-AV: Clean Cc: "tcpm@ietf.org" Subject: Re: [tcpm] revising and advancing NewReno X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 07:26:42 -0000 --Apple-Mail-67--528660094 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-8-24, at 23:37, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] = wrote: > 1 - Would anyone in the working group be opposed to TCPM taking on > a revision to RFC 3782 as a working group item? as an individual: no, good idea > 2 - Does advancing NewReno to Draft Standard seem agreeable? yes, but since the errata and Yoshifumi's proposal change the PS, the = bis version needs to be a PS too, before it can move to DS at the = earliest 6 months later. Lars= --Apple-Mail-67--528660094 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgyNTA3 MjY1OFowIwYJKoZIhvcNAQkEMRYEFDifdAXr1C7iYwLtmZSHb4IbVgDlMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAHtUk587Z70H4iuvUB7dL5gKCpg7HmiwlpG35mzGFmgOzlO1ifb4 UxrhXkO05PJs8R0Vqy6cVqPShWcSqxYX5NSXW/njT6SnUBDT3AV/EqyMBC3t/H+ISC1NniaTOyeX dD0hPUxBIMfbtSrafNfhORa2MWpKVtrqPlETnWYupED44fxSUuHyUuL3oLdRC/n35/zFRN0a/VlL Tn7FvyVepacR/YvHY/8uG49hP72H+SW/wtIj343DsKquecs4vMmg13OG7LHGcgjZQOeWYlZDf2FQ w5e2PWvCrXD0zYnHNHfXQXd0gjCoRWRGc1Rz+DQ6apNu3312sqvA94tBO6dwLPwAAAAAAAA= --Apple-Mail-67--528660094-- From dwing@cisco.com Wed Aug 25 15:09:58 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF463A6A64; Wed, 25 Aug 2010 15:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.51 X-Spam-Level: X-Spam-Status: No, score=-110.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZKnZ8kFNqKF; Wed, 25 Aug 2010 15:09:57 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 19A903A63C9; Wed, 25 Aug 2010 15:09:57 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,270,1280707200"; d="scan'208";a="578812528" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 25 Aug 2010 22:10:30 +0000 Received: from dwingWS (sjc-vpn4-873.cisco.com [10.21.83.104]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7PMATM3005198; Wed, 25 Aug 2010 22:10:29 GMT From: "Dan Wing" To: , , Date: Wed, 25 Aug 2010 15:10:29 -0700 Message-ID: <0e7b01cb44a2$5454b7a0$fcfe26e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActEok5Ei98zlYfQTuij9lq4TseYww== Content-Language: en-us Cc: Andrew Yourtchenko Subject: [tcpm] Revealing identity of TCP client connection when sharing IPv4 address X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: int-area@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 22:09:58 -0000 Please send replies to int-area@ietf.org Hi. Andrew and I have written two I-D's describing two approaches to solve a problem that occurs when sharing an IPv4 address (NAPT44, NAPT64, HTTP proxy, A+P, dual-IVI, etc.). The abstract is common between the two approaches and summarizes the problem: When an IP address is shared among several subscribers, it is impossible to determine which subscriber has initiated that TCP connection. This memo describes a technique to share the identity of a subscriber that initiated a TCP connection with the TCP server. The proposed method avoids altering the application-level payload and works well with SSL-protected connections. approach 1, new TCP option: http://tools.ietf.org/html/draft-wing-nat-reveal-option approach 2, overload existing TIMESTAMP TSVal option and IP ID: http://tools.ietf.org/html/draft-yourtchenko-nat-reveal-hash We are leaning towards the new TCP option (approach 1). The idea crosses BEHAVE (NAT), INTAREA (address sharing), and TCPM (TCP option). However, to reduce cross-posting and because INTAREA already has a working group document related to address sharing, I propose we discuss the document on the int-area@ietf.org mailing list. Comments and feedback welcome. -d From wwwrun@rfc-editor.org Thu Aug 26 10:01:11 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D950E3A6AE3; Thu, 26 Aug 2010 10:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.047 X-Spam-Level: X-Spam-Status: No, score=-102.047 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3ZI+34IVdN6; Thu, 26 Aug 2010 10:01:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 004703A6AE1; Thu, 26 Aug 2010 10:01:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BF528E06DC; Thu, 26 Aug 2010 10:01:43 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100826170143.BF528E06DC@rfc-editor.org> Date: Thu, 26 Aug 2010 10:01:43 -0700 (PDT) Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 5961 on Improving TCP's Robustness to Blind In-Window Attacks X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 17:01:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5961 Title: Improving TCP's Robustness to Blind In-Window Attacks Author: A. Ramaiah, R. Stewart, M. Dalal Status: Standards Track Stream: IETF Date: August 2010 Mailbox: ananth@cisco.com, rstewart@huawei.com, mdalal@cisco.com Pages: 19 Characters: 44717 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-tcpsecure-13.txt URL: http://www.rfc-editor.org/rfc/rfc5961.txt TCP has historically been considered to be protected against spoofed off-path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32-bit sequence number(s). A combination of increasing window sizes and applications using longer-term connections (e.g., H-323 or Border Gateway Protocol (BGP) [RFC4271]) have left modern TCP implementations more vulnerable to these types of spoofed packet injection attacks. Many of these long-term TCP applications tend to have predictable IP addresses and ports that makes it far easier for the 4-tuple (4-tuple is the same as the socket pair mentioned in RFC 793) to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a TCP segment with the RST bit set, the SYN bit set or data into a TCP connection by systematically guessing the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to abort or cause data corruption. This document specifies small modifications to the way TCP handles inbound segments that can reduce the chances of a successful attack. [STANDARDS TRACK] This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From Xiangsong.Cui@huawei.com Sun Aug 29 20:28:57 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA2F93A68E1 for ; Sun, 29 Aug 2010 20:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.092 X-Spam-Level: * X-Spam-Status: No, score=1.092 tagged_above=-999 required=5 tests=[AWL=-0.827, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d70I8svv+pWa for ; Sun, 29 Aug 2010 20:28:57 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E29CC3A68FA for ; Sun, 29 Aug 2010 20:28:56 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7Y007X64CTNQ@szxga05-in.huawei.com> for tcpm@ietf.org; Mon, 30 Aug 2010 11:29:17 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7Y002YP4CSQV@szxga05-in.huawei.com> for tcpm@ietf.org; Mon, 30 Aug 2010 11:29:17 +0800 (CST) Date: Mon, 30 Aug 2010 11:29:16 +0800 From: Xiangsong Cui To: tcpm@ietf.org Message-id: <004801cb47f3$86ce4080$946ac180$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: ActH84WwYQbx5Y9PQiKJFICkRwqYcA== Subject: [tcpm] Checksum of TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 03:28:58 -0000 Hi Guys, I'm reading RFC793, and in section 3.1, it reads: Checksum: 16 bits The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros. The checksum also covers a *96* bit pseudo header conceptually prefixed to the TCP header. This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length. This gives the TCP protection against misrouted segments. This information is carried in the Internet Protocol and is transferred across the TCP/Network interface in the arguments or results of calls by the TCP on the IP. +--------+--------+--------+--------+ | Source Address | +--------+--------+--------+--------+ | Destination Address | +--------+--------+--------+--------+ | zero | PTCL | TCP Length | +--------+--------+--------+--------+ The TCP Length is the TCP header length plus the data length in octets (this is not an explicitly transmitted quantity, but is computed), and it does not count the *12* octets of the pseudo header. In my impresion, TCP is an IP agnostic protocol, but in the second paragraph, It specifies that "a *96* bit pseudo header"(the first sentence) and "the *12* octets of the pseudo header."(the last sentence), which seems to be coupled with IPv4. Considering TCP over IPv6, should we remove the accurate number from the statement? Such as " The checksum also covers a pseudo header ..." and "it does not count the octets of the pseudo header." Adding a note to this? PS, I believe TCP over IPv6 has been implemented, but I havn't see any standard fix on this issue, if it has been addressed, please tell me where to get the new document, thanks! Regards, Xiangsong From anil.agarwal@viasat.com Mon Aug 30 04:59:14 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7F03A69B2 for ; Mon, 30 Aug 2010 04:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlN8WM2RHMvd for ; Mon, 30 Aug 2010 04:59:13 -0700 (PDT) Received: from viasat.com (hawk.viasat.com [12.198.241.145]) by core3.amsl.com (Postfix) with ESMTP id B02E33A69A1 for ; Mon, 30 Aug 2010 04:58:56 -0700 (PDT) Received: from ([172.31.1.23]) by hawk.viasat.com with ESMTP id 5B7LFJ1.14809199; Mon, 30 Aug 2010 07:55:12 -0400 Received: from VGAEXCH01.hq.corp.viasat.com ([172.31.1.20]) by VGAEXCH02.hq.corp.viasat.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Aug 2010 07:59:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB483A.C518C418" Date: Mon, 30 Aug 2010 07:56:56 -0400 Message-ID: <0B0A20D0B3ECD742AA2514C8DDA3B0650127B25E@VGAEXCH01.hq.corp.viasat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Checksum of TCP Thread-Index: ActH84WwYQbx5Y9PQiKJFICkRwqYcAARuw3H References: <004801cb47f3$86ce4080$946ac180$%cui@huawei.com> From: "Agarwal, Anil" To: "Xiangsong Cui" , X-OriginalArrivalTime: 30 Aug 2010 11:59:17.0358 (UTC) FILETIME=[C5C5F8E0:01CB483A] Subject: Re: [tcpm] Checksum of TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 11:59:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB483A.C518C418 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Xiangsong, =20 RFC 2460, section 8.1 covers this issue. =20 Anil ________________________________ From: tcpm-bounces@ietf.org on behalf of Xiangsong Cui Sent: Sun 8/29/2010 11:29 PM To: tcpm@ietf.org Subject: [tcpm] Checksum of TCP Hi Guys, I'm reading RFC793, and in section 3.1, it reads: Checksum: 16 bits The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros. The checksum also covers a *96* bit pseudo header conceptually prefixed to the TCP header. This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length. This gives the TCP protection against misrouted segments. This information is carried in the Internet Protocol and is transferred across the TCP/Network interface in the arguments or results of calls by the TCP on the IP. +--------+--------+--------+--------+ | Source Address | +--------+--------+--------+--------+ | Destination Address | +--------+--------+--------+--------+ | zero | PTCL | TCP Length | +--------+--------+--------+--------+ The TCP Length is the TCP header length plus the data length in octets (this is not an explicitly transmitted quantity, but is computed), and it does not count the *12* octets of the pseudo header. In my impresion, TCP is an IP agnostic protocol, but in the second paragraph, It specifies that "a *96* bit pseudo header"(the first = sentence) and "the *12* octets of the pseudo header."(the last sentence), which = seems to be coupled with IPv4. Considering TCP over IPv6, should we remove the accurate number from the statement? Such as " The checksum also covers a pseudo header ..." and = "it does not count the octets of the pseudo header." Adding a note to this? PS, I believe TCP over IPv6 has been implemented, but I havn't see any standard fix on this issue, if it has been addressed, please tell me = where to get the new document, thanks! Regards, Xiangsong _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm = =20 ------_=_NextPart_001_01CB483A.C518C418 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [tcpm] Checksum of TCP=0A= =0A= =0A= =0A=
=0A=
Xiangsong,
=0A=
 
=0A=
RFC 2460, section 8.1 = covers this issue.
=0A=
 
=0A=
Anil
=0A=

=0A=
=0A= From: = tcpm-bounces@ietf.org on behalf of Xiangsong Cui
Sent: Sun = 8/29/2010 11:29 PM
To: tcpm@ietf.org
Subject: [tcpm] = Checksum of TCP

=0A=
=0A=

Hi Guys,

I'm reading = RFC793, and in section 3.1, it reads:

  Checksum:  16 = bits

    The checksum field is the 16 bit one's = complement of the one's
    complement sum of all 16 = bit words in the header and text.  If a
    = segment contains an odd number of header and text octets to = be
    checksummed, the last octet is padded on the = right with zeros to
    form a 16 bit word for = checksum purposes.  The pad is not
    = transmitted as part of the segment.  While computing the = checksum,
    the checksum field itself is replaced = with zeros.

    The checksum also covers a *96* = bit pseudo header conceptually
    prefixed to the TCP = header.  This pseudo header contains the = Source
    Address, the Destination Address, the = Protocol, and TCP length.
    This gives the TCP = protection against misrouted segments.  This
    = information is carried in the Internet Protocol and is = transferred
    across the TCP/Network interface in = the arguments or results of
    calls by the TCP on = the = IP.

          &n= bsp;          = +--------+--------+--------+--------+
     &n= bsp;           &nb= sp;   = |           Source = Address          = |
           &n= bsp;         = +--------+--------+--------+--------+
     &n= bsp;           &nb= sp;   |         = Destination Address       = |
           &n= bsp;         = +--------+--------+--------+--------+
     &n= bsp;           &nb= sp;   |  zero  |  PTCL  = |    TCP Length   = |
           &n= bsp;         = +--------+--------+--------+--------+

    &nbs= p; The TCP Length is the TCP header length plus the data length = in
      octets (this is not an explicitly = transmitted quantity, but is
      = computed), and it does not count the *12* octets of the = pseudo
      header.


In my = impresion, TCP is an IP agnostic protocol, but in the = second
paragraph, It specifies that "a *96* bit pseudo header"(the = first sentence)
and "the *12* octets of the pseudo header."(the last = sentence), which seems
to be coupled with IPv4.

Considering = TCP over IPv6, should we remove the accurate number from = the
statement? Such as " The checksum also covers a pseudo header = ..." and "it
does not count the octets of the pseudo header."  = Adding a note to this?

PS, I believe TCP over IPv6 has been = implemented, but I havn't see any
standard fix on this issue, if it = has been addressed, please tell me where
to get the new document, = thanks!


Regards,
Xiangsong



_________________= ______________________________
tcpm mailing = list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

=
------_=_NextPart_001_01CB483A.C518C418-- From touch@isi.edu Mon Aug 30 08:55:05 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAF6B3A67F6 for ; Mon, 30 Aug 2010 08:55:04 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkG7d3p0RkvG for ; Mon, 30 Aug 2010 08:55:02 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id DDB5A3A67F2 for ; Mon, 30 Aug 2010 08:55:01 -0700 (PDT) Received: from [75.217.208.201] (201.sub-75-217-208.myvzw.com [75.217.208.201]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o7UFsvTN010608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Aug 2010 08:55:08 -0700 (PDT) Message-ID: <4C7BD449.7020501@isi.edu> Date: Mon, 30 Aug 2010 08:54:49 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Xiangsong Cui References: <004801cb47f3$86ce4080$946ac180$%cui@huawei.com> In-Reply-To: <004801cb47f3$86ce4080$946ac180$%cui@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o7UFsvTN010608 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Checksum of TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 15:55:05 -0000 On 8/29/2010 8:29 PM, Xiangsong Cui wrote: > Hi Guys, > > I'm reading RFC793, and in section 3.1, it reads: ... > In my impresion, TCP is an IP agnostic protocol, FWIW, it really is not. TCP uses a "socket pair" as a connection identifier, i.e.: source IP address destination IP address source TCP port destination IP port As such, the IP addresses are an instrinsic part of a TCP connection, so TCP cannot exist in the absence of IP - or an emulation thereof. The other two fields of the pseudoheader are: PCTL (transport protocol number - for TCP, always "6") TCP segment length (computed from IP length - IP options) These are already contained in the IP header (explicitly or implicitly), it are not repeated in the TCP header - so instead they are included in the pseudoheader. ... > PS, I believe TCP over IPv6 has been implemented, but I havn't see any > standard fix on this issue, if it has been addressed, As noted, this was defined in RFC 2460, in which IPv6 is defined. Joe From Xiangsong.Cui@huawei.com Mon Aug 30 17:54:54 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50DB63A69F4 for ; Mon, 30 Aug 2010 17:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LE2mnNQImX47 for ; Mon, 30 Aug 2010 17:54:53 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 354663A69EA for ; Mon, 30 Aug 2010 17:54:53 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7Z00410RVYZY@szxga04-in.huawei.com> for tcpm@ietf.org; Tue, 31 Aug 2010 08:55:10 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7Z00JZTRVX1O@szxga04-in.huawei.com> for tcpm@ietf.org; Tue, 31 Aug 2010 08:55:10 +0800 (CST) Date: Tue, 31 Aug 2010 08:55:10 +0800 From: Xiangsong Cui In-reply-to: <4C7BD449.7020501@isi.edu> To: 'Joe Touch' Message-id: <002e01cb48a7$29b27290$7d1757b0$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: ActIW8e12H6FwJKrTbyW9fX/HK58BAASyMrA References: <004801cb47f3$86ce4080$946ac180$%cui@huawei.com> <4C7BD449.7020501@isi.edu> Cc: tcpm@ietf.org Subject: Re: [tcpm] Checksum of TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 00:54:54 -0000 I see, thank you Joe and Anil! Regards, Xiangsong > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Monday, August 30, 2010 11:55 PM > To: Xiangsong Cui > Cc: tcpm@ietf.org > Subject: Re: [tcpm] Checksum of TCP > > > > On 8/29/2010 8:29 PM, Xiangsong Cui wrote: > > Hi Guys, > > > > I'm reading RFC793, and in section 3.1, it reads: > ... > > In my impresion, TCP is an IP agnostic protocol, > > FWIW, it really is not. TCP uses a "socket pair" as a connection > identifier, i.e.: > source IP address > destination IP address > source TCP port > destination IP port > > As such, the IP addresses are an instrinsic part of a TCP connection, so > TCP cannot exist in the absence of IP - or an emulation thereof. The > other two fields of the pseudoheader are: > PCTL (transport protocol number - for TCP, always "6") > TCP segment length (computed from IP length - IP options) > > These are already contained in the IP header (explicitly or implicitly), > it are not repeated in the TCP header - so instead they are included in > the pseudoheader. > > ... > > PS, I believe TCP over IPv6 has been implemented, but I havn't see any > > standard fix on this issue, if it has been addressed, > > As noted, this was defined in RFC 2460, in which IPv6 is defined. > > Joe