From tsvwg-admin@ietf.org Thu Aug 24 06:42:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14177 for ; Thu, 24 Aug 2000 06:42:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28601; Thu, 24 Aug 2000 06:37:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28570 for ; Thu, 24 Aug 2000 06:37:18 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14100; Thu, 24 Aug 2000 06:37:20 -0400 (EDT) Message-Id: <200008241037.GAA14100@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: tsvwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 24 Aug 2000 06:37:20 -0400 Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-limited-xmit-00.txt Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Enhancing TCP's Loss Recovery Using Limited Transmit Author(s) : M. Allman, H. Balakrishnan, S. Floyd Filename : draft-ietf-tsvwg-limited-xmit-00.txt Pages : 7 Date : 23-Aug-00 This document proposes a new TCP mechanism that can be used to more effectively recover lost segments when a connection's congestion window is small, or when a large number of segments are lost in a single transmission window. The 'Limited Transmit' algorithm calls for sending a new data segment in response to each of the first two duplicate acknowledgments that arrive at the sender. Transmitting these segments increases the probability that TCP can recover from a single lost segment using the fast retransmit algorithm, rather than using a costly retransmission timeout. Limited Transmit can be used both in conjunction with, and in the absence of, the TCP selective acknowledgment (SACK) mechanism [RFC2018]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-limited-xmit-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-limited-xmit-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-limited-xmit-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000823114110.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-limited-xmit-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-limited-xmit-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000823114110.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Mon Aug 28 14:04:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17236 for ; Mon, 28 Aug 2000 14:04:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15240; Mon, 28 Aug 2000 13:56:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15209 for ; Mon, 28 Aug 2000 13:56:45 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17063 for ; Mon, 28 Aug 2000 13:56:44 -0400 (EDT) Received: from guns (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA29694; Mon, 28 Aug 2000 13:56:44 -0400 (EDT) Message-Id: <200008281756.NAA29694@lombok-fi.lerc.nasa.gov> To: tsvwg@ietf.org Cc: "Sally Floyd" , hari@lcs.mit.edu From: Mark Allman Reply-To: mallman@grc.nasa.gov Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: It's Good to Be King Date: Mon, 28 Aug 2000 13:56:44 -0400 Subject: [Tsvwg] limited transmit i-d Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Sally, Hair and I revised the I-D on enhanced loss recovery for TCP connections using small congestion windows (or experiencing a large amount of ACK loss) that we presented at the recent IETF meeting. The new draft only contains a specification of the Limited Transmit mechanism (sending new data segments on the arrival of the first and second duplicate ACKs). The portion of the document that proposed reducing the duplicate ACK theshold needed to trigger fast retransmit has been removed. Our understanding is that the consensus of the room is that Limited Transmit should be forwarded as proposed standard. We would like to encourage folks to look at the new version of the draft and voice any concerns fairly soon. Unless there are large reservations voiced, we'll request the chairs do a WG last call and forward the document to the IESG fairly soon. The new version of the document is: Mark Allman, Hari Balakrishnan, Sally Floyd. Enhancing TCP's Loss Recovery Using Limited Transmit, August 2000. Internet-Draft draft-ietf-tsvwg-limited-xmit-00.txt (work in progress). ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-limited-xmit-00.txt Thanks! allman --- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Tue Aug 29 09:18:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17041 for ; Tue, 29 Aug 2000 09:18:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01577; Tue, 29 Aug 2000 09:14:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01548 for ; Tue, 29 Aug 2000 09:14:05 -0400 (EDT) Received: from nt1.novaera.com.br ([200.249.200.35]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16911 for ; Tue, 29 Aug 2000 09:13:55 -0400 (EDT) Received: from dial40.novaera.com.br (dial40.novaera.com.br [200.249.201.106]) by nt1.novaera.com.br (NTMail 3.03.0017/1.adcr) with ESMTP id pa550825 for ; Mon, 28 Aug 2000 19:30:22 -0200 Message-ID: <39AAE95C.CD6EF1BA@cin.ufpe.br> Date: Mon, 28 Aug 2000 19:36:12 -0300 From: Rogerio de Carvalho Andrade Organization: Embrapa - DIN (http://www.embrapa.br) / UFPE - CIn (http://www.cin.ufpe.br) X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: tsvwg@ietf.org CC: qos-l@cin.ufpe.br Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Q. about "Limited Transmit" algorithm Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit draft-ietf-tsvwg-limited-xmit-00.txt proposes this algorithm as a new TCP behavior. In my understanding, transmission of a new segment was already permited by RFC2581, though in a small cwnd... Isn't it true that the receipt of a DUPACK turn down the amount of outstanding data (FlightSize) ??? Isn't it accurate trusting that DUPACKs means that one more segment has left the network ??? If yes, a new segment can be sent after a DUPACK arrival and before increasing cwnd (cwnd is increased only at arrival of non-dupacks), as proposed in that draft... I'm not sure about security considerations (regarding dupacks be generate improperly). Could someone clarify it? TIA, Rogerio. _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Tue Aug 29 09:56:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17997 for ; Tue, 29 Aug 2000 09:56:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02051; Tue, 29 Aug 2000 09:48:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02022 for ; Tue, 29 Aug 2000 09:48:50 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17838 for ; Tue, 29 Aug 2000 09:48:47 -0400 (EDT) Received: from guns (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA18711; Tue, 29 Aug 2000 09:42:16 -0400 (EDT) Message-Id: <200008291342.JAA18711@lombok-fi.lerc.nasa.gov> To: Rogerio de Carvalho Andrade From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: tsvwg@ietf.org, qos-l@cin.ufpe.br Subject: Re: [Tsvwg] Q. about "Limited Transmit" algorithm Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Lightning Crashes Date: Tue, 29 Aug 2000 09:42:16 -0400 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org > In my understanding, transmission of a new segment was already > permited by RFC2581, though in a small cwnd... That is not the *intent* of RFC 2581. There may have been some loss between the intent and the text, but I think it is fairly clear. > Isn't it true that the receipt of a DUPACK turn down the amount of > outstanding data (FlightSize) ??? No. FlightSize is defined in RFC 2581 as: FLIGHT SIZE: The amount of data that has been sent but not yet acknowledged. A duplicate ACK (by definition) does not acknowledge new data and therefore cannot decrease the FlightSize. As you mention, duplicate ACKs are used during fast recovery as an indication that something has left the network. But, this algorithm is the exception, not the rule. In fast recovery we are not limited by the FlightSize, but rather governed by an artificially infated cwnd, which is based on duplicate ACKs. I hope that clarifies things. allman --- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Tue Aug 29 17:27:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01219 for ; Tue, 29 Aug 2000 17:27:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07402; Tue, 29 Aug 2000 17:22:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07375 for ; Tue, 29 Aug 2000 17:22:10 -0400 (EDT) Received: from nt1.novaera.com.br ([200.249.200.35]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01175 for ; Tue, 29 Aug 2000 17:22:02 -0400 (EDT) Received: from dial52.novaera.com.br (dial52.novaera.com.br [200.249.201.118]) by nt1.novaera.com.br (NTMail 3.03.0017/1.adcr) with ESMTP id ka551418 for ; Tue, 29 Aug 2000 18:23:33 -0200 Message-ID: <39AC2950.978BB7D2@cin.ufpe.br> Date: Tue, 29 Aug 2000 18:21:20 -0300 From: Rogerio de Carvalho Andrade Organization: Embrapa - DIN (http://www.embrapa.br) / UFPE - CIn (http://www.cin.ufpe.br) X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: mallman@grc.nasa.gov CC: tsvwg@ietf.org, qos-l@cin.ufpe.br Subject: Re: [Tsvwg] Q. about "Limited Transmit" algorithm References: <200008291342.JAA18711@lombok-fi.lerc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Thanks, Allman. Your explanation was absolutely clear. RFC 2581 (as well as RFC 2582) does not explicitly say it but it can easily inferred (mostly in the outlined definition of Flight Size). I've got confused by that other discussion in the end2end-interest list, where Andrei Gurtov guessed wrong the Linux 2.3x behavior, at the transmission of a new segment in response to a partial ACK (or either a DUPACK). Differently to in your recent draft, we were already in the Fast Recovery algorithm, that time. In FR, DUPACKs and partial ACKs can trigger a new segment transmission (if cwnd and rwnd permit). As I could understand, "Limited Transmit" algorithm, proposed in your draft, aims to permit a new segment sending BEFORE enter in FR, isn't it? Specifically, your goal is to make it possible to enter in FR, if I'm not wrong... Cheers, Rogerio. Mark Allman wrote: > > > In my understanding, transmission of a new segment was already > > permited by RFC2581, though in a small cwnd... > > That is not the *intent* of RFC 2581. There may have been some loss > between the intent and the text, but I think it is fairly clear. > > > Isn't it true that the receipt of a DUPACK turn down the amount of > > outstanding data (FlightSize) ??? > > No. FlightSize is defined in RFC 2581 as: > > FLIGHT SIZE: The amount of data that has been sent but not yet > acknowledged. > > A duplicate ACK (by definition) does not acknowledge new data and > therefore cannot decrease the FlightSize. > > As you mention, duplicate ACKs are used during fast recovery as an > indication that something has left the network. But, this algorithm > is the exception, not the rule. In fast recovery we are not limited > by the FlightSize, but rather governed by an artificially infated > cwnd, which is based on duplicate ACKs. > > I hope that clarifies things. > > allman > > --- > http://roland.grc.nasa.gov/~mallman/ -- Rogerio de Carvalho Andrade Analista de Suporte - Embrapa - DIN mailto:Rogerio.Andrade@Embrapa.br Mestrando em Ciencia da Computacao - UFPE - DI mailto:Rogerio@di.ufpe.br _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Wed Aug 30 09:09:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28089 for ; Wed, 30 Aug 2000 09:09:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22343; Wed, 30 Aug 2000 08:58:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22314 for ; Wed, 30 Aug 2000 08:58:26 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27654 for ; Wed, 30 Aug 2000 08:58:27 -0400 (EDT) Received: from guns (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA17887; Wed, 30 Aug 2000 08:57:58 -0400 (EDT) Message-Id: <200008301257.IAA17887@lombok-fi.lerc.nasa.gov> To: Rogerio de Carvalho Andrade From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: tsvwg@ietf.org, qos-l@cin.ufpe.br Subject: Re: [Tsvwg] Q. about "Limited Transmit" algorithm Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Centerfold Date: Wed, 30 Aug 2000 08:57:58 -0400 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org > As I could understand, "Limited Transmit" algorithm, proposed in > your draft, aims to permit a new segment sending BEFORE enter in > FR, isn't it? Yes. > Specifically, your goal is to make it possible to enter in FR, if > I'm not wrong... Exactly. allman _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg