From tcpm-bounces@ietf.org Tue May 6 06:13:33 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 558B628C13A; Tue, 6 May 2008 06:13:33 -0700 (PDT) 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 1F4383A6FDD for ; Tue, 6 May 2008 06:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.251 X-Spam-Level: * X-Spam-Status: No, score=1.251 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 t-S4caWGPho9 for ; Tue, 6 May 2008 06:13:23 -0700 (PDT) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id D180528C388 for ; Tue, 6 May 2008 06:13:11 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA181579561; Tue, 6 May 2008 15:12:41 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA15671; Tue, 6 May 2008 15:12:39 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200805061312.PAA15671@TR-Sys.de> To: mallman@icir.org, vern@icir.org, eblanton@cs.purdue.edu Date: Tue, 6 May 2008 15:12:39 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Cc: tcpm@ietf.org Subject: [tcpm] draft-ietf-tcpm-rfc2581bis-04 -- a few editorials 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-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Taking another round on the updated 2581bis draft, draft-ietf-tcpm-rfc2581bis-04, and reconsidering the flow of arguments, I found a few small editorial issues that still could/should be improved. (1) Section 1, 2nd paragraph Typo: s/in turned/in turn/ (2) Section 1, 3rd paragraph The first paragraph names the four 'classical' congestion control algorithms. The third paragraph resumes the discussion, and arguably the algorithm for restarting after a long idle period could be conceived as a fifth congestion control algorithm. The draft does not do that explicitely, and I do not request that. But to make the reasoning more clear, I suggest to replace "the" by "these" in the first line of the third paragraph: In addition to specifying the congestion control algorithms, this document specifies what TCP connections should do after a relatively long idle period, [...] --- vv | In addition to specifying these congestion control algorithms, this document specifies what TCP connections should do after a relatively long idle period, [...] (3) Section 1, 4th paragraph I do not have at hand the particular editions of the "TCP/IP Illustrated" books refered to by [Ste94] and [WS95], but I have concerns regarding whether or not these good old opusses in fact do precisely reflect the significantly updated recommendation given in the last paragraph of Section 4.1, namely to return to slow start after an idle period if "TCP has not *sent* data in an interval exceeding the retransmision timeout". (emphasis added) The current position of this 4th paragraph in Section 1, below the 'announcement' of the 'after-idle-restart' algorithm might lead the reader to the conclusion that these books already contain, and show the implementation of, this revised algorithm. If that is not true, and to avoid this possible misconception, it would perhaps be wise to shuffle the paragraphs in Section 1 to position the current 4th paragraph immediately below the first paragraph. (On this case, the change in item (2) above becomes even more important for clarity.) (4) Section 1 -- further re-shuffling During the above considerations I got the impression that it also might be prudent for the sake of clarity in the reasoning to move the second paragraph, "This document obsoletes ..." to behind the three paragraphs dealing with the prevalent components of the document, to immediately above the second-to-last paragraph, "This document is organized as follows. ..." In other words: Taking (3) and (4) together, my net recommendation is to swap the second and the fourth paragraph in Section 1. (5) Section 3.1 -- additional instance of clarification Subsidiary to one of the recent clarifications adopted by the draft in a couple of places, I suggest once more to re-state that clarification of "outstanding" immediately below formula (4), e.g. by changing: where, as discussed above, FlightSize is the amount of outstanding data in the network. --- where, as discussed above, FlightSize is the amount of outstanding (i.e., not yet cumulatively acknowledged) data in the network. (6) Section 6 I suggest to harmonize the text, generally talking about RFC 2581 in past tense. To this end, please change: ... The intention of [RFC2581] is to not change ... --- ... The intention of [RFC2581] was to not change ... Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 8 18:01:14 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 081BA3A6899; Thu, 8 May 2008 18:01:14 -0700 (PDT) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 65534) id 3A5403A6F1A; Thu, 8 May 2008 16:16:35 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Old-Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B651C3A6ED7 for ; Thu, 8 May 2008 15:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 24hwp15FlgDN for ; Thu, 8 May 2008 15:56:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AB76E3A6ED4 for ; Thu, 8 May 2008 15:56:11 -0700 (PDT) Received: from [63.168.31.209] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JuF1u-000ABt-5W; Thu, 08 May 2008 22:56:07 +0000 Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id 914572BE21; Thu, 8 May 2008 18:56:00 -0400 (EDT) Received: by colt.internal (Postfix, from userid 3000) id 6B1DC2863B; Thu, 8 May 2008 18:55:58 -0400 (EDT) Date: Thu, 8 May 2008 18:55:58 -0400 From: Ethan Blanton To: Alfred =?iso-8859-1?Q?H=F6nes?= Message-ID: <20080508225556.GA27334@elb.elitists.net> References: <200805061312.PAA15671@TR-Sys.de> MIME-Version: 1.0 In-Reply-To: <200805061312.PAA15671@TR-Sys.de> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.13 (2006-08-11) X-TMDA-Confirmed: Thu, 08 May 2008 16:16:36 -0700 X-Mailman-Approved-At: Thu, 08 May 2008 17:59:36 -0700 Cc: tcpm@ietf.org, vern@icir.org, mallman@icir.org Subject: Re: [tcpm] draft-ietf-tcpm-rfc2581bis-04 -- a few editorials 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-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0741554197==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0741554197== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline --liOOAslEiF7prFVr Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alfred H=F6nes spake unto us the following wisdom: > Taking another round on the updated 2581bis draft, > draft-ietf-tcpm-rfc2581bis-04, > and reconsidering the flow of arguments, I found a few > small editorial issues that still could/should be improved. Alfred, Thank you very much for taking the time to review this document again. Your comments look eminently reasonable; we will consider each of them individually and get back to you (and the WG) with the changes soon. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 --liOOAslEiF7prFVr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFII4T8r9kA9Ig8HBQRAjupAKCbyjQR58ROxXwFN7rwWgQxCrSiFQCeN5j1 9yrSfPa6s1pmhIsRdLbHxDc= =GeIK -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- --===============0741554197== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0741554197==-- From tcpm-bounces@ietf.org Sat May 10 18:11:36 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14F63A6A29; Sat, 10 May 2008 18:11:36 -0700 (PDT) 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 C809E3A6A27 for ; Sat, 10 May 2008 18:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.445 X-Spam-Level: X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[AWL=0.855, BAYES_00=-2.599, 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 k5haHOy2dWnq for ; Sat, 10 May 2008 18:11:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB7E83A69F7 for ; Sat, 10 May 2008 18:11:33 -0700 (PDT) Received: from [63.168.31.209] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jv05u-000HMl-S8; Sun, 11 May 2008 01:11:28 +0000 Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id F03822BE21; Sat, 10 May 2008 21:11:10 -0400 (EDT) Received: by colt.internal (Postfix, from userid 3000) id C9D982863E; Sat, 10 May 2008 21:11:08 -0400 (EDT) Date: Sat, 10 May 2008 21:11:08 -0400 From: Ethan Blanton To: Alfred =?iso-8859-1?Q?H=F6nes?= Message-ID: <20080511011107.GA12264@elb.elitists.net> References: <200805061312.PAA15671@TR-Sys.de> MIME-Version: 1.0 In-Reply-To: <200805061312.PAA15671@TR-Sys.de> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.13 (2006-08-11) Cc: tcpm@ietf.org, vern@icir.org, mallman@icir.org Subject: Re: [tcpm] draft-ietf-tcpm-rfc2581bis-04 -- a few editorials 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: , Content-Type: multipart/mixed; boundary="===============0779593262==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0779593262== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alfred, The following are our responses to your comments. If there are no remaining technical issues with this document, we consider it finished. Thank you for your input. Ethan > (1) Section 1, 2nd paragraph >=20 > Typo: s/in turned/in turn/ Fixed. > (2) Section 1, 3rd paragraph > In addition to specifying the congestion control algorithms, this > document specifies what TCP connections should do after a relatively > long idle period, [...] > --- vv > | In addition to specifying these congestion control algorithms, this > document specifies what TCP connections should do after a relatively > long idle period, [...] Changed. > In other words: Taking (3) and (4) together, my net recommendation > is to swap the second and the fourth paragraph in Section 1. Changed. > (5) Section 3.1 -- additional instance of clarification >=20 > Subsidiary to one of the recent clarifications adopted by the > draft in a couple of places, I suggest once more to re-state that > clarification of "outstanding" immediately below formula (4), > e.g. by changing: >=20 > where, as discussed above, FlightSize is the amount of outstanding > data in the network. > --- > where, as discussed above, FlightSize is the amount of outstanding > (i.e., not yet cumulatively acknowledged) data in the network. This remains unchanged. We feel it is clear enough as written, particularly in conjunction with other TCP documents. > (6) Section 6 >=20 > I suggest to harmonize the text, generally talking about RFC 2581 > in past tense. To this end, please change: >=20 > ... The intention of [RFC2581] is to not change ... > --- > ... The intention of [RFC2581] was to not change ... Somewhat more extensive changes were made here. The paragraph in question now reads: [RFC2001] was extensively rewritten editorially and it is not feasible to itemize the list of changes between [RFC2001] and [RFC2581]. The intention of [RFC2581] was to not change any of the recommendations given in [RFC2001], but to further clarify cases that were not discussed in detail in [RFC2001]. Specifically, [RFC2581] suggested what TCP connections should do after a relatively long idle period, as well as specified and clarified some of the issues pertaining to TCP ACK generation. Finally, the allowable upper bound for the initial congestion window was raised from one to two segments. --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIJkerr9kA9Ig8HBQRAqLkAJ0WiiQ8qySJVnuStACxNF6sYQansACgg6fD yG/itN8MZMDNg7mW7VbiuF4= =Llnw -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- --===============0779593262== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0779593262==-- From tcpm-bounces@ietf.org Fri May 23 12:38:35 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF1228C2A1; Fri, 23 May 2008 12:38:35 -0700 (PDT) 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 D96E728C287 for ; Fri, 23 May 2008 12:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 2fOh7r8L+DbM for ; Fri, 23 May 2008 12:38:33 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id A47E228C127 for ; Fri, 23 May 2008 12:38:32 -0700 (PDT) Received: from wrl-76.cs.helsinki.fi (wrl-76.cs.helsinki.fi [128.214.166.196]) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 23 May 2008 22:38:27 +0300 id 00087BFB.48371D33.00006322 Received: by wrl-76.cs.helsinki.fi (Postfix, from userid 3011) id B52183444B; Fri, 23 May 2008 22:38:27 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by wrl-76.cs.helsinki.fi (Postfix) with ESMTP id B20863401C; Fri, 23 May 2008 22:38:27 +0300 (EEST) Date: Fri, 23 May 2008 22:38:27 +0300 (EEST) From: Markku Kojo To: tcpm@ietf.org In-Reply-To: <20080511011107.GA12264@elb.elitists.net> Message-ID: References: <200805061312.PAA15671@TR-Sys.de> <20080511011107.GA12264@elb.elitists.net> Mime-Version: 1.0 Cc: Ethan Blanton , vern@icir.org, mallman@icir.org Subject: [tcpm] draft-ietf-tcpm-rfc2581bis-04 feedback 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org I finally took a closer look into the latest version of rfc2581bis. It seems to me that it sufficiently covers the earlier explicit comments that I made, including the usage of FlightSize in equation 4 when limited transmit is in use. It seems, however, that using FlightSize as defined in the document still is problematic also in other cases where the actual amount of outstanding data in the network differs from FlightSize as I originally hinted. Example scenario: TCP sender is in normal state and cwnd = FlightSize = 16 MSS. First two segments in the window are lost, no other data or ACK segments are lost. 1) On the arrival of 1st and 2nd dupack, the TCP sender transmits a new data segment on each dupack FlightSize = 18 2) When the 3rd dupack arrives: 1st unacknowledged segment is fast rexmitted ssthresh <- 8, cwnd <- 11 3) On arrival of each subsequent dupack cwnd is increased: after 5 additional dupacks have arrived, TCP sender starts injecting new data segments in to the network, one data segment on each subsequent dupack This inflates FlightSize 4) After all 16 dupacks have arrived -> FlightSize = 24 5) Cumulative Ack for fast rexmitted segment arrives: cwnd <- ssthresh = 8, FlightSize = 23, but the correct estimate of outstanding segments in the network is 8 (or 10 if we consider that the rexmitted segment and the 2nd lost segment are still in flight) 6) RTO expires for the 2nd lost segment (which is now the first unacknowledged segment): According to equation 4 TCP sender calculates new value for ssthresh ssthresh <- 23/2 yielding new ssthresh > current ssthresh which is not correct, I think. Alternatively: 6) The eight new data segments transmitted during the fast recovery will trigger further dupacks (8 dupacks): if the 3rd dupack arrives before RTO expires, TCP sender enters fast retransmit again and ssthresh <- ~11, cwnd <- ~14 When the cumulative Ack for the 2nd rexmitted segment arrives cwnd <- ssthresh = 11 which again is more than allowed. In addition to the example given above and in general, using FlightSize in equation 4 potentially yields wrong outcome if TCP sender is in an earlier loss recovery when RTO expires - either in Fast Recovery or in RTO recovery and RTO expires for another segment (not for the same RTO-ed segment). The current text in the document "When a TCP sender detects segment loss using the retransmission timer and the given segment has not yet been retransmitted, the value of ssthresh MUST be set to no more than the value given in equation 4: ssthresh = max (FlightSize / 2, 2*SMSS) (4)" literally prevents the TCP sender from using the equation 4 for such cases (RTO on fast rexmitted segment or RTO on segment rexmitted during RTO recovery), but I think this was not the original intent for the text modification from RFC 2581. Instead, the intent was to preclude the use of equation 4 only when RTO expires again for the RTO-ed segment. Thanks, /Markku _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 23 12:49:00 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94ECD28C2E1; Fri, 23 May 2008 12:49:00 -0700 (PDT) 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 4C11428C2E1 for ; Fri, 23 May 2008 12:49:00 -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 xvcPz8fQqj2Y for ; Fri, 23 May 2008 12:48:59 -0700 (PDT) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 221EC28C2A1 for ; Fri, 23 May 2008 12:48:57 -0700 (PDT) Received: from [10.1.1.54] ([10.1.1.54]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id m4NJkc4m052486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 23 May 2008 15:46:38 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=lakerest; t=1211571998; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=gncNnWoRg3erjkpPSxSMzSfb49+1xvTr9LPPX1cL4tPpQ1W0HhH3hLL ROVrXOcH8LOr3+LpzV5/WKYIvHL4NnQ== Message-Id: <24EE6FA7-CE4D-406F-8F4E-9A0DA621AB01@lakerest.net> From: Randall Stewart To: Markku Kojo In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 23 May 2008 15:46:37 -0400 References: <200805061312.PAA15671@TR-Sys.de> <20080511011107.GA12264@elb.elitists.net> X-Mailer: Apple Mail (2.919.2) Cc: Ethan Blanton , tcpm@ietf.org, vern@icir.org, mallman@icir.org Subject: Re: [tcpm] draft-ietf-tcpm-rfc2581bis-04 feedback 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Markku: You are a bit late... RFC4960 is long out... We are no longer in a BIS period... I will look at your comments ... but thats my first off the cuff response ... R On May 23, 2008, at 3:38 PM, Markku Kojo wrote: > I finally took a closer look into the latest version of > rfc2581bis. It seems to me that it sufficiently covers > the earlier explicit comments that I made, including the > usage of FlightSize in equation 4 when limited transmit is > in use. > > It seems, however, that using FlightSize as defined in > the document still is problematic also in other cases > where the actual amount of outstanding data in the network > differs from FlightSize as I originally hinted. > > Example scenario: > > TCP sender is in normal state and cwnd = FlightSize = 16 MSS. > First two segments in the window are lost, no other data > or ACK segments are lost. > > 1) On the arrival of 1st and 2nd dupack, the TCP > sender transmits a new data segment on each dupack > > FlightSize = 18 > > 2) When the 3rd dupack arrives: > 1st unacknowledged segment is fast rexmitted > ssthresh <- 8, cwnd <- 11 > > 3) On arrival of each subsequent dupack cwnd is increased: > after 5 additional dupacks have arrived, TCP sender > starts injecting new data segments in to the network, > one data segment on each subsequent dupack > > This inflates FlightSize > > 4) After all 16 dupacks have arrived -> FlightSize = 24 > > 5) Cumulative Ack for fast rexmitted segment arrives: > cwnd <- ssthresh = 8, FlightSize = 23, but > the correct estimate of outstanding segments in the > network is 8 (or 10 if we consider that the rexmitted > segment and the 2nd lost segment are still in flight) > > 6) RTO expires for the 2nd lost segment (which is now the > first unacknowledged segment): > > According to equation 4 TCP sender calculates new > value for ssthresh > > ssthresh <- 23/2 > > yielding new ssthresh > current ssthresh which > is not correct, I think. > > Alternatively: > > 6) The eight new data segments transmitted during the fast > recovery will trigger further dupacks (8 dupacks): > if the 3rd dupack arrives before RTO expires, TCP > sender enters fast retransmit again and > > ssthresh <- ~11, cwnd <- ~14 > > When the cumulative Ack for the 2nd rexmitted segment > arrives > > cwnd <- ssthresh = 11 > > which again is more than allowed. > > > In addition to the example given above and in general, > using FlightSize in equation 4 potentially yields wrong > outcome if TCP sender is in an earlier loss recovery > when RTO expires - either in Fast Recovery or in RTO > recovery and RTO expires for another segment (not for the > same RTO-ed segment). > > The current text in the document > > "When a TCP sender detects segment loss using the retransmission > timer and the given segment has not yet been retransmitted, the > value of ssthresh MUST be set to no more than the value given > in equation 4: > > ssthresh = max (FlightSize / 2, 2*SMSS) (4)" > > literally prevents the TCP sender from using the equation 4 > for such cases (RTO on fast rexmitted segment or RTO on > segment rexmitted during RTO recovery), but I think this > was not the original intent for the text modification > from RFC 2581. Instead, the intent was to preclude the use > of equation 4 only when RTO expires again for the RTO-ed > segment. > > > Thanks, > > /Markku > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0369 (direct) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 23 12:50:26 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42ED128C300; Fri, 23 May 2008 12:50:26 -0700 (PDT) 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 5FDFA28C2EB for ; Fri, 23 May 2008 12:50:21 -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 R58d3ryqLUFX for ; Fri, 23 May 2008 12:50:20 -0700 (PDT) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 990E728C2A1 for ; Fri, 23 May 2008 12:50:19 -0700 (PDT) Received: from [10.1.1.54] ([10.1.1.54]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id m4NJmCoT052531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 23 May 2008 15:48:12 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=lakerest; t=1211572092; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=ShW4KeDjOiYK2lbdUa/uItIev9w301jCKMT3HuuQHehDALNrO+0ZP+7 PIeDEf7RM/A9XYqVF3hdpsgI67y44sg== Message-Id: <25C39084-03B1-40B3-9B06-AEEA858C72C3@lakerest.net> From: Randall Stewart To: Markku Kojo In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 23 May 2008 15:48:12 -0400 References: <200805061312.PAA15671@TR-Sys.de> <20080511011107.GA12264@elb.elitists.net> X-Mailer: Apple Mail (2.919.2) Cc: Ethan Blanton , tcpm@ietf.org, vern@icir.org, mallman@icir.org Subject: Re: [tcpm] draft-ietf-tcpm-rfc2581bis-04 feedback 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Never mind.. I see you are not talking about RFC2960.. but 2581.. opps.. Hmm.. I wonder why my filter did not send this to my tcpm box.. Never mind my previous response :-0 R On May 23, 2008, at 3:38 PM, Markku Kojo wrote: > I finally took a closer look into the latest version of > rfc2581bis. It seems to me that it sufficiently covers > the earlier explicit comments that I made, including the > usage of FlightSize in equation 4 when limited transmit is > in use. > > It seems, however, that using FlightSize as defined in > the document still is problematic also in other cases > where the actual amount of outstanding data in the network > differs from FlightSize as I originally hinted. > > Example scenario: > > TCP sender is in normal state and cwnd = FlightSize = 16 MSS. > First two segments in the window are lost, no other data > or ACK segments are lost. > > 1) On the arrival of 1st and 2nd dupack, the TCP > sender transmits a new data segment on each dupack > > FlightSize = 18 > > 2) When the 3rd dupack arrives: > 1st unacknowledged segment is fast rexmitted > ssthresh <- 8, cwnd <- 11 > > 3) On arrival of each subsequent dupack cwnd is increased: > after 5 additional dupacks have arrived, TCP sender > starts injecting new data segments in to the network, > one data segment on each subsequent dupack > > This inflates FlightSize > > 4) After all 16 dupacks have arrived -> FlightSize = 24 > > 5) Cumulative Ack for fast rexmitted segment arrives: > cwnd <- ssthresh = 8, FlightSize = 23, but > the correct estimate of outstanding segments in the > network is 8 (or 10 if we consider that the rexmitted > segment and the 2nd lost segment are still in flight) > > 6) RTO expires for the 2nd lost segment (which is now the > first unacknowledged segment): > > According to equation 4 TCP sender calculates new > value for ssthresh > > ssthresh <- 23/2 > > yielding new ssthresh > current ssthresh which > is not correct, I think. > > Alternatively: > > 6) The eight new data segments transmitted during the fast > recovery will trigger further dupacks (8 dupacks): > if the 3rd dupack arrives before RTO expires, TCP > sender enters fast retransmit again and > > ssthresh <- ~11, cwnd <- ~14 > > When the cumulative Ack for the 2nd rexmitted segment > arrives > > cwnd <- ssthresh = 11 > > which again is more than allowed. > > > In addition to the example given above and in general, > using FlightSize in equation 4 potentially yields wrong > outcome if TCP sender is in an earlier loss recovery > when RTO expires - either in Fast Recovery or in RTO > recovery and RTO expires for another segment (not for the > same RTO-ed segment). > > The current text in the document > > "When a TCP sender detects segment loss using the retransmission > timer and the given segment has not yet been retransmitted, the > value of ssthresh MUST be set to no more than the value given > in equation 4: > > ssthresh = max (FlightSize / 2, 2*SMSS) (4)" > > literally prevents the TCP sender from using the equation 4 > for such cases (RTO on fast rexmitted segment or RTO on > segment rexmitted during RTO recovery), but I think this > was not the original intent for the text modification > from RFC 2581. Instead, the intent was to preclude the use > of equation 4 only when RTO expires again for the RTO-ed > segment. > > > Thanks, > > /Markku > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0369 (direct) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm