From mailnull@www1.ietf.org Sat Mar 1 21:02:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22558 for ; Sat, 1 Mar 2003 21:02:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h222C5E17849 for tsvwg-archive@odin.ietf.org; Sat, 1 Mar 2003 21:12:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h222Bip17841; Sat, 1 Mar 2003 21:11:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h22274p16959 for ; Sat, 1 Mar 2003 21:07:04 -0500 Received: from merlot.juniper.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22275; Sat, 1 Mar 2003 20:57:16 -0500 (EST) Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h221xBS13041; Sat, 1 Mar 2003 17:59:11 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h221xAY43658; Sat, 1 Mar 2003 17:59:11 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Sat, 1 Mar 2003 17:59:10 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org, "" , "" , "" , "" Message-ID: <20030301174430.O43585@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Tsvwg] RSVP change document Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Hi All, The current venue for discussing draft-kompella-rsvp-change-00.txt (IANA Considerations and change process for RSVP) will be in the TSVWG (Thu 13:00-15:00 -- if not, I hope either the TSV ADs will correct me. For now, let's limit the discussion to the tsvwg mailing list. Kireeti. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat Mar 1 21:05:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22753 for ; Sat, 1 Mar 2003 21:05:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h222EgR18401 for tsvwg-archive@odin.ietf.org; Sat, 1 Mar 2003 21:14:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h222EVp18293; Sat, 1 Mar 2003 21:14:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h222Cdp17877 for ; Sat, 1 Mar 2003 21:12:39 -0500 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22572 for ; Sat, 1 Mar 2003 21:02:51 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.6/8.12.2) id h2224RSe010090; Sat, 1 Mar 2003 21:04:27 -0500 (EST) Date: Sat, 1 Mar 2003 21:04:27 -0500 (EST) From: Scott Bradner Message-Id: <200303020204.h2224RSe010090@newdev.harvard.edu> To: ccamp@ops.ietf.org, kireeti@juniper.net, mpls@uu.net, nsis@ietf.org, rsvp@ISI.EDU, tsvwg@ietf.org Cc: Jon.peterson@neustar.com, mankin@psg.com In-Reply-To: <20030301174430.O43585@kummer.juniper.net> Subject: [Tsvwg] Re: [Rsvp] RSVP change document Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , the tsvwg list will be the main venue I will talk with Allison to see if there is time in teh tsvwg meeting to start the dicussion Scott --- From rsvp-admin@mailman.isi.edu Sat Mar 1 21:00:42 2003 X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs From: Kireeti Kompella To: ccamp@ops.ietf.org, "" , "" , "" , "" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Rsvp] RSVP change document Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Sat, 1 Mar 2003 17:59:10 -0800 (PST) Hi All, The current venue for discussing draft-kompella-rsvp-change-00.txt (IANA Considerations and change process for RSVP) will be in the TSVWG (Thu 13:00-15:00 -- if not, I hope either the TSV ADs will correct me. For now, let's limit the discussion to the tsvwg mailing list. Kireeti. _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sun Mar 2 23:07:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25776 for ; Sun, 2 Mar 2003 23:07:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h234Grk27188 for tsvwg-archive@odin.ietf.org; Sun, 2 Mar 2003 23:16:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h234GHp27158; Sun, 2 Mar 2003 23:16:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h234E8p27071 for ; Sun, 2 Mar 2003 23:14:08 -0500 Received: from pop-2.dnv.wideopenwest.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25751 for ; Sun, 2 Mar 2003 23:03:48 -0500 (EST) Received: from thoth.ir.bbn.com (d53-203-209.clv.wideopenwest.com [64.53.209.203]) by pop-2.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h2349qn19929; Sun, 2 Mar 2003 22:09:52 -0600 Received: from thoth.ir.bbn.com (localhost [127.0.0.1]) by thoth.ir.bbn.com (8.12.6/8.12.6) with ESMTP id h2348ev6039115; Sun, 2 Mar 2003 23:08:40 -0500 (EST) (envelope-from mallman@thoth.ir.bbn.com) Message-Id: <200303030408.h2348ev6039115@thoth.ir.bbn.com> To: Reiner Ludwig From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit In-Reply-To: <5.1.0.14.0.20030228134039.029015c8@mailhost.eed.ericsson.se> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Who Made Who Date: Sun, 02 Mar 2003 23:08:40 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > - You talk about [All00] and the many short http transfers. I > don't question that result, but I think that you could maybe put > it a bit more into perspective. From our recent measurements, we > find that http 1.1 and especially pipelining are becoming > increasingly popular. Thus, http transfers should be getting > longer on average these days. I'd certainly cite any data on the subject. I'll go back and read the text around [All00] and maybe soften a bit. (The web server used for [All00] did (/does) support HTTP/1.1 persistent connections and pipelining. However, clients could certainly be evolving to use such features more.) > - Concerning the solutions mentioned in the appendix. How about if > the sender maintained a ratio of ER-based-spurious-retransmits > over total-number-of-transmitted-segments, assuming something like > Eifel/DSACK/FRTO-based detection. Then we could say that this > ratio MUST not be larger than some threshold, say 2 percent. As > soon as the ratio goes higher, we turn off ER, and turn it on > again as soon as the ratio goes below the threshold again. I think this is certainly a reasonable idea... maybe even the most reasonable idea I have yet heard. We'll definately add this to some portion of the id. Thanks! allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 3 10:54:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00532 for ; Mon, 3 Mar 2003 10:54:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23G45729203 for tsvwg-archive@odin.ietf.org; Mon, 3 Mar 2003 11:04:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23G3Yp29163; Mon, 3 Mar 2003 11:03:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23FxBp28827 for ; Mon, 3 Mar 2003 10:59:11 -0500 Received: from MAIL.cynetanetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00328 for ; Mon, 3 Mar 2003 10:48:37 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Tsvwg] early retransmit Date: Mon, 3 Mar 2003 09:50:38 -0600 Message-ID: <9255B6CD76A88943A3062F7D4E6432F55C3762@mail.cynetanetworks.com> Thread-Topic: [Tsvwg] early retransmit Thread-Index: AcLhPFx1BC2jZTGuSAO0D+5YMPP82QAXw3IQ From: "Spencer Dawkins" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h23FxBp28828 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Wouldn't this also be an appropriate suggestion for Fast Retransmit and Limited Transmit adaptive thresholding (not just ER)? As an aside: I have to say that I wonder about the interaction between adaptive transport mechanisms like this and mobile handoff (at either the Mobile IP or subnetwork layers) that can significantly twiddle what the transport is looking at. Which doesn't make Reiner's suggestion UNreasonable, but does seem like there's still opportunities for refinement. Spencer > -----Original Message----- > From: Mark Allman [mailto:mallman@grc.nasa.gov] > > - Concerning the solutions mentioned in the appendix. How about if > > the sender maintained a ratio of ER-based-spurious-retransmits > > over total-number-of-transmitted-segments, assuming something like > > Eifel/DSACK/FRTO-based detection. Then we could say that this > > ratio MUST not be larger than some threshold, say 2 percent. As > > soon as the ratio goes higher, we turn off ER, and turn it on > > again as soon as the ratio goes below the threshold again. > > I think this is certainly a reasonable idea... maybe even the most > reasonable idea I have yet heard. We'll definately add this to some > portion of the id. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 4 07:37:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15684 for ; Tue, 4 Mar 2003 07:37:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24CmJA32656 for tsvwg-archive@odin.ietf.org; Tue, 4 Mar 2003 07:48:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Clwp32599; Tue, 4 Mar 2003 07:47:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Ceup32005 for ; Tue, 4 Mar 2003 07:40:56 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15026; Tue, 4 Mar 2003 07:29:58 -0500 (EST) Message-Id: <200303041229.HAA15026@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: Tue, 04 Mar 2003 07:29:58 -0500 Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpsocket-06.txt Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --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 : Sockets API Extensions for Stream Control Transmission Protocol (SCTP) Author(s) : R. Stewart et al. Filename : draft-ietf-tsvwg-sctpsocket-06.txt Pages : 77 Date : 2003-3-3 This document describes a mapping of the Stream Control Transmission Protocol SCTP RFC2960 [8] into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features and a consolidated error and event notification scheme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sctpsocket-06.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-sctpsocket-06.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: <2003-3-3145112.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-sctpsocket-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-sctpsocket-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-3145112.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 4 07:37:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15699 for ; Tue, 4 Mar 2003 07:37:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24CmKW32669 for tsvwg-archive@odin.ietf.org; Tue, 4 Mar 2003 07:48:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Cm7p32617; Tue, 4 Mar 2003 07:48:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Cf0p32012 for ; Tue, 4 Mar 2003 07:41:00 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15044; Tue, 4 Mar 2003 07:30:03 -0500 (EST) Message-Id: <200303041230.HAA15044@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: Tue, 04 Mar 2003 07:30:02 -0500 Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-addip-sctp-07.txt Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --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 : Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration Author(s) : R. Stewart et al. Filename : draft-ietf-tsvwg-addip-sctp-07.txt Pages : 36 Date : 2003-3-3 This document describes extensions to the Stream Control Transmission Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP address information on an existing association. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-addip-sctp-07.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-addip-sctp-07.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: <2003-3-3145123.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-addip-sctp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-addip-sctp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-3145123.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 4 07:37:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15713 for ; Tue, 4 Mar 2003 07:37:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24CmNk32687 for tsvwg-archive@odin.ietf.org; Tue, 4 Mar 2003 07:48:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Cm8p32632; Tue, 4 Mar 2003 07:48:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Cf5p32023 for ; Tue, 4 Mar 2003 07:41:05 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15062; Tue, 4 Mar 2003 07:30:07 -0500 (EST) Message-Id: <200303041230.HAA15062@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: Tue, 04 Mar 2003 07:30:07 -0500 Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-08.txt Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --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 : Stream Control Transmission Protocol (SCTP) Implementors Guide Author(s) : R. Stewart, L. Ong et al. Filename : draft-ietf-tsvwg-sctpimpguide-08.txt Pages : 64 Date : 2003-3-3 This document contains a compilation of all defects found up until the publishing of this document for the Stream Control Transmission Protocol (SCTP) RFC2960 [3]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of SCTP to clarify errors in the original SCTP document. This document updates RFC2960 [3] and text within this document supersedes the text found in RFC2960 [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sctpimpguide-08.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-sctpimpguide-08.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: <2003-3-3145133.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-sctpimpguide-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-sctpimpguide-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-3145133.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 4 09:57:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24952 for ; Tue, 4 Mar 2003 09:57:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24F7wl11190 for tsvwg-archive@odin.ietf.org; Tue, 4 Mar 2003 10:07:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24F7Yp11140; Tue, 4 Mar 2003 10:07:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24F6ap10289 for ; Tue, 4 Mar 2003 10:06:36 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24817 for ; Tue, 4 Mar 2003 09:55:34 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h24EvZNS012480 for ; Tue, 4 Mar 2003 08:57:36 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E64BEDF.8090601@stewart.chicago.il.us> Date: Tue, 04 Mar 2003 08:57:35 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: TSV WG list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] PR SCTP Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Greeings: The new version of PR-SCTP is now available... http://www.ietf.org/internet-drafts/draft-stewart-tsvwg-prsctp-03.txt Please have a close look at it.. the authors all feel it is fully baked and ready to move forward... comments would be most welcome :> The feature (its been rolling around for quite some time) provides a partial reliablility. It has been sucessfully tested at the last SCTP Bakeoff with two implementations.. and many present said it would be showing up soon in their implementation as well :-> Thanks R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 4 12:18:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02260 for ; Tue, 4 Mar 2003 12:18:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24HSZX23890 for tsvwg-archive@odin.ietf.org; Tue, 4 Mar 2003 12:28:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24HSDp23863; Tue, 4 Mar 2003 12:28:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24HR3p23780 for ; Tue, 4 Mar 2003 12:27:03 -0500 Received: from thebe.your-site.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02154 for ; Tue, 4 Mar 2003 12:15:58 -0500 (EST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 7A7F424523F; Tue, 4 Mar 2003 12:18:00 -0500 (EST) Date: Tue, 4 Mar 2003 11:19:46 -0600 From: Caitlin Bestler Subject: Re: [Tsvwg] PR SCTP To: Randall Stewart , tsvwg@ietf.org X-Priority: 3 In-Reply-To: <3E64BEDF.8090601@stewart.chicago.il.us> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >3.3.1 Sending Forward-TSN-Supported param in INIT > > If an SCTP endpoint supports the FORWARD TSN chunk, then > any time it sends an INIT during association > establishment, it SHOULD include the > Forward-TSN-supported parameter in the INIT chunk to > indicate this fact to its peer. Does an SCTP endpoint supporting this capability mean that the implementation has this capability, or that the local ULP has also enabled the capability? It strikes me that partial reliability is only of use for a ULP that is explicitly aware of it, and therefore would enable it locally for the endpoint. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 4 15:11:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08620 for ; Tue, 4 Mar 2003 15:11:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24KMIg10146 for tsvwg-archive@odin.ietf.org; Tue, 4 Mar 2003 15:22:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24KLu510124; Tue, 4 Mar 2003 15:21:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24KKw510019 for ; Tue, 4 Mar 2003 15:20:58 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08467 for ; Tue, 4 Mar 2003 15:09:50 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h24KBcNS013061; Tue, 4 Mar 2003 14:11:38 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E65087A.90809@stewart.chicago.il.us> Date: Tue, 04 Mar 2003 14:11:38 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Caitlin Bestler CC: tsvwg@ietf.org Subject: Re: [Tsvwg] PR SCTP References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Caitlin Bestler wrote: >>3.3.1 Sending Forward-TSN-Supported param in INIT >> >>If an SCTP endpoint supports the FORWARD TSN chunk, then >>any time it sends an INIT during association >>establishment, it SHOULD include the >>Forward-TSN-supported parameter in the INIT chunk to >>indicate this fact to its peer. > > > Does an SCTP endpoint supporting this capability mean that > the implementation has this capability, or that the local > ULP has also enabled the capability? > Capability referes to the stack being able to do pr-sctp.. not the application. The application, would need to send with a flag to note that the message has a time limit (for example). If the app was un-aware of the capability then it would not get used... > It strikes me that partial reliability is only of use for > a ULP that is explicitly aware of it, and therefore would > enable it locally for the endpoint. > Just because the peer endpoints are capable of PR-SCTP does not mean it would be used by the application... I think I may be missing your point.. If the app does not wish to use it.. it won't period.. No matter if the two stacks support it. The PR-SCTP document is concentrating on the protocol aspects and mechanisms.. just like TCP timestamps or TCP-Sack etc... if the O/S puts an interface to disable the behavior (such as BSD has to turn on/ off timestamps or SACK via sysctl) that is outside the scope of this document and would be more apt to show up in a sockets api like document.. R > Caitlin Bestler > http://asomi.com/CaitlinBestler/ > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 4 15:22:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09047 for ; Tue, 4 Mar 2003 15:22:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24KXVV10738 for tsvwg-archive@odin.ietf.org; Tue, 4 Mar 2003 15:33:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24KXC510727; Tue, 4 Mar 2003 15:33:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24KWq510666 for ; Tue, 4 Mar 2003 15:32:52 -0500 Received: from thebe.your-site.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09009 for ; Tue, 4 Mar 2003 15:21:44 -0500 (EST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id DF629245166; Tue, 4 Mar 2003 15:23:45 -0500 (EST) Date: Tue, 4 Mar 2003 14:25:32 -0600 From: Caitlin Bestler Subject: Re: [Tsvwg] PR SCTP To: Randall Stewart , tsvwg@ietf.org X-Priority: 3 In-Reply-To: <3E65087A.90809@stewart.chicago.il.us> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 3/4/03, Randall Stewart wrote: > >I think I may be missing your point.. If the app does >not wish to use it.. it won't period.. No matter >if the two stacks support it. > I was seeking clarification on the issue of whether a stack should send this information in all INITs that it generates, or if it should only do so when there has been some indication from the application layer that there is a need for the feature. In other words, should an INIT being sent for an endpoint that has never needed partial reliability before and does not need it now, *change* when this draft is adopted? Or should the INITs supporting endoints that are unrelated to partial reliability simply omit this parameter, even if in fact they have the code to support partial reliability on other endpoints when the application layer needs it? Does the capability exist *for an endpoint* because the library has been upgraded, or should the application layer be expected to somehow activate the capability? I believe that applications that do not require new capabilities would prefer for the advertisements of their endpoints to remain unchanged even as new features are defined. If the new features are irrelevant to the application should they change packets on the wire? Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 4 17:48:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13242 for ; Tue, 4 Mar 2003 17:48:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24MwpT21033 for tsvwg-archive@odin.ietf.org; Tue, 4 Mar 2003 17:58:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24MwG521016; Tue, 4 Mar 2003 17:58:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24MvI520965 for ; Tue, 4 Mar 2003 17:57:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13142; Tue, 4 Mar 2003 17:46:05 -0500 (EST) Message-Id: <200303042246.RAA13142@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , tsvwg@ietf.org From: The IESG Date: Tue, 04 Mar 2003 17:46:05 -0500 Subject: [Tsvwg] Document Action: Robust ECN Signaling with Nonces to Experimental Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , The IESG has approved the Internet-Draft 'Robust ECN Signaling with Nonces' as an Experimental RFC. This document is the product of the Transport Area Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. Technical Summary This specification describes the ECN-nonce, an optional addition to Explicit Congestion Notification (RFC 3168) that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth. The ECN-nonce uses the two ECT codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts. Working Group Summary The working group supported publishing of this document and the Last Call discussion of the document raised no issues with the quality of the document. Protocol Quality There are implementations of the nonce algorithm and bits accompanying the implementations of RFC 3168, the Explicit Congestion Notification Proposed Standard. The specification was reviewed for the IESG by Allison Mankin and Randy Bush. RFC Editor Note: RFC-Editor, please add the following text after the Abstract: Statement of Intent: This specification contains an optional addition to Explicit Congestion Notification (RFC 3168) improving its robustness against malicious or accidental concealment of marked packets. It has not been deployed widely. One goal of publication as an as an Experimental RFC is to be prudent, and encourage use and deployment prior to publication in the standards track. Another consideration is to give time for firewall developers to accept and recognize the pattern presented by the nonce. It is the intent of the Transport Area to re-submit this specification as an IETF Proposed Standard in future after more experience has been gained. RFC-Editor, please also expand the acronyms in the abstract on first appearance: Explicit Congestion Notification (ECN) ECN-Capable Transport (ECT) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 4 19:14:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16628 for ; Tue, 4 Mar 2003 19:14:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h250PQv27510 for tsvwg-archive@odin.ietf.org; Tue, 4 Mar 2003 19:25:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h250P7527486; Tue, 4 Mar 2003 19:25:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h250OA527422 for ; Tue, 4 Mar 2003 19:24:10 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16576 for ; Tue, 4 Mar 2003 19:12:57 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h250EqNS013464; Tue, 4 Mar 2003 18:14:52 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E65417C.9000500@stewart.chicago.il.us> Date: Tue, 04 Mar 2003 18:14:52 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Caitlin Bestler CC: tsvwg@ietf.org Subject: Re: [Tsvwg] PR SCTP References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Caitlin Bestler wrote: > On 3/4/03, Randall Stewart wrote: > > > >>I think I may be missing your point.. If the app does >>not wish to use it.. it won't period.. No matter >>if the two stacks support it. >> > > I was seeking clarification on the issue of whether a > stack should send this information in all INITs that it > generates, or if it should only do so when there has been > some indication from the application layer that there is > a need for the feature. > > In other words, should an INIT being sent for an endpoint > that has never needed partial reliability before and does > not need it now, *change* when this draft is adopted? > > Or should the INITs supporting endoints that are unrelated > to partial reliability simply omit this parameter, even > if in fact they have the code to support partial reliability > on other endpoints when the application layer needs it? > > Does the capability exist *for an endpoint* because the > library has been upgraded, or should the application layer > be expected to somehow activate the capability? > > I believe that applications that do not require new > capabilities would prefer for the advertisements of their > endpoints to remain unchanged even as new features are > defined. If the new features are irrelevant to the > application should they change packets on the wire? > > I would tend to deem this a user interface issue. I could see a O/S provider making an option that says: Don't tell the peer that you support feature X, because I just don't plain want to do it... R > Caitlin Bestler > http://asomi.com/CaitlinBestler/ > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 4 23:18:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21715 for ; Tue, 4 Mar 2003 23:18:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h254SnE10003 for tsvwg-archive@odin.ietf.org; Tue, 4 Mar 2003 23:28:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h254SS509991; Tue, 4 Mar 2003 23:28:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h254Rj509957 for ; Tue, 4 Mar 2003 23:27:45 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21698 for ; Tue, 4 Mar 2003 23:16:27 -0500 (EST) Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18qQMO-0003dq-00; Tue, 04 Mar 2003 20:18:28 -0800 To: Randall Stewart cc: TSV WG list Subject: Re: [Tsvwg] PR SCTP In-Reply-To: Message from Randall Stewart of "Tue, 04 Mar 2003 08:57:35 CST." <3E64BEDF.8090601@stewart.chicago.il.us> Date: Tue, 04 Mar 2003 20:18:26 -0800 From: Allison Mankin Message-Id: Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , We will have some time on the agenda in SF to discuss PR SCTP as well. We're going to publish a tentative agenda for the meeting very shortly. Allison _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Mar 5 06:41:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27320 for ; Wed, 5 Mar 2003 06:41:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25BqLm18421 for tsvwg-archive@odin.ietf.org; Wed, 5 Mar 2003 06:52:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Bpr518250; Wed, 5 Mar 2003 06:51:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BiG517499 for ; Wed, 5 Mar 2003 06:44:16 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26704; Wed, 5 Mar 2003 06:32:48 -0500 (EST) Message-Id: <200303051132.GAA26704@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: Wed, 05 Mar 2003 06:32:48 -0500 Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-tcp-eifel-response-03.txt Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --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 : The Eifel Response Algorithm for TCP Author(s) : R. Ludwig, A. Gurtov Filename : draft-ietf-tsvwg-tcp-eifel-response-03.txt Pages : 12 Date : 2003-3-4 The Eifel response algorithm requires a detection algorithm to detect a posteriori whether the TCP sender has entered loss recovery unnecessarily. In response to a spurious timeout it adapts the retransmission timer to avoid further spurious timeouts, and can avoid - depending on the detection algorithm - the often unnecessary go-back-N retransmits that would otherwise be sent. Likewise, it adapts the duplicate acknowledgement threshold in response to a spurious fast retransmit. In both cases, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eifel-response-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-tcp-eifel-response-03.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-tcp-eifel-response-03.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: <2003-3-4174542.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-tcp-eifel-response-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-tcp-eifel-response-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-4174542.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Mar 5 06:51:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27670 for ; Wed, 5 Mar 2003 06:51:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25C2Uc19014 for tsvwg-archive@odin.ietf.org; Wed, 5 Mar 2003 07:02:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25C25518970; Wed, 5 Mar 2003 07:02:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25C1f518929 for ; Wed, 5 Mar 2003 07:01:41 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27641 for ; Wed, 5 Mar 2003 06:50:12 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h25BqGpC000590 for ; Wed, 5 Mar 2003 12:52:16 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVMFBTS; Wed, 5 Mar 2003 12:52:11 +0100 Received: from res0010384da36.eed.ericsson.se (dhcp5-197 [164.48.135.197]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id MAA03419 for ; Wed, 5 Mar 2003 12:51:58 +0100 (MET) Message-Id: <5.1.0.14.0.20030305124425.02b2b490@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 05 Mar 2003 12:51:52 +0100 To: tsvwg@ietf.org From: Reiner Ludwig Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Tsvwg] Eifel-Response-03 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , we have updated the draft that specifies the Eifel response algorithm: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eifel-response-03.txt We have followed Pasi Sarolahti's suggestion and made the Eifel response algorithm independent of any particular detection algorithm. I.e., it should now be possible to also "plug" the Eifel response onto a number of alternative detection algorithms including DSACK-based solutions and/or F-RTO. We would greatly welcome more feedback. Otherwise, we believe that this draft is ready for WG-last-call to become an experimental RFC. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Mar 5 12:55:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16751 for ; Wed, 5 Mar 2003 12:55:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25I5oC02158 for tsvwg-archive@odin.ietf.org; Wed, 5 Mar 2003 13:05:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25I4fO02102; Wed, 5 Mar 2003 13:04:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25HwuO01763 for ; Wed, 5 Mar 2003 12:58:56 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16356 for ; Wed, 5 Mar 2003 12:47:46 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h25HmV114733 for ; Wed, 5 Mar 2003 19:48:31 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Mar 2003 19:49:49 +0200 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Mar 2003 19:49:49 +0200 Subject: Re: [Tsvwg] Eifel-Response-03 From: Yogesh Prem Swami To: ext Reiner Ludwig Cc: tsvwg@ietf.org In-Reply-To: <5.1.0.14.0.20030305124425.02b2b490@mailhost.eed.ericsson.se> References: <5.1.0.14.0.20030305124425.02b2b490@mailhost.eed.ericsson.se> Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1046886587.22268.98.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 05 Mar 2003 11:49:47 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Mar 2003 17:49:49.0409 (UTC) FILETIME=[9E100510:01C2E33F] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Reiner, I didn't see anything fundamentally different (apart from the timer calculation) in this draft from the -01 draft, so all my previous comments about not restoring the congestion window are still valid. The rationale behind the timer calculation is also not clear to me. But let me begin with congestion issues. -- The bottom line for a spurious timeout is that a spurious timeout is spurious ONLY in terms of what packets to resend; its not spurious in terms of congestion. Congestion is not a property of one particular connection, but its a property of the *entire* system. So the response algorithm MUST follow the same congestion principles as a normally timeout connection. Restoring congestion window after a timeout is WRONG. Just because a particular TCP connection was waiting for some new ACK does not mean that rest of the connections in the system would leave the congestion state of that connection intact. The competing TCP connections will eat up all the unused resources (buffer space). Do some analysis or run some tests and see for yourself. All the papers and documents that you pointed out shows only a SINGLE TCP connection in the system (there are other CBR traffic, but CBR does not compete like TCP does. With CBR the congestion state remains unaltered). Unless you own an ISP, a Backbone, and the server, you will have more than one connection in the system. Conceptually, the *least* a spurious timed out connection can do is to follow RFC-2861 (and I don't know why it's not a standards track RFC)--and that is after you discount subnet change causing spurious timeout. Also, just see how TRFC behaves if it does not receive an ACK for some time. Why is Eifel response exempted from all these considerations. Eifel response will create a havoc in case of subnet change with present Inter Protocols (specific networks with hop-by-hop flow control may not have this problem, but such networks are not part of IP). Again, run some simulations (let me know if you cannot setup a test scenario with subnet change). -- In step ReCC, why should the sender stop processing spurious timeout response after 3 timeouts. Why the magic number 3? I guess a better scheme is to just follow RFC-2861 with some modifications. -- The timer calculation in STO.2: SRTT <- SRTT + 1/FlightSize * (RTT-SAMPLE - SRTT) is most disconcerting. Why should SRTT have a component of FLIGHT_SIZE. BTW, just to refresh your memory, the RTT samples are the round trip time for the *entire* congestion window--the samples are taken once every window--and not for every packet. Are you implicitly assuming that RTT is a linear function of window size. Well, RTT is a linear function only if you have a single queue (one hop); for the rest of the cases, it increases non-linearly depending upon the queuing discipline of individual router. Besides, if you are restoring the window which you are, there is no need to take FlightSize into consideration. Also, in the later two steps, aren't the values of SRTT and RTTVAR reset. Could you explain these three steps: SRTT <- SRTT + 1/FlightSize * (RTT-SAMPLE - SRTT) and set SRTT <- RTT-SAMPLE RTTVAR <- RTT-SAMPLE/2, Isn't my value of SRTT same as RTT_SAMPLE after all this fancy calculation? What am I missing here? -- yogesh PS: Folks, there are many more comments in the DCLOR draft (draft-swami-tsvwg-tcp-dclor-00.txt) which I cannot possibly write down here, but please read it for more arguments why Eifel response is not right. On Wed, 2003-03-05 at 05:51, ext Reiner Ludwig wrote: > we have updated the draft that specifies the Eifel response algorithm: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eifel-response-03.txt > > We have followed Pasi Sarolahti's suggestion and made the Eifel response > algorithm independent of any particular detection algorithm. I.e., it > should now be possible to also "plug" the Eifel response onto a number of > alternative detection algorithms including DSACK-based solutions and/or F-RTO. > > We would greatly welcome more feedback. > > Otherwise, we believe that this draft is ready for WG-last-call to become > an experimental RFC. > > ///Reiner > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Mar 5 14:14:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22575 for ; Wed, 5 Mar 2003 14:14:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25JOm610170 for tsvwg-archive@odin.ietf.org; Wed, 5 Mar 2003 14:24:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25JNoO10098; Wed, 5 Mar 2003 14:23:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25JCxO09436 for ; Wed, 5 Mar 2003 14:12:59 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21997 for ; Wed, 5 Mar 2003 14:01:48 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h25J2X120207 for ; Wed, 5 Mar 2003 21:02:33 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 5 Mar 2003 21:03:49 +0200 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Mar 2003 21:03:51 +0200 From: Yogesh Prem Swami To: tsvwg@ietf.org Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1046891029.22266.133.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 05 Mar 2003 13:03:49 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Mar 2003 19:03:51.0264 (UTC) FILETIME=[F59D4E00:01C2E349] Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Test environments for congestion response Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I asked this in last IETF, but let me ask again. Since now we have many congestion response algorithms, will it make sense to have a well defined test environment against which authors can run their tests and get results? The test environment could be an information RFC that can be used in future too. In the past, I have seen various drafts and papers where authors want to evaluate the congestion behavior of their algorithm, but they only use a single TCP connection in the entire system. This approach sometimes gives hundreds of percents of improvement and might suit the author needs, but when these tests are run with multiple connections the performance goes down significantly--sometimes below the performance of existing algorithms. Having spent time trying to model networks, I understand that it's not always possible to model a 100% realistic network, but leaving it totally un-addressed is even worse. Probably it will be useful to have a set of guidelines: have 10 TCP connections, 5 TFRC based connections with 5k, 10K, 100K, ... file size, travesing 10 routers with certain buffer spaces on the path, etc., etc. These numbers could be used from the Internet measurements (BGP statistics ... ) I think whenever we have multiple schemes we must run the tests along these guidelines and pick the scheme which comes up with the best compromise in terms of congestion or whaever the working group deems important. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Mar 5 16:28:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29876 for ; Wed, 5 Mar 2003 16:28:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25LdW123512 for tsvwg-archive@odin.ietf.org; Wed, 5 Mar 2003 16:39:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25LcXO23307; Wed, 5 Mar 2003 16:38:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25LZLO22331 for ; Wed, 5 Mar 2003 16:35:21 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29527 for ; Wed, 5 Mar 2003 16:24:06 -0500 (EST) Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18qgOl-000H53-00; Wed, 05 Mar 2003 13:25:59 -0800 To: tsvwg@ietf.org Subject: re: The IESG: [Tsvwg] Document Action: Robust ECN Signaling with Nonces to Experimental Cc: sob@harvard.edu, jon.peterson@neustar.biz, smb@research.att.com Reply-To: mankin@psg.com Date: Wed, 05 Mar 2003 13:25:59 -0800 From: Allison Mankin Message-Id: Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Folks, Remember our discussion of whether this document should be Experimental or Proposed Standard? The kicker when IESG discussed it was the recollection of the troubles that ensued when ECN first came out and firewalls blocked it. The IESG view was that presenting a sudden Proposed Standard with a new bit pattern in TCP would not present a stronger case for change to firewall vendors than an RFC that was Experimental. So the plan this time was for an explicit approach: Steve Bellovin will contact firewall and similar developers. We will think about a Last Call for Proposed Standard when some openings for nonce by them have been made and reported here. Others who have resources to gather data about the experimental use of the nonce, its interaction with firewalls, etc, or who can work with firewall, intrusion detection and other such developers, are strongly encouraged to help and report too. Here is the final form of the Statement of Intent that will go into the RFC for the Experimental publication. Statement of Intent: This specification contains an optional addition to Explicit Congestion Notification (RFC 3168) improving its robustness against malicious or accidental concealment of marked packets. It has not been deployed widely. One goal of publication as an as an Experimental RFC is to be prudent, and encourage use and deployment prior to publication in the standards track. Another consideration is to give time for firewall developers to accept and recognize the pattern presented by the nonce. It is the intent of the Transport Area to re-submit this specification as an IETF Proposed Standard in future after more experience has been gained. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Mar 5 22:33:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11549 for ; Wed, 5 Mar 2003 22:33:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h263hxZ17576 for tsvwg-archive@odin.ietf.org; Wed, 5 Mar 2003 22:43:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h263haO17517; Wed, 5 Mar 2003 22:43:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h263gGO17480 for ; Wed, 5 Mar 2003 22:42:16 -0500 Received: from parmesan.cs.wisc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11449; Wed, 5 Mar 2003 22:30:54 -0500 (EST) Received: (from poon@localhost) by parmesan.cs.wisc.edu (8.9.2/8.9.2) id VAA14252; Wed, 5 Mar 2003 21:32:57 -0600 (CST) Date: Wed, 5 Mar 2003 21:32:57 -0600 (CST) From: Kacheong Poon Message-Id: <200303060332.VAA14252@parmesan.cs.wisc.edu> To: spencer_dawkins@yahoo.com, trigtran@ietf.org Cc: tsvwg@ietf.org Subject: [Tsvwg] Re: [Trigtran] TRIGTRAN BoF at IETF 56 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Included message from "Spencer Dawkins" : >---- >Carl and I will be hosting a second TRIGTRAN BoF at IETF 56. > >The working copy of the BoF Agenda is available below (and is >being sent to agenda@ietf.org). > >We will present issues discussed in the Framework draft, available at >http://www.ietf.org/internet-drafts/draft-dawkins-trigtran-framework-00.txt. I believe there will be a lot more comments if this announcement is also made to the tsvwg mailing list. So I cc this reply to that list. >This BoF is intended to lead to the formation of a TRIGTRAN working group, >so most of our time together will be dedicated to answering a series of >questions to figure out if we're doing the right thing. > >Please plan to attend and be opinionated. > >Spencer, for Spencer and Carl > >p.s. The Problem Statement draft will be available at >http://www.ietf.org/internet-drafts/draft-dawkins-trigtran-probstmt-01.txt, >as soon as it's announced. The only changes we've made were updates to >reflect constraints in the minimal architecture model that we adopted >at IETF 55. > >p.p.s. The meeting minutes from the first BOF are available at >http://www.ietf.org/proceedings/02nov/239.htm > >p.p.p.s. My e-mail address is changing to spencer_dawkins@yahoo.com, >effective immediately. .... >AGENDA: > >- Agenda Bashing 10 minutes > >- Issues identified in TRIGTRAN Framework draft 20 minutes > Constraints of Minimal Architecture Or is it really the constraint of the current Internet architecture? Many researchers are already looking at the next generation Internet and this is probably one area where they will work on. So is it really reasonable for this proposed WG to solve an architecture problem? Or is what people actually want something not constrained by the current Internet architecture? IMHO, trigger is the wrong name to use. Pardon my English, but to me, trigger means an immediate response to a certain event. But maybe the only thing we can do is to provide some form of signal, does not necessarily need to be immediate, to the end points. Signalling message seems to be a more appropriate name. Anyway, it seems to me that what people want here is to have a way for transport to find out a little bit more about the network so that it can react more effectively to different network events. And using signals ("triggers") to do that can be one mechanism. Should a TRIGTRAN WG be formed now if there can be other mechanisms to do that? Should we evaluate them before making a decision on which one to use, signalling being one? Another obvious mechanism, as opposed to active signal, is polling by transport on some network elements. I am not suggesting that it is better or worse (probably worse (-:) than active signal. But I believe setting up a WG at this point without even some discussion and evaluation on other mechanisms is not the appropriate thing to do. > Form of Registrations > Form of Notifications > Allowable Responses to Notifications > Deployment Issues > Preliminary Security Assessment > >- Questions leading to a WG charter 50 minutes It seems that this should be the first agenda item. The reason is that if people don't even think that signal ("triggers") is the right mechanism to achieve what we want, it does not make sense to discuss a framework document. So maybe the two items should be swapped? > - is an end-to-end solution sufficient, > or do we really need help from the network? Or as mentioned above, can we have reasonable help from the network without some modifications to the current Internet architecture? Is a non-e2e solution sound? > - are explicit messages required? > - can we agree on the list of canonical triggers? I believe the above question should be broken up. We should first ask if there can be an agreed list of generic network events that we want transport to be aware of. And then we can look at the list and find out which one can be most likely "told" to transport. Lastly, we should find the most appropriate mechanism to do that given the current Internet architecture. A WG can be formed to achieve that. The above framework document can then be used as one of the documents describing one mechanism being investigated. I think that may be a more appropriate WG to be formed instead of a TRIGTRAN WG. I will not go to the IETF, so please count my vote as a NO to the formation of a TRIGTRAN WG, if that question will actually be asked. Or is the above problem still a research issue at this moment? > - can these triggers be generated by subnetwork technologies? > - can we agree on a list of reasonable responses? > - who would use TRIGTRAN notifications? (OMA, SIP, etc.)? > - who would implement a reasonable TRIGTRAN specification? > >- Next Steps leading to a TRIGTRAN working group 40 minutes > Volunteers > Documents > Timeline > Land Mines >---- K. Poon. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 00:11:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13232 for ; Thu, 6 Mar 2003 00:11:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h265Lx923100 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 00:21:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h265KQO23041; Thu, 6 Mar 2003 00:20:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h265JlO22969 for ; Thu, 6 Mar 2003 00:19:47 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13154 for ; Thu, 6 Mar 2003 00:08:24 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id BE26F9DD4; Thu, 6 Mar 2003 00:10:28 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 693EF9DD1; Thu, 6 Mar 2003 00:10:27 -0500 (EST) Date: Thu, 6 Mar 2003 00:10:27 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Yogesh Prem Swami Cc: Subject: Re: [Tsvwg] Test environments for congestion response In-Reply-To: <1046891029.22266.133.camel@atcp01.americas.nokia.com> Message-ID: X-Spam-Status: No, hits=-5.3 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On 5 Mar 2003, Yogesh Prem Swami wrote: > Having spent time trying to model networks, I understand that it's not > always possible to model a 100% realistic network, but leaving it > totally un-addressed is even worse. Probably it will be useful to have a > set of guidelines: have 10 TCP connections, 5 TFRC based connections > with 5k, 10K, 100K, ... file size, travesing 10 routers with certain > buffer spaces on the path, etc., etc. These numbers could be used from > the Internet measurements (BGP statistics ... ) Wouldn't an aggregation of Pareto ON-OFF sources be enough? The cross-traffic should be self-similar. A few TCP and TFRC connections probably will not give you the arrival pattern that a router actually experiences. I think the idea of an Information RFC as you suggest would be a good idea, but I'd be really interested in seeing a large group agree on something like this. :-) ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 10:23:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20083 for ; Thu, 6 Mar 2003 10:23:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26FYnt13522 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 10:34:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FYEO13506; Thu, 6 Mar 2003 10:34:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FXtO13484 for ; Thu, 6 Mar 2003 10:33:55 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20013 for ; Thu, 6 Mar 2003 10:22:20 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h26FONB3012613; Thu, 6 Mar 2003 16:24:23 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVMRM7W; Thu, 6 Mar 2003 16:24:21 +0100 Received: from res0010384da36.eed.ericsson.se (dhcp5-197 [164.48.135.197]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id QAA12832; Thu, 6 Mar 2003 16:24:06 +0100 (MET) Message-Id: <5.1.0.14.0.20030306130447.027d9c58@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Mar 2003 16:23:59 +0100 To: Yogesh Prem Swami From: Reiner Ludwig Subject: Re: [Tsvwg] Eifel-Response-03 Cc: tsvwg@ietf.org In-Reply-To: <1046886587.22268.98.camel@atcp01.americas.nokia.com> References: <5.1.0.14.0.20030305124425.02b2b490@mailhost.eed.ericsson.se> <5.1.0.14.0.20030305124425.02b2b490@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 18:49 05.03.2003, Yogesh Prem Swami wrote: >The >rationale behind the timer calculation is also not clear to me. That point is taken. In the meantime, we have had discussions offline from this list about "making the retransmission timer more conservative in response to a detected spurious timeout". Yes, we are convinced. That part needs to be changed. >Restoring congestion window after a timeout is WRONG. We have had that discussion before, and you won't convince us just because you get more excited about this. Our views and arguments about this issue are presented in section 3.4 of the Eifel response draft. You and I have different views on this, and that's fine. Let's hear from others instead of restating the same opinions over and over again. The interworking with Congestion Window Validation (CWV) [RFC2861] that you brought up, I find relevant, though ... CWV kicks in if - the connection has been *idle* for longer than one RTO, or - the connection has been *application-limited* for longer than one RTO. In RFC2861, the term *application-limited* is well defined ("When TCP sends a packet that does not fill the congestion window, and the TCP send queue is empty, then the sender is application-limited."), but unfortunately the term *idle* is not so well defined; also not in the CWV pseudo-code. What is missing is that *idle* means: "no data is outstanding". This is how V. Jacobson defined it in his '92 revision of his SIGCOMM '88 paper (appendix C), and that's also how it's implemented in BSD. With the Eifel response algorithm the situation is different. Once a spurious timeout has been detected, the connection had apparently *not* been idle before. Thus, that part of the CWV algorithm should not kick in. The second part of the CWV algorithm that deals with *application-limited* connections is already implicitly included in the Eifel response algorithm: cwnd is at most restored to the current flightsize + IW. This basically follows the spirit and intention of the CWV algorithm. So, I think you have a valid point. In the next revision of the Eifel response draft, we should say that the CWV algorithm should be "reset". For example, by setting the CWV variables T_last and T_prev to tcpnow. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 10:45:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21554 for ; Thu, 6 Mar 2003 10:45:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26FuwV15884 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 10:56:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FuSO15836; Thu, 6 Mar 2003 10:56:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FsqO15662 for ; Thu, 6 Mar 2003 10:54:52 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21237; Thu, 6 Mar 2003 10:43:16 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h26FjJwv020738; Thu, 6 Mar 2003 16:45:19 +0100 (MET) Received: from ESEALNT744.al.sw.ericsson.se ([153.88.251.4]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4JJ97G; Thu, 6 Mar 2003 16:45:19 +0100 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <1ZX198F3>; Thu, 6 Mar 2003 16:45:19 +0100 Message-ID: <1AB3D30B989BF141BBD5C70057B2EF7C01B65A2E@eestqnt105.es.eu.ericsson.se> X-Sybari-Trust: df25d9e4 9ffcebbb 7a95d2f4 00000138 From: "Javier Pastor-Balbas (ECE)" To: sigtran@ietf.org, "'tsvwg@ietf.org'" Cc: "Maria-Carmen Belinchon-Vergara (ECE)" Date: Thu, 6 Mar 2003 16:45:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26FsqO15663 Subject: [Tsvwg] RE: [Sigtran] I-D ACTION:draft-ietf-sigtran-sctp-mib-09.txt Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi guys, The new version of the SCTP MIB has been recently published. SCTP-MIB v09 is the result of a long revision process with MIB doctors and SIGTRAN advisors after the WGLC (thanks guys). Here you have the a summary of the changes we have made: - Copyright notice included - The Boiler plate has been updated. - Description sections have been reworked - WG information included in the MODULE-IDENTITY - Typos - Removed size limitations from InetAddress. It is instead explained in the DESCRIPTION clause - sctpAssocRemAddressHBActive object type changed from Integer to Truthvalue - Values by default added. - Some objects have been renamed to mantain naming consistency - Some objects description have been updated/reworded - In some objects we have added references to the related chapter in RFC2960 - DNS names are recommended in ASCII only. Not UTF. - Discontinuity time counter added for the whole SCTP layer - New Module group created: sctpPerAssocStatsGroup included as a Mandatory Group - References polished and updated Enjoy the reading. Cheers // MCarmen and Javier. > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: miércoles, 05 de marzo de 2003 12:33 > Cc: sigtran@ietf.org > Subject: [Sigtran] I-D ACTION:draft-ietf-sigtran-sctp-mib-09.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Signaling Transport Working > Group of the IETF. > > Title : Stream Control Transmission Protocol > Management > Information Base > Author(s) : J. Pastor, M. Belinchon > Filename : draft-ietf-sigtran-sctp-mib-09.txt > Pages : 45 > Date : 2003-3-4 > > The Stream Control Transmission Protocol (SCTP) is a reliable > transport protocol operating on top of a connectionless packet > network such as IP, designed to transport PSTN signaling messages > over the connectionless packet network, but is capable of broader > applications. > This memo defines the Management Information Base (MIB) module which > describes the minimum amount of objects needed to manage the > implementation of the SCTP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-mib-09.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > 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-sigtran-sctp-mib-09.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-sigtran-sctp-mib-09.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. > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 11:27:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25029 for ; Thu, 6 Mar 2003 11:27:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26Gcnt20735 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 11:38:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26GcKO20713; Thu, 6 Mar 2003 11:38:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26GbrO20669 for ; Thu, 6 Mar 2003 11:37:53 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24977 for ; Thu, 6 Mar 2003 11:26:17 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 8BCBA9DD7; Thu, 6 Mar 2003 11:28:20 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 44C449DD1; Thu, 6 Mar 2003 11:28:19 -0500 (EST) Date: Thu, 6 Mar 2003 11:28:19 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Reiner Ludwig Cc: Yogesh Prem Swami , Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <5.1.0.14.0.20030306130447.027d9c58@mailhost.eed.ericsson.se> Message-ID: X-Spam-Status: No, hits=-5.3 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Thu, 6 Mar 2003, Reiner Ludwig wrote: > At 18:49 05.03.2003, Yogesh Prem Swami wrote: > >Restoring congestion window after a timeout is WRONG. > > We have had that discussion before, and you won't convince us just because > you get more excited about this. Our views and arguments about this issue > are presented in section 3.4 of the Eifel response draft. You and I have > different views on this, and that's fine. Let's hear from others instead of > restating the same opinions over and over again. I was ready to say that I agree with Yogesh, but... > the CWV algorithm that deals with *application-limited* connections is > already implicitly included in the Eifel response algorithm: cwnd is at > most restored to the current flightsize + IW. This basically follows the > spirit and intention of the CWV algorithm. If cwnd restoration is as explained above, then I think "restoring cwnd" is fine. I quickly skimmed the draft and saw on page 5, the step for reverting cwnd includes the following text: If the acceptable ACK has the ECN-Echo flag [RFC3168] set OR the TCP sender has already taken more than three timeouts for the oldest outstanding segment, then proceed to step (DONE), How was the value three chosen? ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 11:37:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25684 for ; Thu, 6 Mar 2003 11:37:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26Gmpr21449 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 11:48:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26GmKO21405; Thu, 6 Mar 2003 11:48:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26GeSO20946 for ; Thu, 6 Mar 2003 11:40:28 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25110 for ; Thu, 6 Mar 2003 11:28:51 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26GTZ115368 for ; Thu, 6 Mar 2003 18:29:35 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 18:30:54 +0200 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 18:30:53 +0200 Subject: Re: [Tsvwg] Eifel-Response-03 From: Yogesh Prem Swami To: ext Reiner Ludwig Cc: tsvwg@ietf.org In-Reply-To: <5.1.0.14.0.20030306130447.027d9c58@mailhost.eed.ericsson.se> References: <5.1.0.14.0.20030305124425.02b2b490@mailhost.eed.ericsson.se> <5.1.0.14.0.20030305124425.02b2b490@mailhost.eed.ericsson.se> <5.1.0.14.0.20030306130447.027d9c58@mailhost.eed.ericsson.se> Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1046968251.24703.49.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 06 Mar 2003 10:30:51 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2003 16:30:53.0250 (UTC) FILETIME=[C1814220:01C2E3FD] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Reiner, all, On Thu, 2003-03-06 at 09:23, ext Reiner Ludwig wrote > are presented in section 3.4 of the Eifel response draft. You and I have Here's the excerpt from 3.4: "When a TCP sender enters loss recovery, it also assumes that is has received a congestion indication. In response to that it reduces cwnd, and ssthresh. However, once the TCP sender detects that the loss recovery has been falsely triggered, this reduction was unnecessary. In fact, no congestion signal has been received. We therefore believe that it is safe to revert to the previous congestion control state." If I go by this logic, then why shall I start with a small window size at the start of the connection? At the start of the connection I have no congestion indication, so I should be able to send what ever amount of data I want? Are you suggesting we should start with a window of say 10M bytes and wait until we receive congestion indication? Your logic seems to imply that. > The interworking with Congestion Window Validation (CWV) [RFC2861] that you > brought up, I find relevant, though ... > > CWV kicks in if > - the connection has been *idle* for longer than one RTO, or > - the connection has been *application-limited* for longer than one RTO. > > In RFC2861, the term *application-limited* is well defined ("When TCP sends > a packet that does not fill the congestion window, and the TCP send queue > is empty, then the sender is application-limited."), but unfortunately the > term *idle* is not so well defined; also not in the CWV pseudo-code. What idle is any time period greater than RTO. RTO is an statistical upper bound during which the *end to end state of the network* will remain *roughly* (no guarantees) the same as far as congestion is concerned. Beyond that, there is no reason to believe that network will be in the same state. > is missing is that *idle* means: "no data is outstanding". This is how V. > Jacobson defined it in his '92 revision of his SIGCOMM '88 paper (appendix > C), and that's also how it's implemented in BSD. > Congestion control is about the state of the network, not about how you define certain things. If the state of the network changes because the sender was not sending data for more than RTO, then that is a valid candidate for CVW--regardless of the definition used. In addition, CVS works only when there is no host mobility. > With the Eifel response algorithm the situation is different. Once a > spurious timeout has been detected, the connection had apparently *not* > been idle before. The connection is not idle, but the network has been. Beyond RTO you don't know what happened in the network. > Thus, that part of the CWV algorithm should not kick in. The second part of > the CWV algorithm that deals with *application-limited* connections is > already implicitly included in the Eifel response algorithm: cwnd is at > most restored to the current flightsize + IW. This basically follows the > spirit and intention of the CWV algorithm. It doesn't matter whether it's application limited or idle. The simple rule is: if you have used your share of network resources within RTO, you can continue using that share. If you have not, you are required to start from scratch. But I think it will be good to get some feedback from other people too. I strongly disagree with the present response algorithm because it reduces the over all throughput of the system. Again, I emphsize "the system" and not one particular TCP connection. We have also put the results in appendix of the DCLOR draft to see the difference. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 12:00:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28510 for ; Thu, 6 Mar 2003 12:00:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26HC0i23993 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 12:12:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HBJO23800; Thu, 6 Mar 2003 12:11:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26GrsO21907 for ; Thu, 6 Mar 2003 11:53:54 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26262 for ; Thu, 6 Mar 2003 11:42:17 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26GleF22815 for ; Thu, 6 Mar 2003 18:47:40 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 18:44:20 +0200 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 18:44:19 +0200 Subject: Re: [Tsvwg] Eifel-Response-03 From: Yogesh Prem Swami To: "Armando L. Caro Jr." Cc: Reiner Ludwig , tsvwg@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1046969057.24711.62.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 06 Mar 2003 10:44:17 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2003 16:44:19.0801 (UTC) FILETIME=[A23F2C90:01C2E3FF] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, On Thu, 2003-03-06 at 10:28, ext Armando L. Caro Jr. wrote: > > > the CWV algorithm that deals with *application-limited* connections is > > already implicitly included in the Eifel response algorithm: cwnd is at > > most restored to the current flightsize + IW. This basically follows the > > spirit and intention of the CWV algorithm. > > If cwnd restoration is as explained above, then I think "restoring cwnd" > is fine. > > I quickly skimmed the draft and saw on page 5, the step for reverting cwnd > includes the following text: > > If the acceptable ACK has the ECN-Echo flag [RFC3168] set > OR the TCP sender has already taken more than three > timeouts for the oldest outstanding segment, then proceed > to step (DONE), > The ECN-ECHO doesn't say anything. Consider this case Part-A Part-B Sender ----------> pkt stalling node ----------> receiver The Congestion Experience could have been set either on Part-A or on Part-B, but the ACKs received after the spurious timeout only tell the state of the network either a) for the entire path but before RTO, or b) only Part-B. In either case, the sender does not know what the current state of network is on Part-A. It's possible that Part-B was not congested but Part-A got congestion during the RTO period and you will not receiver any ECN-Echo in that case. On the other hand, if the network did get better during the stalling period, it's better that the sender should start using the resources at a faster rate. Eifel response fails in both the cases. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 12:13:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29424 for ; Thu, 6 Mar 2003 12:13:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26HOEu25354 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 12:24:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HNgO25218; Thu, 6 Mar 2003 12:23:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26H8nO23598 for ; Thu, 6 Mar 2003 12:08:49 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28165 for ; Thu, 6 Mar 2003 11:57:11 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26Gvs102375 for ; Thu, 6 Mar 2003 18:57:54 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 18:59:13 +0200 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 18:59:13 +0200 Subject: Re: [Tsvwg] Test environments for congestion response From: Yogesh Prem Swami To: "Armando L. Caro Jr." Cc: tsvwg@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1046969951.24711.78.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 06 Mar 2003 10:59:11 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2003 16:59:13.0183 (UTC) FILETIME=[B6BE72F0:01C2E401] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Armando, On Wed, 2003-03-05 at 23:10, ext Armando L. Caro Jr. wrote: > On 5 Mar 2003, Yogesh Prem Swami wrote: > > > Having spent time trying to model networks, I understand that it's not > > always possible to model a 100% realistic network, but leaving it > > totally un-addressed is even worse. Probably it will be useful to have a > > set of guidelines: have 10 TCP connections, 5 TFRC based connections > > with 5k, 10K, 100K, ... file size, travesing 10 routers with certain > > buffer spaces on the path, etc., etc. These numbers could be used from > > the Internet measurements (BGP statistics ... ) > > Wouldn't an aggregation of Pareto ON-OFF sources be enough? The > cross-traffic should be self-similar. A few TCP and TFRC connections > probably will not give you the arrival pattern that a router actually > experiences. > I agree. What is needed is a realistic scenario which can mimic the network behaviour in a certain way. I am appalled by results which show 300% improvent in TCP performance, but of course the authors were using loopback addresses for testing their improved schemes. [Just exaggerating ...] > I think the idea of an Information RFC as you suggest would be a good > idea, but I'd be really interested in seeing a large group agree on > something like this. :-) > Yes, but not defining anything is probably worse. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 12:15:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29964 for ; Thu, 6 Mar 2003 12:15:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26HR1w26349 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 12:27:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HQPO26116; Thu, 6 Mar 2003 12:26:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26H4HO22598 for ; Thu, 6 Mar 2003 12:04:17 -0500 Received: from web10906.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27813 for ; Thu, 6 Mar 2003 11:52:39 -0500 (EST) Message-ID: <20030306165443.36190.qmail@web10906.mail.yahoo.com> Received: from [64.3.223.254] by web10906.mail.yahoo.com via HTTP; Thu, 06 Mar 2003 08:54:43 PST Date: Thu, 6 Mar 2003 08:54:43 -0800 (PST) From: Spencer Dawkins To: trigtran@ietf.org Cc: tsvwg@ietf.org In-Reply-To: <200303060332.VAA14252@parmesan.cs.wisc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Tsvwg] Re: [Trigtran] TRIGTRAN BoF at IETF 56 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Just a couple of points on Kacheong's note: Spencer --- Kacheong Poon wrote: > >AGENDA: > > > >- Agenda Bashing 10 minutes > > > >- Issues identified in TRIGTRAN Framework draft 20 minutes > > Constraints of Minimal Architecture > > Or is it really the constraint of the current Internet > architecture? Many researchers are already looking at > the next generation Internet and this is probably one > area where they will work on. So is it really reasonable > for this proposed WG to solve an architecture problem? > Or is what people actually want something not constrained > by the current Internet architecture? No, this is actually a topic requested by some people who have asked "what about links that aren't access links?" and similar questions. It's just explaining why we excluded some topologies from consideration. > > IMHO, trigger is the wrong name to use. Pardon my English, > but to me, trigger means an immediate response to a certain > event. But maybe the only thing we can do is to provide > some form of signal, does not necessarily need to be > immediate, > to the end points. Signalling message seems to be a more > appropriate name. You may very well be correct, that we might think of a more helpful name (although I note, tongue-in-cheek, that Signalling for Transport/SIGTRAN seems to be previously occuppied - sorry, Lyndon!) > > Anyway, it seems to me that what people want here is to have a > way for transport to find out a little bit more about the > network > so that it can react more effectively to different network > events. > And using signals ("triggers") to do that can be one > mechanism. This is my understanding also. > > Should a TRIGTRAN WG be formed now if there can be other > mechanisms > to do that? Should we evaluate them before making a decision > on > which one to use, signalling being one? Another obvious > mechanism, > as opposed to active signal, is polling by transport on some > network elements. I am not suggesting that it is better or > worse > (probably worse (-:) than active signal. But I believe > setting > up a WG at this point without even some discussion and > evaluation > on other mechanisms is not the appropriate thing to do. I'm not sure that I've done a good job of making something clear, so let me try here: The framework draft Carl and I put together is (at most) one way the problem might be addressed. I'm very clear in my mind that it's not baseline for a working group draft, with as little discussion as we've had on some of the approaches. If $TRIGTRAN (or a more suitable name) is chartered, I'd expect the charter to include a more rigorous requirements document, and I'd be asking for other frameworks (maybe not polling, but I'm sure there's something! perhaps defining a standardized mechanism for link-up, and end-to-end messaging beyond link-down and link-up? but I'm getting ahead of where the discussion has been, at least to date). So, to be clearer than I have been in the past, Carl and I aren't tied to a particular working group name, set of requirements, or set of protocol mechanisms, at this time. Please send text! Thanks for your feedback, and for your suggestions on a detailed way forward. Spencer, for Spencer and Carl __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 12:19:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00402 for ; Thu, 6 Mar 2003 12:19:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26HUfX27005 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 12:30:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HU4O26961; Thu, 6 Mar 2003 12:30:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HTfO26913 for ; Thu, 6 Mar 2003 12:29:41 -0500 Received: from localhost.localdomain (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00230 for ; Thu, 6 Mar 2003 12:18:03 -0500 (EST) Received: (from elb@localhost) by localhost.localdomain (8.11.6/8.11.6) id h26HK2a12693; Thu, 6 Mar 2003 12:20:02 -0500 Date: Thu, 6 Mar 2003 12:20:02 -0500 From: Ethan Blanton To: Yogesh Prem Swami Cc: ext Reiner Ludwig , tsvwg@ietf.org Subject: Re: [Tsvwg] Eifel-Response-03 Message-ID: <20030306172002.GC10705@paco.resnet.purdue.edu> Mail-Followup-To: Yogesh Prem Swami , ext Reiner Ludwig , tsvwg@ietf.org References: <5.1.0.14.0.20030305124425.02b2b490@mailhost.eed.ericsson.se> <5.1.0.14.0.20030305124425.02b2b490@mailhost.eed.ericsson.se> <5.1.0.14.0.20030306130447.027d9c58@mailhost.eed.ericsson.se> <1046968251.24703.49.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gE7i1rD7pdK0Ng3j" Content-Disposition: inline In-Reply-To: <1046968251.24703.49.camel@atcp01.americas.nokia.com> User-Agent: Mutt/1.4i X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --gE7i1rD7pdK0Ng3j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Yogesh Prem Swami spake unto us the following wisdom: > Here's the excerpt from 3.4:=20 > "When a TCP sender enters loss recovery, it also assumes > that is has received a congestion indication. In response to > that it reduces cwnd, and ssthresh. However, once the TCP > sender detects that the loss recovery has been falsely > triggered, this reduction was unnecessary. In fact, no > congestion signal has been received. We therefore believe > that it is safe to revert to the previous congestion control > state." >=20 > If I go by this logic, then why shall I start with a small window size > at the start of the connection? At the start of the connection I have no > congestion indication, so I should be able to send what ever amount of > data I want?=20 I don't think this is equivalent at all to what Reiner's draft is saying. His draft is more equivalent to saying "As long as I am continuing with normal TCP transmission and getting normal acknowledgements, it's OK to use congestion avoidance as usual." The basic point here is that we *thought* we saw congestion, but we didn't -- we busted our own connection by using an apparently bogus RTO timer. As another message in this thread indicated, perhaps finding a way to fix that RTO is called for, but that is orthogonal to the point you are questioning here. > Are you suggesting we should start with a window of say 10M bytes and > wait until we receive congestion indication? Your logic seems to imply > that. I'm suggesting (as I agree with Reiner, and I think this is what his text says) that we should use the accepted TCP congestion avoidance and congestion control routines, and take advantage of the fact that we can detect when we made a mistake. > I strongly disagree with the present response algorithm because it > reduces the over all throughput of the system. Again, I emphsize "the > system" and not one particular TCP connection. We have also put the > results in appendix of the DCLOR draft to see the difference.=20 I think saying it reduces the overall throughput of every system is a bold claim ... I would believe that it reduces throughput in some circumstances, but I would like to believe that it improves the throughput for the connection in question without adversely affecting the rest of the network in many or most circumstances. Ethan --=20 Happiness is a belt-fed weapon. --gE7i1rD7pdK0Ng3j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Z4NCr9kA9Ig8HBQRAnt9AJ0TYqxehOK1we5RBcorou3GhyCuxgCdGQ0y fI5S2dAB8dVfQhMoKDGI690= =2vPP -----END PGP SIGNATURE----- --gE7i1rD7pdK0Ng3j-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 12:31:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01456 for ; Thu, 6 Mar 2003 12:31:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26HgcQ28509 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 12:42:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HgHO28449; Thu, 6 Mar 2003 12:42:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HfFO28356 for ; Thu, 6 Mar 2003 12:41:15 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01336 for ; Thu, 6 Mar 2003 12:29:38 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 113FE9DD7; Thu, 6 Mar 2003 12:31:42 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id C01379D9D; Thu, 6 Mar 2003 12:31:40 -0500 (EST) Date: Thu, 6 Mar 2003 12:31:40 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Yogesh Prem Swami Cc: ext Reiner Ludwig , Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <1046968251.24703.49.camel@atcp01.americas.nokia.com> Message-ID: X-Spam-Status: No, hits=-5.3 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On 6 Mar 2003, Yogesh Prem Swami wrote: > Here's the excerpt from 3.4: > > > "When a TCP sender enters loss recovery, it also assumes that is has > received a congestion indication. In response to that it reduces cwnd, > and ssthresh. However, once the TCP sender detects that the loss > recovery has been falsely triggered, this reduction was unnecessary. In > fact, no congestion signal has been received. We therefore believe that > it is safe to revert to the previous congestion control state." > > If I go by this logic, then why shall I start with a small window size > at the start of the connection? At the start of the connection I have no > congestion indication, so I should be able to send what ever amount of > data I want? > > Are you suggesting we should start with a window of say 10M bytes and > wait until we receive congestion indication? Your logic seems to imply > that. I agree with you on principal, but I think you are missing something. From section 3.1 (The Algorithm), the cwnd restoration algorithm is: cwnd <- min (pipe_prev, (FlightSize + IW)) ssthresh <- pipe_prev So this algorithm does use the CWV principles from RFC 2861. I would suggest to Reiner to reword text references to cwnd restoration so that the text better reflects the actual algorithm. (FYI: I will read the response drafts in more detail soon and give my comments.) ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 12:52:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02924 for ; Thu, 6 Mar 2003 12:52:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26I3MA29994 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 13:03:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26I35O29978; Thu, 6 Mar 2003 13:03:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26I1CO29897 for ; Thu, 6 Mar 2003 13:01:12 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02842 for ; Thu, 6 Mar 2003 12:49:33 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26HoH101888 for ; Thu, 6 Mar 2003 19:50:17 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 19:51:37 +0200 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 19:51:36 +0200 Subject: Re: [Tsvwg] Eifel-Response-03 From: Yogesh Prem Swami To: ext Ethan Blanton Cc: ext Reiner Ludwig , tsvwg@ietf.org In-Reply-To: <20030306172002.GC10705@paco.resnet.purdue.edu> References: <5.1.0.14.0.20030305124425.02b2b490@mailhost.eed.ericsson.se> <5.1.0.14.0.20030305124425.02b2b490@mailhost.eed.ericsson.se> <5.1.0.14.0.20030306130447.027d9c58@mailhost.eed.ericsson.se> <1046968251.24703.49.camel@atcp01.americas.nokia.com> <20030306172002.GC10705@paco.resnet.purdue.edu> Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1046973094.24704.108.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 06 Mar 2003 11:51:34 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2003 17:51:36.0745 (UTC) FILETIME=[0873F190:01C2E409] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, On Thu, 2003-03-06 at 11:20, ext Ethan Blanton wrote: > Yogesh Prem Swami spake unto us the following wisdom: > > Here's the excerpt from 3.4: > > "When a TCP sender enters loss recovery, it also assumes > > that is has received a congestion indication. In response to > > that it reduces cwnd, and ssthresh. However, once the TCP > > sender detects that the loss recovery has been falsely > > triggered, this reduction was unnecessary. In fact, no > > congestion signal has been received. We therefore believe > > that it is safe to revert to the previous congestion control > > state." > > > > If I go by this logic, then why shall I start with a small window size > > at the start of the connection? At the start of the connection I have no > > congestion indication, so I should be able to send what ever amount of > > data I want? > > I don't think this is equivalent at all to what Reiner's draft is > saying. His draft is more equivalent to saying "As long as I am > continuing with normal TCP transmission and getting normal > acknowledgements, it's OK to use congestion avoidance as usual." The That's precisely the point. During the spurious timeout period, the sender is not getting the ACKs in the regular fashion, so congestion avoidance makes no sense. During that period the other TCP connections in the system were still doing fine and they will use up all the resources of the network. Please see section 2.2 of DCLOR draft (draft-swami-tsvwg-tcp-dclor-00.txt) for an analysis. > basic point here is that we *thought* we saw congestion, but we didn't we cannot claim that we *didn't see* congestion; the congestion informaiotn on the first part (the part between the sender and stalling node) is more than an RTO old so its of little use. All we can claim is that we don't know what happened during that idle period. > I'm suggesting (as I agree with Reiner, and I think this is what his > text says) that we should use the accepted TCP congestion avoidance > and congestion control routines, and take advantage of the fact that > we can detect when we made a mistake. Yes we can detect congestion after losing packets, but that would be too late. Consider the case where there are repeated spurious timeouts (which will happen if there are many mobile users moving from one subnet to another). In that case, the network will keep losing packets from random set of senders. As long as spurious timeouts happen once in a while, it might be acceptable to restore the window. But once the number of spurious timeouts increases, the system will the hardly hit. > > > I strongly disagree with the present response algorithm because it > > reduces the over all throughput of the system. Again, I emphsize "the > > system" and not one particular TCP connection. We have also put the > > results in appendix of the DCLOR draft to see the difference. > > I think saying it reduces the overall throughput of every system is a > bold claim ... I would believe that it reduces throughput in some Indeed it's a bold claim, and that's why I am asking the working group to define a test environment which will consider all possible causes of spurious timeouts. This will also allow an independent observer to test each of these schemes. I think this should be acceptable to everyone. > circumstances, but I would like to believe that it improves the > throughput for the connection in question without adversely affecting > the rest of the network in many or most circumstances. > Could you please provide some data of these circumstances. From my experiments, I have found the performance to go down (I used the Linux distribution of Eifel.) in almost all cases except where there are just one or two TCP connections in the system. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 12:52:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02940 for ; Thu, 6 Mar 2003 12:52:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26I3Pb30008 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 13:03:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26I22O29934; Thu, 6 Mar 2003 13:02:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26I0UO29854 for ; Thu, 6 Mar 2003 13:00:30 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02811 for ; Thu, 6 Mar 2003 12:48:36 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8/8.12.3) with ESMTP id h26HhOTL021993; Thu, 6 Mar 2003 11:43:25 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E6788BC.1020500@stewart.chicago.il.us> Date: Thu, 06 Mar 2003 11:43:24 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Reiner Ludwig CC: "Armando L. Caro Jr." , Yogesh Prem Swami , tsvwg@ietf.org Subject: Re: [Tsvwg] Eifel-Response-03 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Armando L. Caro Jr. wrote: > On Thu, 6 Mar 2003, Reiner Ludwig wrote: > > >>At 18:49 05.03.2003, Yogesh Prem Swami wrote: >> >>>Restoring congestion window after a timeout is WRONG. >> >>We have had that discussion before, and you won't convince us just because >>you get more excited about this. Our views and arguments about this issue >>are presented in section 3.4 of the Eifel response draft. You and I have >>different views on this, and that's fine. Let's hear from others instead of >>restating the same opinions over and over again. > > > I was ready to say that I agree with Yogesh, but... > I like Armando was ready to agree with Yogesh.. then at the prompting of this set of exchanges I went and read the draft ;-> > >>the CWV algorithm that deals with *application-limited* connections is >>already implicitly included in the Eifel response algorithm: cwnd is at >>most restored to the current flightsize + IW. This basically follows the >>spirit and intention of the CWV algorithm. > I think FWIW I am ok with restoring to min(prevfs, (currfs+IW)) But I do have one question.. Would this ever other return anything but currfs+IW? R > > If cwnd restoration is as explained above, then I think "restoring cwnd" > is fine. > > I quickly skimmed the draft and saw on page 5, the step for reverting cwnd > includes the following text: > > If the acceptable ACK has the ECN-Echo flag [RFC3168] set > OR the TCP sender has already taken more than three > timeouts for the oldest outstanding segment, then proceed > to step (DONE), > > How was the value three chosen? > > ~armando > > 0-- --0 > | Armando L. Caro Jr. | Protocol Engineering Lab | > | www.cis.udel.edu/~acaro | University of Delaware | > 0-- --0 > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 13:04:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03531 for ; Thu, 6 Mar 2003 13:04:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26IFcZ31611 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 13:15:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IEZO31550; Thu, 6 Mar 2003 13:14:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IDhO31457 for ; Thu, 6 Mar 2003 13:13:43 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03419 for ; Thu, 6 Mar 2003 13:02:05 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 810E99DD7; Thu, 6 Mar 2003 13:04:09 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 27A679D82; Thu, 6 Mar 2003 13:04:08 -0500 (EST) Date: Thu, 6 Mar 2003 13:04:08 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Randall Stewart Cc: Reiner Ludwig , Yogesh Prem Swami , Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <3E6788BC.1020500@stewart.chicago.il.us> Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Thu, 6 Mar 2003, Randall Stewart wrote: > I think FWIW I am ok with restoring to min(prevfs, (currfs+IW)) > > But I do have one question.. > > Would this ever other return anything but currfs+IW? Yeah, I don't see how prev_flight is ever achieved... unless the spurious rtx detection is REALLY late. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 13:06:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03808 for ; Thu, 6 Mar 2003 13:06:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26IHnp31824 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 13:17:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IH5O31765; Thu, 6 Mar 2003 13:17:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IGXO31730 for ; Thu, 6 Mar 2003 13:16:33 -0500 Received: from localhost.localdomain (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03591 for ; Thu, 6 Mar 2003 13:04:54 -0500 (EST) Received: (from elb@localhost) by localhost.localdomain (8.11.6/8.11.6) id h26I6nE12764; Thu, 6 Mar 2003 13:06:49 -0500 Date: Thu, 6 Mar 2003 13:06:49 -0500 From: Ethan Blanton To: Yogesh Prem Swami Cc: ext Reiner Ludwig , tsvwg@ietf.org Subject: Re: [Tsvwg] Eifel-Response-03 Message-ID: <20030306180649.GE10705@paco.resnet.purdue.edu> Mail-Followup-To: Yogesh Prem Swami , ext Reiner Ludwig , tsvwg@ietf.org References: <5.1.0.14.0.20030305124425.02b2b490@mailhost.eed.ericsson.se> <5.1.0.14.0.20030305124425.02b2b490@mailhost.eed.ericsson.se> <5.1.0.14.0.20030306130447.027d9c58@mailhost.eed.ericsson.se> <1046968251.24703.49.camel@atcp01.americas.nokia.com> <20030306172002.GC10705@paco.resnet.purdue.edu> <1046973094.24704.108.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PPYy/fEw/8QCHSq3" Content-Disposition: inline In-Reply-To: <1046973094.24704.108.camel@atcp01.americas.nokia.com> User-Agent: Mutt/1.4i X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --PPYy/fEw/8QCHSq3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Yogesh Prem Swami spake unto us the following wisdom: > As long as spurious timeouts happen once in a while, it might be > acceptable to restore the window. But once the number of spurious > timeouts increases, the system will the hardly hit. Now on this point, I *completely* agree. Our experiments with DSACK suggested that if these bogus retransmissions (of any kind) are not curbed, they will become a significant problem in and of themselves. However, as Reiner has I believe pointed out in another part of this thread, this is a known problem ... and I would agree with you that it needs a little bit of face time in this draft or any other draft addressing the issue of allowing congestion state reversion. Obviously we do not want to continually take false timeouts and spew unnecessary retransmits into the network in any event. If this is the crux of your position, then I am in agreement. Ethan --=20 Happiness is a belt-fed weapon. --PPYy/fEw/8QCHSq3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Z445r9kA9Ig8HBQRApQ+AJ98T4lnNjR+QzFwM86mtj/ei4ugsQCdEUK4 C8yrav1JZg1RtmIfjD8sKA8= =7Z9G -----END PGP SIGNATURE----- --PPYy/fEw/8QCHSq3-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 14:02:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06627 for ; Thu, 6 Mar 2003 14:02:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26JDqR04804 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 14:13:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JDSO04767; Thu, 6 Mar 2003 14:13:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JCRO04697 for ; Thu, 6 Mar 2003 14:12:27 -0500 Received: from seraph3.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06510 for ; Thu, 6 Mar 2003 14:00:47 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id CF1186BA22 for ; Thu, 6 Mar 2003 14:02:51 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h26J2o7h002440; Thu, 6 Mar 2003 14:02:50 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id OAA22540; Thu, 6 Mar 2003 14:02:50 -0500 (EST) Message-Id: <200303061902.OAA22540@guns.lerc.nasa.gov> To: Ethan Blanton From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: Yogesh Prem Swami , ext Reiner Ludwig , tsvwg@ietf.org Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <20030306180649.GE10705@paco.resnet.purdue.edu> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Walk on the Wild Side Date: Thu, 06 Mar 2003 14:02:50 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > Yogesh Prem Swami spake unto us the following wisdom: > > As long as spurious timeouts happen once in a while, it might be > > acceptable to restore the window. But once the number of spurious > > timeouts increases, the system will the hardly hit. > > Now on this point, I *completely* agree. Our experiments with > DSACK suggested that if these bogus retransmissions (of any kind) > are not curbed, they will become a significant problem in and of > themselves. However, as Reiner has I believe pointed out in > another part of this thread, this is a known problem ... and I > would agree with you that it needs a little bit of face time in > this draft or any other draft addressing the issue of allowing > congestion state reversion. Obviously we do not want to > continually take false timeouts and spew unnecessary retransmits > into the network in any event. > > If this is the crux of your position, then I am in agreement. I agree that spuriously retransmitting continuously is a Bad Thing. But, I want to note that Reiner's draft (& our draft on what to do in the face of reordering) takes action to attempt to avoid this situation in the future (i.e., so it doesn't happen continuously). That is, the RTO or the dupthresh is adjusted in an effort to prevent continuous bogosity. And, so I think it is a bit unfair to argue against Reiner's intent here (if you want to claim that his algorithms do not go far enough, I think that is fine -- but, I think that is a different argument all together). allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 14:30:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07942 for ; Thu, 6 Mar 2003 14:30:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26JfJt07182 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 14:41:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JetO07145; Thu, 6 Mar 2003 14:40:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JTjO05662 for ; Thu, 6 Mar 2003 14:29:45 -0500 Received: from seraph3.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07370 for ; Thu, 6 Mar 2003 14:18:04 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 014E96BA4A for ; Thu, 6 Mar 2003 14:20:08 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h26JK87h008846; Thu, 6 Mar 2003 14:20:08 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id OAA23101; Thu, 6 Mar 2003 14:20:08 -0500 (EST) Message-Id: <200303061920.OAA23101@guns.lerc.nasa.gov> To: Yogesh Prem Swami From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: ext Reiner Ludwig , tsvwg@ietf.org Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <1046968251.24703.49.camel@atcp01.americas.nokia.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Walk on the Wild Side Date: Thu, 06 Mar 2003 14:20:08 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > If I go by this logic, then why shall I start with a small window > size at the start of the connection? At the start of the > connection I have no congestion indication, so I should be able to > send what ever amount of data I want? > > Are you suggesting we should start with a window of say 10M bytes > and wait until we receive congestion indication? Your logic seems > to imply that. I disagree with the above analysis. I hope the following is very neutral -- I mean it to neither support nor refute your overall argument (I am still rolling that around in my head). At the beginning of a connection you have no congestion indication, indeed. But, also you have no indication of what the cwnd ought to be. When we spuriously timeout we have a cwnd that has been validated by the network path. Now, that might or might not be valid after the suprious timeout--- rather my point si that we have *some notion* about what cwnd ought to be, as opposed to the start of a connection when we have none. allman _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 15:13:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10802 for ; Thu, 6 Mar 2003 15:13:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26KOwx10576 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 15:24:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KObO10542; Thu, 6 Mar 2003 15:24:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26K9aO09571 for ; Thu, 6 Mar 2003 15:09:36 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09043 for ; Thu, 6 Mar 2003 14:57:54 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26K3IF28715 for ; Thu, 6 Mar 2003 22:03:18 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 21:59:58 +0200 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 21:59:57 +0200 Subject: Re: [Tsvwg] Eifel-Response-03 From: Yogesh Prem Swami To: mallman@grc.nasa.gov Cc: ext Reiner Ludwig , tsvwg@ietf.org In-Reply-To: <200303061920.OAA23101@guns.lerc.nasa.gov> References: <200303061920.OAA23101@guns.lerc.nasa.gov> Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1046980795.1225.38.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 06 Mar 2003 13:59:56 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2003 19:59:57.0877 (UTC) FILETIME=[F6AF6E50:01C2E41A] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Marc, all, On Thu, 2003-03-06 at 13:20, ext Mark Allman wrote: > > If I go by this logic, then why shall I start with a small window > > size at the start of the connection? At the start of the > > connection I have no congestion indication, so I should be able to > > send what ever amount of data I want? > > > > Are you suggesting we should start with a window of say 10M bytes > > and wait until we receive congestion indication? Your logic seems > > to imply that. > > I disagree with the above analysis. I hope the following is very > neutral -- I mean it to neither support nor refute your overall > argument (I am still rolling that around in my head). > > At the beginning of a connection you have no congestion indication, > indeed. But, also you have no indication of what the cwnd ought to > be. When we spuriously timeout we have a cwnd that has been > validated by the network path. Now, that might or might not be > valid after the suprious timeout--- rather my point si that we have > *some notion* about what cwnd ought to be, as opposed to the start > of a connection when we have none. > Yes, I agree that the sender has a some stale information about the state of the network, but that information, as you note, might not be of any use. The answer to the question of how good the information actually is, depends on the how long the spurious timeout lasted Let us do some simplified calculations (I am using the same calculation in my DCLOR draft; I apologize if you have already seen this). Lets say there are M competing connection (apart from the connection which was interrupted) and each of them has a Round Trip Time or R (this is a simplifying assumption; I am by no means suggestion it's the case). Let's also say that that the stalling duration is K*R, where K is some integer constant (again just a simplified case to the feel for things). Let's also assume that all the competing connections were doing congestion aovidance. In this case while the stalled connection was waiting for acknowledgements, rest of the M competing connections would increase their congestoin window 1 segment per RTT. So by the end of the spurious timeout, the effective buffer space for the defaulting connection will become: cwnd - M*K As we can see this number grows linealy with K (that is the stalling period) and with the number of competing connections. There is NO way for a TCP sender to know how many competing connections are there in the system. Now if I restore the window (in this idealized scenario) then there will be M*K packet loss. In reality this is not so direct due to retransmissions etc, but it's close (at least in our emulation which had differnet uniform distributed RTT values) All this analysis is true as long as the spurious timeout is not caused due to user's mobility. With user's mobility, things are worse. In the DCLOR draft we take the most conservative approach to start with a small window size and run slow-start. This prevents from packet loss, and also improves thoughput. This approach is also in sync with RFC-793 which recommends "being conservative in what you send, and liberal in what you accept." BTW, it's useful to point out that fast-retransmit, fast-recovery recovers one packet per RTT. On the other hand, Slow start can recover packet at a much faster rate if the number of lost packets is large. There is a lot more information in Janey C. Hoe's MS thesis (Strart Up dynamics of TCP's congestion control and avoidance schemes) So coming back to the argument of initial window, a spurious timeout is no different from a new connection. The information that the sender has is too old and has no value. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 15:35:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11560 for ; Thu, 6 Mar 2003 15:35:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26KkGT12577 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 15:46:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KjlO12534; Thu, 6 Mar 2003 15:45:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KRUO10694 for ; Thu, 6 Mar 2003 15:27:30 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10939 for ; Thu, 6 Mar 2003 15:15:48 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26KLCF06959 for ; Thu, 6 Mar 2003 22:21:12 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Mar 2003 22:17:52 +0200 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Mar 2003 22:17:51 +0200 Subject: Re: [Tsvwg] Eifel-Response-03 From: Yogesh Prem Swami To: mallman@grc.nasa.gov Cc: Ethan Blanton , ext Reiner Ludwig , tsvwg@ietf.org In-Reply-To: <200303061902.OAA22540@guns.lerc.nasa.gov> References: <200303061902.OAA22540@guns.lerc.nasa.gov> Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1046981869.1223.48.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 06 Mar 2003 14:17:50 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2003 20:17:52.0012 (UTC) FILETIME=[76EB6CC0:01C2E41D] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Marc, On Thu, 2003-03-06 at 13:02, ext Mark Allman wrote: > > Yogesh Prem Swami spake unto us the following wisdom: > > > As long as spurious timeouts happen once in a while, it might be > > > acceptable to restore the window. But once the number of spurious > > > timeouts increases, the system will the hardly hit. > > > > Now on this point, I *completely* agree. Our experiments with > > DSACK suggested that if these bogus retransmissions (of any kind) > > are not curbed, they will become a significant problem in and of > > themselves. However, as Reiner has I believe pointed out in > > another part of this thread, this is a known problem ... and I > > would agree with you that it needs a little bit of face time in > > this draft or any other draft addressing the issue of allowing > > congestion state reversion. Obviously we do not want to > > continually take false timeouts and spew unnecessary retransmits > > into the network in any event. > > > > If this is the crux of your position, then I am in agreement. > > I agree that spuriously retransmitting continuously is a Bad Thing. > But, I want to note that Reiner's draft (& our draft on what to do > in the face of reordering) takes action to attempt to avoid this One can avoid (although I'm still skeptical how this can be done without hurting the thoughput in case of real timeouts) spurious timeouts if the same sender keeps timing out over and over again. But if the sender's are new each time--which is most likey the case--then one cannot do anything. The effect on the network is, however, still the same. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 16:26:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13296 for ; Thu, 6 Mar 2003 16:26:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26Lbc716846 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 16:37:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Lb1O16099; Thu, 6 Mar 2003 16:37:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KhkO12423 for ; Thu, 6 Mar 2003 15:43:46 -0500 Received: from seraph3.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11485 for ; Thu, 6 Mar 2003 15:32:06 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id D1DCD6BA62 for ; Thu, 6 Mar 2003 15:34:09 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h26KY87h000757; Thu, 6 Mar 2003 15:34:08 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id PAA24035; Thu, 6 Mar 2003 15:34:08 -0500 (EST) Message-Id: <200303062034.PAA24035@guns.lerc.nasa.gov> To: Yogesh Prem Swami From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: Ethan Blanton , ext Reiner Ludwig , tsvwg@ietf.org Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <1046981869.1223.48.camel@atcp01.americas.nokia.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Walk on the Wild Side Date: Thu, 06 Mar 2003 15:34:08 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > > I agree that spuriously retransmitting continuously is a Bad > > Thing. But, I want to note that Reiner's draft (& our draft on > > what to do in the face of reordering) takes action to attempt to > > avoid this > > One can avoid (although I'm still skeptical how this can be done > without hurting the thoughput in case of real timeouts) spurious > timeouts if the same sender keeps timing out over and over > again. You want to eat your cake, too? > But if the sender's are new each time--which is most likey the > case--then one cannot do anything. The effect on the network is, > however, still the same. Good point. (A theoretical argument is that we could share this information between connections. That might help some. But, in practice we don't share information -- and, I am not even sure how much it would help in this case.) allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 16:34:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13683 for ; Thu, 6 Mar 2003 16:34:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26LjBB17538 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 16:45:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26LihO17492; Thu, 6 Mar 2003 16:44:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KKlO10383 for ; Thu, 6 Mar 2003 15:20:47 -0500 Received: from seraph2.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10152 for ; Thu, 6 Mar 2003 15:09:05 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 951CF689C3 for ; Thu, 6 Mar 2003 15:11:10 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h26KB97h024469; Thu, 6 Mar 2003 15:11:09 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id PAA23741; Thu, 6 Mar 2003 15:11:09 -0500 (EST) Message-Id: <200303062011.PAA23741@guns.lerc.nasa.gov> To: Yogesh Prem Swami From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: ext Reiner Ludwig , tsvwg@ietf.org, "Ethan Blanton" Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <1046886587.22268.98.camel@atcp01.americas.nokia.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Walk on the Wild Side Date: Thu, 06 Mar 2003 15:11:09 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > -- The bottom line for a spurious timeout is that a spurious > timeout is spurious ONLY in terms of what packets to resend; its > not spurious in terms of congestion. > > [...] > > Restoring congestion window after a timeout is WRONG. I think you bring up an interesting thought. I am not sure we have ever actually defined what "congestion" means in an RFC (and, if we have someone please correct me). We use drops as implicit indications of "congestion". We use ECN bits as explicit indications of "congestion". However, that does not preclude the use of other indications, I would say. So then the question is: when the retransmission timer fires what part of that process is the congestion indication? * Is it the unexpectedly long time we spent waiting for feedback (an ACK) for some segment? * Or, is it that we believe something has been dropped (and, so we are now retransmitting)? I *think* I have a hit on this. But, I am going to roll it around my head a bit so I can be coherent when I try to explain it. But, I'd be interested in hearing other's thoughts, too. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 20:18:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22794 for ; Thu, 6 Mar 2003 20:18:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h271TYh03320 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 20:29:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271SSO03269; Thu, 6 Mar 2003 20:28:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271RIO03207 for ; Thu, 6 Mar 2003 20:27:18 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22720 for ; Thu, 6 Mar 2003 20:15:30 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 93C3A9DF8; Thu, 6 Mar 2003 20:17:35 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 466899DF7; Thu, 6 Mar 2003 20:17:34 -0500 (EST) Date: Thu, 6 Mar 2003 20:17:34 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Yogesh Prem Swami Cc: , ext Reiner Ludwig , Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <1046980795.1225.38.camel@atcp01.americas.nokia.com> Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On 6 Mar 2003, Yogesh Prem Swami wrote: > Yes, I agree that the sender has a some stale information about the > state of the network, but that information, as you note, might not be of > any use. The answer to the question of how good the information actually > is, depends on the how long the spurious timeout lasted > > Let us do some simplified calculations (I am using the same calculation > in my DCLOR draft; I apologize if you have already seen this). Lets say > there are M competing connection (apart from the connection which was > interrupted) and each of them has a Round Trip Time or R (this is a > simplifying assumption; I am by no means suggestion it's the case). > Let's also say that that the stalling duration is K*R, where K is some > integer constant (again just a simplified case to the feel for things). > Let's also assume that all the competing connections were doing > congestion aovidance. > > In this case while the stalled connection was waiting for > acknowledgements, rest of the M competing connections would increase > their congestoin window 1 segment per RTT. So by the end of the spurious > timeout, the effective buffer space for the defaulting connection will > become: > > cwnd - M*K > > > As we can see this number grows linealy with K (that is the stalling > period) and with the number of competing connections. There is NO way > for a TCP sender to know how many competing connections are there in the > system. I think you have a flaw in your analysis. You are assuming that the competing flows are synchronized, which is not the case in a real networks. I agree with you that the "available bandwidth" for a flow does fluctuate, but you cannot simply say that one TCP connection reducing its sending rate will cause others to increase x amount in y amount of time. The congestion state at routers is bursty... connections may get drops just because of coincidental burst at the time it decided to send. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 20:25:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23079 for ; Thu, 6 Mar 2003 20:25:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h271ac603684 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 20:36:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271aCO03672; Thu, 6 Mar 2003 20:36:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271ZmO03620 for ; Thu, 6 Mar 2003 20:35:48 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23056 for ; Thu, 6 Mar 2003 20:24:00 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id B10AC9DF8; Thu, 6 Mar 2003 20:26:05 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 8D1939DAA; Thu, 6 Mar 2003 20:26:04 -0500 (EST) Date: Thu, 6 Mar 2003 20:26:04 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Mark Allman Cc: Yogesh Prem Swami , Ethan Blanton , ext Reiner Ludwig , Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <200303062034.PAA24035@guns.lerc.nasa.gov> Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Thu, 6 Mar 2003, Mark Allman wrote: > > But if the sender's are new each time--which is most likey the > > case--then one cannot do anything. The effect on the network is, > > however, still the same. > > Good point. > > (A theoretical argument is that we could share this information > between connections. That might help some. But, in practice we > don't share information -- and, I am not even sure how much it would > help in this case.) I don't think sharing this information makes much sense. My understanding is that detecting spurious timeouts is useful in wireless scenarios where RTTs may fluctuate much more due to L2 rtxs. In these cases, spikes in RTTs are probably due noise, which is temporary. Thus, it is not something meaningful to convey to other new connections. For wired netwoks, RTT spikes are less frequent, but still not meaningful to share. PLEASE correct me if I am totally off here... ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 20:27:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23142 for ; Thu, 6 Mar 2003 20:27:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h271co104567 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 20:38:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271c3O04525; Thu, 6 Mar 2003 20:38:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271beO04493 for ; Thu, 6 Mar 2003 20:37:40 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23093 for ; Thu, 6 Mar 2003 20:25:52 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id C76FF9DFC; Thu, 6 Mar 2003 20:27:57 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 70A289DF5; Thu, 6 Mar 2003 20:27:56 -0500 (EST) Date: Thu, 6 Mar 2003 20:27:56 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Mark Allman Cc: Yogesh Prem Swami , ext Reiner Ludwig , Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <200303061920.OAA23101@guns.lerc.nasa.gov> Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Thu, 6 Mar 2003, Mark Allman wrote: > > If I go by this logic, then why shall I start with a small window > > size at the start of the connection? At the start of the > > connection I have no congestion indication, so I should be able to > > send what ever amount of data I want? > > > > Are you suggesting we should start with a window of say 10M bytes > > and wait until we receive congestion indication? Your logic seems > > to imply that. > > I disagree with the above analysis. I hope the following is very > neutral -- I mean it to neither support nor refute your overall > argument (I am still rolling that around in my head). > > At the beginning of a connection you have no congestion indication, > indeed. But, also you have no indication of what the cwnd ought to > be. Now THIS information would be a good idea to share :-) (Yeah, I know... people have already thought of that) ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 6 20:34:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23305 for ; Thu, 6 Mar 2003 20:34:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h271jkr04949 for tsvwg-archive@odin.ietf.org; Thu, 6 Mar 2003 20:45:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271j9O04929; Thu, 6 Mar 2003 20:45:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271imO04892 for ; Thu, 6 Mar 2003 20:44:48 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23280 for ; Thu, 6 Mar 2003 20:33:00 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id A6E3F9E00; Thu, 6 Mar 2003 20:35:05 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 2895F9E02; Thu, 6 Mar 2003 20:35:04 -0500 (EST) Date: Thu, 6 Mar 2003 20:35:04 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Mark Allman Cc: Yogesh Prem Swami , ext Reiner Ludwig , , Ethan Blanton Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <200303062011.PAA23741@guns.lerc.nasa.gov> Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Thu, 6 Mar 2003, Mark Allman wrote: > So then the question is: when the retransmission timer fires what > part of that process is the congestion indication? > > * Is it the unexpectedly long time we spent waiting for feedback > (an ACK) for some segment? > > * Or, is it that we believe something has been dropped (and, so we > are now retransmitting)? Both :-) It's just that the drop is a clearer indiation (in wired networks) that there is congestion. Without the loss, a long delay does imply congestion, but the question is how to act on it. I believe that TCP Westwood and TCP Vegas provide some direction here. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 7 03:20:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14288 for ; Fri, 7 Mar 2003 03:20:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h278Va028543 for tsvwg-archive@odin.ietf.org; Fri, 7 Mar 2003 03:31:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h278UWO28497; Fri, 7 Mar 2003 03:30:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h278TwO28440 for ; Fri, 7 Mar 2003 03:29:59 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14241 for ; Fri, 7 Mar 2003 03:18:02 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h278NQF25199 for ; Fri, 7 Mar 2003 10:23:26 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Mar 2003 10:20:05 +0200 Received: from sahaja.research.nokia.com ([172.21.40.118]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 10:20:04 +0200 Subject: Re: [Tsvwg] Eifel-Response-03 From: Pasi Sarolahti To: "Armando L. Caro Jr." Cc: Mark Allman , Yogesh Prem Swami , ext Reiner Ludwig , tsvwg@ietf.org, Ethan Blanton In-Reply-To: References: Content-Type: text/plain Organization: Nokia Research Center Message-Id: <1047025203.3149.47.camel@optiplex> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Mar 2003 10:20:04 +0200 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Mar 2003 08:20:04.0494 (UTC) FILETIME=[5B1772E0:01C2E482] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Fri, 2003-03-07 at 03:35, ext Armando L. Caro Jr. wrote: > On Thu, 6 Mar 2003, Mark Allman wrote: > > > So then the question is: when the retransmission timer fires what > > part of that process is the congestion indication? > > > > * Is it the unexpectedly long time we spent waiting for feedback > > (an ACK) for some segment? > > > > * Or, is it that we believe something has been dropped (and, so we > > are now retransmitting)? > > Both :-) It's just that the drop is a clearer indiation (in wired > networks) that there is congestion. Without the loss, a long delay does > imply congestion, but the question is how to act on it. I believe that TCP > Westwood and TCP Vegas provide some direction here. I agree. We were suggesting in the F-RTO draft that cwnd & ssthresh would be reduced by some amount (halving was suggested) after detecting spurious RTO. Some problem cases were pointed out with that approach (possible underutilization of the pipe in congestion avoidance, especially when RTO occurs in the beginning of connection) but I still think it could be one way to go, at least with some modifications. One alternative could be, for example, reducing only cwnd and keeping ssthresh at a higher level, which starts to be quite close to RFC2861, I think. In any case, I think it might be useful to have the different potential response alternatives documented with some background why the particular response is justifiable. From the reader's perspective it might be better to have them all in the same covers, but I don't know if folks here are willing to go that way. - Pasi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 7 03:39:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14669 for ; Fri, 7 Mar 2003 03:39:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h278omQ30256 for tsvwg-archive@odin.ietf.org; Fri, 7 Mar 2003 03:50:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h278nAO30153; Fri, 7 Mar 2003 03:49:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h278lLO30076 for ; Fri, 7 Mar 2003 03:47:21 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14605 for ; Fri, 7 Mar 2003 03:35:23 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h278a8117320 for ; Fri, 7 Mar 2003 10:36:08 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Mar 2003 10:37:27 +0200 Received: from sahaja.research.nokia.com ([172.21.40.118]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 10:37:26 +0200 Subject: Re: [Tsvwg] Eifel-Response-03 From: Pasi Sarolahti To: mallman@grc.nasa.gov Cc: Yogesh Prem Swami , Ethan Blanton , ext Reiner Ludwig , tsvwg@ietf.org In-Reply-To: <200303062034.PAA24035@guns.lerc.nasa.gov> References: <200303062034.PAA24035@guns.lerc.nasa.gov> Content-Type: text/plain Organization: Nokia Research Center Message-Id: <1047026246.3146.60.camel@optiplex> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Mar 2003 10:37:26 +0200 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Mar 2003 08:37:26.0672 (UTC) FILETIME=[C8473100:01C2E484] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 2003-03-06 at 22:34, ext Mark Allman wrote: > > But if the sender's are new each time--which is most likey the > > case--then one cannot do anything. The effect on the network is, > > however, still the same. > > Good point. > > (A theoretical argument is that we could share this information > between connections. That might help some. But, in practice we > don't share information -- and, I am not even sure how much it would > help in this case.) Btw, that is not necessarily so theoretical. E.g. Linux stores the recent values of ssthresh, rto-related parameters, observed reordering, etc. per destination and reuses them as initial values when new connections start up shortly. - Pasi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 7 07:27:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25396 for ; Fri, 7 Mar 2003 07:27:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27CcWi19772 for tsvwg-archive@odin.ietf.org; Fri, 7 Mar 2003 07:38:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CbaO19482; Fri, 7 Mar 2003 07:37:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27C6lO15818 for ; Fri, 7 Mar 2003 07:06:47 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21653; Fri, 7 Mar 2003 06:54:47 -0500 (EST) Message-Id: <200303071154.GAA21653@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: Fri, 07 Mar 2003 06:54:47 -0500 Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-tcp-mib-extension-03.txt Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --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 : TCP Extended Statistics MIB Author(s) : M. Mathis, J. Heffner Filename : draft-ietf-tsvwg-tcp-mib-extension-03.txt Pages : 50 Date : 2003-3-6 This draft describes extended performance statistics for TCP. They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application. If a network based application is performing poorly, TCP can determine if the bottleneck is in the sender, the receiver or the network itself. If the bottleneck is in the network, TCP can provide specific information about its nature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-mib-extension-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-tcp-mib-extension-03.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-tcp-mib-extension-03.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: <2003-3-6125508.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-tcp-mib-extension-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-tcp-mib-extension-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6125508.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 7 07:35:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26541 for ; Fri, 7 Mar 2003 07:35:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27Cko920805 for tsvwg-archive@odin.ietf.org; Fri, 7 Mar 2003 07:46:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CjTO20660; Fri, 7 Mar 2003 07:45:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CiVO20595 for ; Fri, 7 Mar 2003 07:44:31 -0500 Received: from pop-1.dnv.wideopenwest.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26183 for ; Fri, 7 Mar 2003 07:32:20 -0500 (EST) Received: from thoth.ir.bbn.com (d53-66-209.clv.wideopenwest.com [64.53.209.66]) by pop-1.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h27CcLh22462; Fri, 7 Mar 2003 06:38:21 -0600 Received: from thoth.ir.bbn.com (localhost [127.0.0.1]) by thoth.ir.bbn.com (8.12.6/8.12.6) with ESMTP id h27CYTqH052720; Fri, 7 Mar 2003 07:34:29 -0500 (EST) (envelope-from mallman@thoth.ir.bbn.com) Message-Id: <200303071234.h27CYTqH052720@thoth.ir.bbn.com> To: Yogesh Prem Swami From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: ext Reiner Ludwig , tsvwg@ietf.org Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <1046980795.1225.38.camel@atcp01.americas.nokia.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Walk on the Wild Side Date: Fri, 07 Mar 2003 07:34:29 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > Let us do some simplified calculations I'm not yet convinced that your analysis is right because... + If the delay spike is on a shared portion of the network then chances are multiple connections will suffer the effects. You assume only one connection will. + If the delay spike is on a non-shared network then your notion that other connections will take the resources once used by the transfer that spuriously retransmitted is right, I think. But, in that case, when the transfer that spuriously retransmitted figures it out and reverts the CC state, isn't that OK? That is, the other connections have more than their share and the connection in question has less than its fair share of the shared network resources. (And, also note that the increased traffic is not introduced as a huge burst.) + Unfortunately, real networks are not quite as static as you have sketched - with connections coming and going, and connections experiencing loss (from the non-shared network), and apps limiting the sending, and a thousand other things. So, I think it is pretty hard to use a back-of-the-envelope calculation to argue that the eifel-response is going to hurt the overall system. > BTW, it's useful to point out that fast-retransmit, fast-recovery > recovers one packet per RTT. On the other hand, Slow start can > recover packet at a much faster rate if the number of lost packets > is large. There is a lot more information in Janey C. Hoe's MS > thesis (Strart Up dynamics of TCP's congestion control and > avoidance schemes) Or in RFC 2582. > So coming back to the argument of initial window, a spurious > timeout is no different from a new connection. The information > that the sender has is too old and has no value. So, I am still unconvinced that these two cases are the same. I might be happy with a scheme that sort of followed RFC 2861 -- i.e., when we detect a spurious retransmit via the RTO we look at the elapsed time between when sending that retransmit and sending whatever data segment we sent prior to that. For each RTO seconds that have elapsed we reduce cwnd_prev by half. That places some value on the previous CC state, but at the same time takes into account that the connection has not been validating its cwnd for some time. (And, if enough time passes the old cwnd information will be "too old" and have "no value", but that case does not happen immediately and simply by virtue of the fact that the RTO fired.) allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 7 08:27:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00604 for ; Fri, 7 Mar 2003 08:27:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27Dcr025393 for tsvwg-archive@odin.ietf.org; Fri, 7 Mar 2003 08:38:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27DbvO25371; Fri, 7 Mar 2003 08:37:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27DarO24507 for ; Fri, 7 Mar 2003 08:36:53 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00248 for ; Fri, 7 Mar 2003 08:24:51 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h27DQswv023126; Fri, 7 Mar 2003 14:26:54 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F5W999CY; Fri, 7 Mar 2003 14:26:53 +0100 Received: from res0010384da36.eed.ericsson.se (dhcp5-197 [164.48.135.197]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id OAA06103; Fri, 7 Mar 2003 14:26:45 +0100 (MET) Message-Id: <5.1.0.14.0.20030307141843.02ae1e18@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Mar 2003 14:26:41 +0100 To: "Armando L. Caro Jr." From: Reiner Ludwig Subject: Re: [Tsvwg] Eifel-Response-03 Cc: tsvwg@ietf.org In-Reply-To: References: <5.1.0.14.0.20030306130447.027d9c58@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 17:28 06.03.2003, Armando L. Caro Jr. wrote: >I quickly skimmed the draft and saw on page 5, the step for reverting cwnd >includes the following text: > > If the acceptable ACK has the ECN-Echo flag [RFC3168] set > OR the TCP sender has already taken more than three > timeouts for the oldest outstanding segment, then proceed > to step (DONE), > >How was the value three chosen? Out of the hat. It's up for debate. The question is: How many spurious timeouts in a row, i.e., for the same outstanding sequence number, are OK to still restore congetsion control state? In an earlier proposal, we suggested "full restore" for the first spurious timeout, "half restore" for the second spurious timeout, etc. (see http://iceberg.cs.berkeley.edu/papers/Ludwig-Eifel-Alg/index.html) ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 7 08:42:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01367 for ; Fri, 7 Mar 2003 08:42:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27Drp826319 for tsvwg-archive@odin.ietf.org; Fri, 7 Mar 2003 08:53:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Dr8O26273; Fri, 7 Mar 2003 08:53:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Dq0O26202 for ; Fri, 7 Mar 2003 08:52:00 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01263 for ; Fri, 7 Mar 2003 08:39:57 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h27DfsB3025071; Fri, 7 Mar 2003 14:41:54 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F5X2HPRY; Fri, 7 Mar 2003 14:41:52 +0100 Received: from res0010384da36.eed.ericsson.se (dhcp5-197 [164.48.135.197]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id OAA09468; Fri, 7 Mar 2003 14:41:50 +0100 (MET) Message-Id: <5.1.0.14.0.20030307143505.02afecf0@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Mar 2003 14:41:45 +0100 To: Randall Stewart From: Reiner Ludwig Subject: Re: [Tsvwg] Eifel-Response-03 Cc: tsvwg@ietf.org In-Reply-To: <3E6788BC.1020500@stewart.chicago.il.us> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 18:43 06.03.2003, Randall Stewart wrote: >I think FWIW I am ok with restoring to min(prevfs, (currfs+IW)) > >But I do have one question.. > >Would this ever other return anything but currfs+IW? Yes, it can. If the TCP sender was in congestion avoidance (FlightSize >= ssthresh) when a spurious timeout occurs, no data segments and no ACKs get lost, then cwnd == pipe_prev (== value of FlightSize when the timeout occurs) after step (ReCC) of the algorithm. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 7 09:09:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02994 for ; Fri, 7 Mar 2003 09:09:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27EKpN28864 for tsvwg-archive@odin.ietf.org; Fri, 7 Mar 2003 09:20:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27EKAO28831; Fri, 7 Mar 2003 09:20:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27EJYO28774 for ; Fri, 7 Mar 2003 09:19:34 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02868 for ; Fri, 7 Mar 2003 09:07:30 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h27E9XB3003261; Fri, 7 Mar 2003 15:09:33 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVM5WSG; Fri, 7 Mar 2003 15:09:32 +0100 Received: from res0010384da36.eed.ericsson.se (dhcp5-197 [164.48.135.197]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id PAA15505; Fri, 7 Mar 2003 15:08:31 +0100 (MET) Message-Id: <5.1.0.14.0.20030307150242.02abcc68@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Mar 2003 15:08:26 +0100 To: mallman@grc.nasa.gov From: Reiner Ludwig Subject: Re: [Tsvwg] Eifel-Response-03 Cc: tsvwg@ietf.org In-Reply-To: <200303062011.PAA23741@guns.lerc.nasa.gov> References: <1046886587.22268.98.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 21:11 06.03.2003, Mark Allman wrote: >So then the question is: when the retransmission timer fires what >part of that process is the congestion indication? > > * Is it the unexpectedly long time we spent waiting for feedback > (an ACK) for some segment? > > * Or, is it that we believe something has been dropped (and, so we > are now retransmitting)? > >I *think* I have a hit on this. But, I am going to roll it around >my head a bit so I can be coherent when I try to explain it. But, >I'd be interested in hearing other's thoughts, too. RFCs 2309, and 2914 only talk about "packet drop" as the congestion signal. On the other hand, I certainly agree that the we cannot fully reverse congestion control state when the sender hasn't probed the network for some time. We thought 3 timeouts in a row should be an OK time. But maybe we should go back to the previous approach of halving pipe_prev for every RTO (backed-off or not?). ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 7 09:24:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04144 for ; Fri, 7 Mar 2003 09:24:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27EZa229826 for tsvwg-archive@odin.ietf.org; Fri, 7 Mar 2003 09:35:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27EZ8O29749; Fri, 7 Mar 2003 09:35:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27EWFO29572 for ; Fri, 7 Mar 2003 09:32:15 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03798 for ; Fri, 7 Mar 2003 09:20:11 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h27EMGB3006277; Fri, 7 Mar 2003 15:22:16 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVM550G; Fri, 7 Mar 2003 15:22:15 +0100 Received: from res0010384da36.eed.ericsson.se (dhcp5-197 [164.48.135.197]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id PAA18328; Fri, 7 Mar 2003 15:22:12 +0100 (MET) Message-Id: <5.1.0.14.0.20030307151016.02ab1c90@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Mar 2003 15:22:07 +0100 To: Yogesh Prem Swami From: Reiner Ludwig Cc: tsvwg@ietf.org In-Reply-To: <1046973094.24704.108.camel@atcp01.americas.nokia.com> References: <20030306172002.GC10705@paco.resnet.purdue.edu> <5.1.0.14.0.20030305124425.02b2b490@mailhost.eed.ericsson.se> <5.1.0.14.0.20030305124425.02b2b490@mailhost.eed.ericsson.se> <5.1.0.14.0.20030306130447.027d9c58@mailhost.eed.ericsson.se> <1046968251.24703.49.camel@atcp01.americas.nokia.com> <20030306172002.GC10705@paco.resnet.purdue.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Tsvwg] The Eifel-Response is conservative ... Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , ... at least compared to the current TCP that after a spurious timeout sends (often) useless go-back-Ns in slow-start, and thereby breaking 'packet conservation'. With the Eifel-Response + advanced loss recovery, 'packet conservation' is preserved *and* useful restransmits are sent. You make it look as if the Eifel-Response was aggressive. This is not the case. For example, if the TCP sender was in congestion avoidance before the spurious timeout, then it will simply return to that state with the Eifel response. I.e., each of the (late) original ACKs will nicely clock out one or two (in case of delayed ACKs) new data segment(s). ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 7 11:14:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13427 for ; Fri, 7 Mar 2003 11:14:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27GQ6A08973 for tsvwg-archive@odin.ietf.org; Fri, 7 Mar 2003 11:26:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27GPNO08924; Fri, 7 Mar 2003 11:25:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27GOCO08693 for ; Fri, 7 Mar 2003 11:24:12 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13122 for ; Fri, 7 Mar 2003 11:12:07 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27GCn120679 for ; Fri, 7 Mar 2003 18:12:49 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Mar 2003 18:14:09 +0200 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 18:14:09 +0200 Subject: Re: [Tsvwg] Eifel-Response-03 From: Yogesh Prem Swami To: "Armando L. Caro Jr." Cc: mallman@grc.nasa.gov, ext Reiner Ludwig , tsvwg@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1047053647.3377.22.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 07 Mar 2003 10:14:07 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Mar 2003 16:14:09.0704 (UTC) FILETIME=[95C20A80:01C2E4C4] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 2003-03-06 at 19:17, ext Armando L. Caro Jr. wrote: > On 6 Mar 2003, Yogesh Prem Swami wrote: > > > Yes, I agree that the sender has a some stale information about the > > state of the network, but that information, as you note, might not be of > > any use. The answer to the question of how good the information actually > > is, depends on the how long the spurious timeout lasted > > > > Let us do some simplified calculations (I am using the same calculation > > in my DCLOR draft; I apologize if you have already seen this). Lets say > > there are M competing connection (apart from the connection which was > > interrupted) and each of them has a Round Trip Time or R (this is a > > simplifying assumption; I am by no means suggestion it's the case). > > Let's also say that that the stalling duration is K*R, where K is some > > integer constant (again just a simplified case to the feel for things). > > Let's also assume that all the competing connections were doing > > congestion aovidance. > > > > In this case while the stalled connection was waiting for > > acknowledgements, rest of the M competing connections would increase > > their congestoin window 1 segment per RTT. So by the end of the spurious > > timeout, the effective buffer space for the defaulting connection will > > become: > > > > cwnd - M*K > > > > > > As we can see this number grows linealy with K (that is the stalling > > period) and with the number of competing connections. There is NO way > > for a TCP sender to know how many competing connections are there in the > > system. > > I think you have a flaw in your analysis. You are assuming that the > competing flows are synchronized, which is not the case in a real > networks. I agree with you that the "available bandwidth" for a flow does > fluctuate, but you cannot simply say that one TCP connection reducing its > sending rate will cause others to increase x amount in y amount of time. > The congestion state at routers is bursty... connections may get drops > just because of coincidental burst at the time it decided to send. > Armando, There is no flaw in the analysis, although I do agree that the number M*K is the upper bound--asuuming no non TCP connections. TCP has such a choatic behavior it's impossible to have a realistic analysis on paper. The idea behind the analysis is to demonstrate that the congestion state in the network is not going to remain the same after an RTO, so the sender cannot start from it left. The analysis also gives a good idea how the number of connections affects the overall process. If you have too many connections in the system, chances are your old congestion state will be of no value at all. This is also one of the reasons why I asked for a standarad simulation environment against which we can evaluate different schemes. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 7 11:36:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15186 for ; Fri, 7 Mar 2003 11:36:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27Gm6e11170 for tsvwg-archive@odin.ietf.org; Fri, 7 Mar 2003 11:48:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27GlJO11094; Fri, 7 Mar 2003 11:47:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27GkMO11057 for ; Fri, 7 Mar 2003 11:46:22 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15120 for ; Fri, 7 Mar 2003 11:34:15 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27GdfF00774 for ; Fri, 7 Mar 2003 18:39:41 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Mar 2003 18:36:17 +0200 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 18:36:17 +0200 Subject: Re: [Tsvwg] Eifel-Response-03 From: Yogesh Prem Swami To: mallman@grc.nasa.gov Cc: ext Reiner Ludwig , tsvwg@ietf.org In-Reply-To: <200303071234.h27CYTqH052720@thoth.ir.bbn.com> References: <200303071234.h27CYTqH052720@thoth.ir.bbn.com> Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1047054975.3376.44.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 07 Mar 2003 10:36:15 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Mar 2003 16:36:17.0615 (UTC) FILETIME=[AD412DF0:01C2E4C7] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mark, On Fri, 2003-03-07 at 06:34, ext Mark Allman wrote: > > Let us do some simplified calculations > > I'm not yet convinced that your analysis is right because... > > + If the delay spike is on a shared portion of the network then > chances are multiple connections will suffer the effects. You > assume only one connection will. Well the argument in my analysis assumes that the bottle neck router (the router that has minumum buffer_space/|different in outgoing link speed and incoming| ratio on the end to end path) and the point where packets are stalled are different. That's why there is just one TCP conenction. This is a very realistic scenario. Here is figure from the DCLOR draft: C(1) C(2)... C(M) | | ... | | | ... | | | ... | V V ... V \ \ / \ \ / \ \ / +------X--X--X---+ +------------------+ Defaulting | | | | C(0) ----------->| Bottleneck |------>|Buffered packets |---> connection | router | | | +-----X--X----X--+ +------------------+ | | | | | | c(1)c(2) C(M) The M connections I was talking about go through the bottle neck router. > > + If the delay spike is on a non-shared network then your notion > that other connections will take the resources once used by the > transfer that spuriously retransmitted is right, I think. But, > in that case, when the transfer that spuriously retransmitted > figures it out and reverts the CC state, isn't that OK? That > is, the other connections have more than their share and the > connection in question has less than its fair share of the > shared network resources. (And, also note that the increased > traffic is not introduced as a huge burst.) > Yes the increased traffic has not introduced the burst, but the Eifel response has. Also, why should the other traffic which didn't go through spurious timeout suffer because of the burst caused by Eifel response. Problem with such bursts is that some connections might get unnecessarily penalized (for example a connection which was just starting). > + Unfortunately, real networks are not quite as static as you have > sketched - with connections coming and going, and connections > experiencing loss (from the non-shared network), and apps > limiting the sending, and a thousand other things. So, I think > it is pretty hard to use a back-of-the-envelope calculation to > argue that the eifel-response is going to hurt the overall > system. > Completely agree. I won't bet a penny on that analysis. But the point is that the congestion state of the system is not going to remain the same. I gess I got that idea across so the analysis has served its purpose. > > BTW, it's useful to point out that fast-retransmit, fast-recovery > > recovers one packet per RTT. On the other hand, Slow start can > > recover packet at a much faster rate if the number of lost packets > > is large. There is a lot more information in Janey C. Hoe's MS > > thesis (Strart Up dynamics of TCP's congestion control and > > avoidance schemes) > > Or in RFC 2582. > > > So coming back to the argument of initial window, a spurious > > timeout is no different from a new connection. The information > > that the sender has is too old and has no value. > > So, I am still unconvinced that these two cases are the same. > > I might be happy with a scheme that sort of followed RFC 2861 -- > i.e., when we detect a spurious retransmit via the RTO we look at > the elapsed time between when sending that retransmit and sending > whatever data segment we sent prior to that. For each RTO seconds > that have elapsed we reduce cwnd_prev by half. That places some > value on the previous CC state, but at the same time takes into > account that the connection has not been validating its cwnd for > some time. (And, if enough time passes the old cwnd information > will be "too old" and have "no value", but that case does not happen > immediately and simply by virtue of the fact that the RTO fired.) That's precisely my point. Except, this scheme will not work when there are spurious timeouts due to subnet change. Not compaining too much though. I hope we (except Reiner) agree that Eifel Response is Myopic in it's approach. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 7 11:57:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16374 for ; Fri, 7 Mar 2003 11:57:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27H8pq13224 for tsvwg-archive@odin.ietf.org; Fri, 7 Mar 2003 12:08:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27H87O13166; Fri, 7 Mar 2003 12:08:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27GvYO11759 for ; Fri, 7 Mar 2003 11:57:34 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15665 for ; Fri, 7 Mar 2003 11:45:28 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27GkB107258 for ; Fri, 7 Mar 2003 18:46:11 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Mar 2003 18:47:31 +0200 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 18:47:31 +0200 Subject: Re: [Tsvwg] Eifel-Response-03 From: Yogesh Prem Swami To: ext Reiner Ludwig Cc: mallman@grc.nasa.gov, tsvwg@ietf.org In-Reply-To: <5.1.0.14.0.20030307150242.02abcc68@mailhost.eed.ericsson.se> References: <1046886587.22268.98.camel@atcp01.americas.nokia.com> <5.1.0.14.0.20030307150242.02abcc68@mailhost.eed.ericsson.se> Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1047055649.3377.56.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 07 Mar 2003 10:47:29 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Mar 2003 16:47:31.0533 (UTC) FILETIME=[3EF0E7D0:01C2E4C9] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Fri, 2003-03-07 at 08:08, ext Reiner Ludwig wrote: > At 21:11 06.03.2003, Mark Allman wrote: > >So then the question is: when the retransmission timer fires what > >part of that process is the congestion indication? > > > > * Is it the unexpectedly long time we spent waiting for feedback > > (an ACK) for some segment? > > > > * Or, is it that we believe something has been dropped (and, so we > > are now retransmitting)? > > > >I *think* I have a hit on this. But, I am going to roll it around > >my head a bit so I can be coherent when I try to explain it. But, > >I'd be interested in hearing other's thoughts, too. > > RFCs 2309, and 2914 only talk about "packet drop" as the congestion signal. > On the other hand, I certainly agree that the we cannot fully reverse > congestion control state when the sender hasn't probed the network for some > time. We thought 3 timeouts in a row should be an OK time. But maybe we 3 timeouts are too long--it roughly (1+2+4)*(3*RTT) = 21*RTT (I have replaced RTO with 3RTT for simplicity; that's ofcourse not always the case). The best approach is to 1/2 the data rate every RTO as Mark (and RFC 2861) pointed out in his last e-mail. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 7 12:10:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17321 for ; Fri, 7 Mar 2003 12:10:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27HMWH15258 for tsvwg-archive@odin.ietf.org; Fri, 7 Mar 2003 12:22:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HM0O15025; Fri, 7 Mar 2003 12:22:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HFxO14021 for ; Fri, 7 Mar 2003 12:15:59 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16732 for ; Fri, 7 Mar 2003 12:03:53 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27H4a117039 for ; Fri, 7 Mar 2003 19:04:36 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Mar 2003 19:05:56 +0200 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 19:05:56 +0200 From: Yogesh Prem Swami To: ext Reiner Ludwig Cc: tsvwg@ietf.org In-Reply-To: <5.1.0.14.0.20030307151016.02ab1c90@mailhost.eed.ericsson.se> References: <20030306172002.GC10705@paco.resnet.purdue.edu> <5.1.0.14.0.20030305124425.02b2b490@mailhost.eed.ericsson.se> <5.1.0.14.0.20030305124425.02b2b490@mailhost.eed.ericsson.se> <5.1.0.14.0.20030306130447.027d9c58@mailhost.eed.ericsson.se> <1046968251.24703.49.camel@atcp01.americas.nokia.com> <20030306172002.GC10705@paco.resnet.purdue.edu> <5.1.0.14.0.20030307151016.02ab1c90@mailhost.eed.ericsson.se> Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1047056754.3376.73.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 07 Mar 2003 11:05:54 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Mar 2003 17:05:56.0523 (UTC) FILETIME=[D190FFB0:01C2E4CB] Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Re: The Eifel-Response is conservative ... Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Reiner, On Fri, 2003-03-07 at 08:22, ext Reiner Ludwig wrote: > ... at least compared to the current TCP that after a spurious timeout > sends (often) useless go-back-Ns in slow-start, and thereby breaking > 'packet conservation'. > With the Eifel-Response + advanced loss recovery, 'packet conservation' is > preserved *and* useful restransmits are sent. > Hate to repeat myself, but Packet conservation is meaningless after a timeout. To quote from VJ's paper--congestion control and avoidance (page 2, paragraph 4): "By conservation of packets we mean that for a connection in equilibrium , i.e., running stably with a full window of data in transit, the packet flow is what a physicist would call conservative ..." After a timeout, the sender is not "running stably with a full window of data." > You make it look as if the Eifel-Response was aggressive. This is not the I am not making Eifel Response "look" aggressive--it *is* agressive. And it's WRONG. --yogesh > case. For example, if the TCP sender was in congestion avoidance before the > spurious timeout, then it will simply return to that state with the Eifel > response. I.e., each of the (late) original ACKs will nicely clock out one > or two (in case of delayed ACKs) new data segment(s). > > ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 7 12:18:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17876 for ; Fri, 7 Mar 2003 12:18:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27HTbE16032 for tsvwg-archive@odin.ietf.org; Fri, 7 Mar 2003 12:29:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HTEO15969; Fri, 7 Mar 2003 12:29:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HQ8O15758 for ; Fri, 7 Mar 2003 12:26:08 -0500 Received: from seraph2.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17589 for ; Fri, 7 Mar 2003 12:14:02 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 412FA6899D for ; Fri, 7 Mar 2003 12:16:06 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h27HG57h002305; Fri, 7 Mar 2003 12:16:05 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id MAA36021; Fri, 7 Mar 2003 12:16:05 -0500 (EST) Message-Id: <200303071716.MAA36021@guns.lerc.nasa.gov> To: Yogesh Prem Swami From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: ext Reiner Ludwig , tsvwg@ietf.org Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <1047054975.3376.44.camel@atcp01.americas.nokia.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Superunknown Date: Fri, 07 Mar 2003 12:16:05 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , I understand the scenario you are assuming now. Thanks. > Yes the increased traffic has not introduced the burst, but the > Eifel response has. The eifel response calls for sending based on the ACK clock. And, the ACKs should be coming back at the rate the bottleneck link can support (in the return direction). So, we should not be sending a huge burst, but rather ACK clocking things out. (The ACK clock could be a bit off, I suppose. But it has to be better than a big line-rate burst.) > Also, why should the other traffic which didn't go through > spurious timeout suffer because of the burst caused by Eifel > response. Problem with such bursts is that some connections might > get unnecessarily penalized (for example a connection which was > just starting). To flip this around: Why should the connection through the link with the delay spike have to give up share through the bottleneck? Why does the fact that one of the links it traverses uses LL retransmits (that worked!) mean that it should get less resources through the bottleneck? These seem like orthogonal issues to me. > > I might be happy with a scheme that sort of followed RFC 2861 -- > > i.e., when we detect a spurious retransmit via the RTO we look > > at the elapsed time between when sending that retransmit and > > sending whatever data segment we sent prior to that. For each > > RTO seconds that have elapsed we reduce cwnd_prev by half. That > > places some value on the previous CC state, but at the same time > > takes into account that the connection has not been validating > > its cwnd for some time. (And, if enough time passes the old > > cwnd information will be "too old" and have "no value", but that > > case does not happen immediately and simply by virtue of the > > fact that the RTO fired.) > > That's precisely my point. Except, this scheme will not work when > there are spurious timeouts due to subnet change. Not compaining > too much though. I presume you mean because the new cwnd could have no resemblence to the previous cwnd. Is that right? This is a more general problem though -- if you switch to a subnet with drastically different properties then I think you're likely to get into some TCP ugliness whether there are spurious retransmits or not. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 7 13:16:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21312 for ; Fri, 7 Mar 2003 13:16:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27ISU723298 for tsvwg-archive@odin.ietf.org; Fri, 7 Mar 2003 13:28:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27IRvO23278; Fri, 7 Mar 2003 13:27:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27IQXO23223 for ; Fri, 7 Mar 2003 13:26:33 -0500 Received: from localhost.localdomain (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21275 for ; Fri, 7 Mar 2003 13:14:26 -0500 (EST) Received: (from elb@localhost) by localhost.localdomain (8.11.6/8.11.6) id h27IG0k15226; Fri, 7 Mar 2003 13:16:00 -0500 Date: Fri, 7 Mar 2003 13:16:00 -0500 From: Ethan Blanton To: Yogesh Prem Swami Cc: mallman@grc.nasa.gov, ext Reiner Ludwig , tsvwg@ietf.org Subject: Re: [Tsvwg] Eifel-Response-03 Message-ID: <20030307181600.GM10705@paco.resnet.purdue.edu> Mail-Followup-To: Yogesh Prem Swami , mallman@grc.nasa.gov, ext Reiner Ludwig , tsvwg@ietf.org References: <200303071234.h27CYTqH052720@thoth.ir.bbn.com> <1047054975.3376.44.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1047054975.3376.44.camel@atcp01.americas.nokia.com> User-Agent: Mutt/1.4i X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Yogesh Prem Swami spake unto us the following wisdom: > I hope we (except Reiner) agree that Eifel Response is Myopic in it's > approach. I'm not sure who "we" is at this point, but I do not agree. I think the basic plan of attack is valid. Ethan -- Happiness is a belt-fed weapon. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 7 14:08:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23525 for ; Fri, 7 Mar 2003 14:08:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27JJh128476 for tsvwg-archive@odin.ietf.org; Fri, 7 Mar 2003 14:19:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27JJDO28454; Fri, 7 Mar 2003 14:19:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27JIkO28416 for ; Fri, 7 Mar 2003 14:18:46 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23491 for ; Fri, 7 Mar 2003 14:06:37 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 22A319D8C; Fri, 7 Mar 2003 14:08:42 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id E24119DE0; Fri, 7 Mar 2003 14:08:39 -0500 (EST) Date: Fri, 7 Mar 2003 14:08:39 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Yogesh Prem Swami Cc: Ethan Blanton , , ext Reiner Ludwig , Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <20030307181600.GM10705@paco.resnet.purdue.edu> Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Fri, 7 Mar 2003, Ethan Blanton wrote: > Yogesh Prem Swami spake unto us the following wisdom: > > I hope we (except Reiner) agree that Eifel Response is Myopic in it's > > approach. > > I'm not sure who "we" is at this point, but I do not agree. I think > the basic plan of attack is valid. I too think the Eifel Response is fine. As Mark said in a previous mail, the cwnd is restored, but the acks are clocking out the data. The ack clock never went away... just delayed. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 7 14:37:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24521 for ; Fri, 7 Mar 2003 14:37:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27JmjD31334 for tsvwg-archive@odin.ietf.org; Fri, 7 Mar 2003 14:48:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27JmDO31310; Fri, 7 Mar 2003 14:48:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27JliO31276 for ; Fri, 7 Mar 2003 14:47:44 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24440 for ; Fri, 7 Mar 2003 14:35:34 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27JaK124889 for ; Fri, 7 Mar 2003 21:36:20 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Mar 2003 21:37:38 +0200 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Mar 2003 21:37:37 +0200 Subject: Re: [Tsvwg] Eifel-Response-03 From: Yogesh Prem Swami To: "Armando L. Caro Jr." Cc: Ethan Blanton , mallman@grc.nasa.gov, ext Reiner Ludwig , tsvwg@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1047065855.3376.232.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 07 Mar 2003 13:37:35 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Mar 2003 19:37:37.0925 (UTC) FILETIME=[026CBB50:01C2E4E1] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Fri, 2003-03-07 at 13:08, ext Armando L. Caro Jr. wrote: > > I'm not sure who "we" is at this point, but I do not agree. I think > > the basic plan of attack is valid. > > I too think the Eifel Response is fine. As Mark said in a previous mail, > the cwnd is restored, but the acks are clocking out the data. The ack > clock never went away... just delayed. > > ~armando The ACK clock is how you send new data into the network. Congestion response is about how you prevent unnecessary packet loss. These two are different issues. Ack clocking *can* be used to prevent congestion if these ACKs arrive in a regular fashion. If the ACKs don't arrive in a regular fashion, as in case of spurious timeout, they don't convey any information. If I go back to my previous figure Part-A Part-B sender-------> stalling node -------> receiver The ACKs are telling me that congestion on Part-B is fine. But is that sufficient to conclude that congestion on the entire Part-A + Part-B is fine? To me the answer seems to be no. In addition, the ACKs on Part-B will all arrive as a burst--depending upon how many hops are between stalling node and receiver (stating from my simulations). I still think that a well defined test can help. Based on the simulations, we can decide the right thing to do. After the tests, the working group might decide not to give so much importance to congestion after all, if something else of an algorithm is important. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 7 14:44:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24772 for ; Fri, 7 Mar 2003 14:44:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27JtdG31947 for tsvwg-archive@odin.ietf.org; Fri, 7 Mar 2003 14:55:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Jt4O31858; Fri, 7 Mar 2003 14:55:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Js8O31814 for ; Fri, 7 Mar 2003 14:54:08 -0500 Received: from seraph2.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24677 for ; Fri, 7 Mar 2003 14:41:57 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 1A2A4689DE for ; Fri, 7 Mar 2003 14:44:02 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h27Ji17h011739; Fri, 7 Mar 2003 14:44:01 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id OAA38558; Fri, 7 Mar 2003 14:44:00 -0500 (EST) Message-Id: <200303071944.OAA38558@guns.lerc.nasa.gov> To: Yogesh Prem Swami From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: "Armando L. Caro Jr." , Ethan Blanton , ext Reiner Ludwig , tsvwg@ietf.org Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <1047065855.3376.232.camel@atcp01.americas.nokia.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Superunknown Date: Fri, 07 Mar 2003 14:44:00 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > The ACK clock is how you send new data into the > network. Congestion response is about how you prevent unnecessary > packet loss. These two are different issues. Ack clocking *can* be > used to prevent congestion if these ACKs arrive in a regular > fashion. If the ACKs don't arrive in a regular fashion, as in case > of spurious timeout, they don't convey any information. I would phrase it "they may not convey any useful information". On the other hand, they will serve to prevent a complete line-rate burst (e.g., send N packets as fast as you can) even in the worst case. > I still think that a well defined test can help. Based on the > simulations, we can decide the right thing to do. I bet that with the right simulation I could make either case. That's the nice thing about simulations! :) (It's just a damn hard problem to come up with *the* simulation harness -- probably because there isn't one, IMO.) allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 7 14:44:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24794 for ; Fri, 7 Mar 2003 14:44:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27Jtl831968 for tsvwg-archive@odin.ietf.org; Fri, 7 Mar 2003 14:55:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27JtGO31897; Fri, 7 Mar 2003 14:55:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27JspO31831 for ; Fri, 7 Mar 2003 14:54:51 -0500 Received: from nit.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24720 for ; Fri, 7 Mar 2003 14:42:41 -0500 (EST) Received: (from falk@localhost) by nit.isi.edu (8.11.6/8.11.6) id h27Jih131250; Fri, 7 Mar 2003 11:44:43 -0800 Date: Fri, 7 Mar 2003 11:44:43 -0800 From: Aaron Falk To: Yogesh Prem Swami Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] Test environments for congestion response Message-ID: <20030307194443.GH15341@isi.edu> Mail-Followup-To: Yogesh Prem Swami , tsvwg@ietf.org References: <1046891029.22266.133.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1046891029.22266.133.camel@atcp01.americas.nokia.com> User-Agent: Mutt/1.4i Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Yogesh- You might find this of interest: http://www.acm.org/sigcomm/ccr/archive/1999/oct99/allman2.pdf --aaron Yogesh Prem Swami wrote: > Hi, > > I asked this in last IETF, but let me ask again. Since now we have many > congestion response algorithms, will it make sense to have a well > defined test environment against which authors can run their tests and > get results? The test environment could be an information RFC that can > be used in future too. > > In the past, I have seen various drafts and papers where authors want to > evaluate the congestion behavior of their algorithm, but they only use a > single TCP connection in the entire system. This approach sometimes > gives hundreds of percents of improvement and might suit the author > needs, but when these tests are run with multiple connections the > performance goes down significantly--sometimes below the performance of > existing algorithms. > > Having spent time trying to model networks, I understand that it's not > always possible to model a 100% realistic network, but leaving it > totally un-addressed is even worse. Probably it will be useful to have a > set of guidelines: have 10 TCP connections, 5 TFRC based connections > with 5k, 10K, 100K, ... file size, travesing 10 routers with certain > buffer spaces on the path, etc., etc. These numbers could be used from > the Internet measurements (BGP statistics ... ) > > I think whenever we have multiple schemes we must run the tests along > these guidelines and pick the scheme which comes up with the best > compromise in terms of congestion or whaever the working group deems > important. > > > --yogesh > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 7 14:54:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25349 for ; Fri, 7 Mar 2003 14:54:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27K5hc00564 for tsvwg-archive@odin.ietf.org; Fri, 7 Mar 2003 15:05:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27K5DO00538; Fri, 7 Mar 2003 15:05:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27K4IO00399 for ; Fri, 7 Mar 2003 15:04:18 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25279 for ; Fri, 7 Mar 2003 14:52:08 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8/8.12.3) with ESMTP id h27Js4oX001155; Fri, 7 Mar 2003 13:54:05 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E68F8DC.2090205@stewart.chicago.il.us> Date: Fri, 07 Mar 2003 13:54:04 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ethan Blanton CC: Yogesh Prem Swami , mallman@grc.nasa.gov, ext Reiner Ludwig , tsvwg@ietf.org Subject: Re: [Tsvwg] Eifel-Response-03 References: <200303071234.h27CYTqH052720@thoth.ir.bbn.com> <1047054975.3376.44.camel@atcp01.americas.nokia.com> <20030307181600.GM10705@paco.resnet.purdue.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ethan Blanton wrote: > Yogesh Prem Swami spake unto us the following wisdom: > >>I hope we (except Reiner) agree that Eifel Response is Myopic in it's >>approach. > > > I'm not sure who "we" is at this point, but I do not agree. I think > the basic plan of attack is valid. > > Ethan > Count me NOT in the "we" catagory... I am ok with Eifel's basic plan of attack as well.. R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 10 00:25:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05584 for ; Mon, 10 Mar 2003 00:25:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2A5cQT02408 for tsvwg-archive@odin.ietf.org; Mon, 10 Mar 2003 00:38:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A5YlO01565; Mon, 10 Mar 2003 00:34:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A5XIO01528 for ; Mon, 10 Mar 2003 00:33:18 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04456 for ; Mon, 10 Mar 2003 00:19:57 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:O2OKkJWKKOADX0jwPxJlqXXU+aQ+5DCH@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2A5EoD04722; Sun, 9 Mar 2003 22:14:50 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2A5EnP01712; Sun, 9 Mar 2003 22:14:49 -0700 Date: Sun, 9 Mar 2003 22:14:49 -0700 From: "Brian F. G. Bidulock" To: tsvwg@ietf.org Cc: sctp-impl@external.cisco.com Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-08.txt Message-ID: <20030309221449.A1547@openss7.org> Reply-To: bidulock@openss7.org References: <200303041230.HAA15062@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <200303041230.HAA15062@ietf.org>; from Internet-Drafts@ietf.org on Tue, Mar 04, 2003 at 07:30:07AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I have been told by an author of this document that this document is normative. Is this the case? Could someone please point me to the place in the IETF process where a draft document is considered normative before advancing? --brian On Tue, 04 Mar 2003, Internet-Drafts@ietf.org wrote: > 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 : Stream Control Transmission Protocol (SCTP) > Implementors Guide > Author(s) : R. Stewart, L. Ong et al. > Filename : draft-ietf-tsvwg-sctpimpguide-08.txt > Pages : 64 > Date : 2003-3-3 > > This document contains a compilation of all defects found up until > the publishing of this document for the Stream Control Transmission > Protocol (SCTP) RFC2960 [3]. These defects may be of an editorial or > technical nature. This document may be thought of as a companion > document to be used in the implementation of SCTP to clarify errors > in the original SCTP document. > This document updates RFC2960 [3] and text within this document > supersedes the text found in RFC2960 [3]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-08.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > 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-sctpimpguide-08.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-sctpimpguide-08.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. -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 10 04:53:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05573 for ; Mon, 10 Mar 2003 04:53:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AA5xE29047 for tsvwg-archive@odin.ietf.org; Mon, 10 Mar 2003 05:05:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AA5NO29035; Mon, 10 Mar 2003 05:05:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AA4jO28988 for ; Mon, 10 Mar 2003 05:04:45 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05261 for ; Mon, 10 Mar 2003 04:51:18 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2A9rOwv029492; Mon, 10 Mar 2003 10:53:25 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVN27MJ; Mon, 10 Mar 2003 10:53:23 +0100 Received: from res0010384da36.eed.ericsson.se (dhcp5-197 [164.48.135.197]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id KAA15425; Mon, 10 Mar 2003 10:53:20 +0100 (MET) Message-Id: <5.1.0.14.0.20030310061531.028edbd0@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 10 Mar 2003 10:53:16 +0100 To: tsvwg@ietf.org From: Reiner Ludwig Cc: end2end-interest@postel.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Tsvwg] Dealing with Spurious Retransmits in TCP Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , [I have cc:ed end2end-interest@postel.org, but please reply only to tsvwg@ietf.org to avoid double postings.] What about the following rule for those TCPs that are enhanced to detect spurious retransmits? Those TCPs MUST reduce their cwnd by MSS (alternatively by the amount of spuriously retransmitted data) when a spurious retransmit has been detected. The logic would be to say that since the TCP sender has used more than its fair share of bandwidth in the past (due to the spurious retransmit), it has to pay back for that once the spurious retransmit has been detected. With that rule, the policies for adapting RTO and DUPTHRESH would become less crucial. Moreover, a TCP sender for interactive applications (assuming that this implies that response time is more important than throughput) may then have the freedom to use a non-standard retransmission timer (more optimistic; not to say more aggressive), and Early Retransmit without concerns. Taking this a step further, one could argue that as long as the TCP sender uses no more than its fair share of bandwidth, it is free to send what it wants. For example, everytime an acceptable ACK arrives, and the TCP sender does not have new data available, it may retransmit from the queue of unacked data. RTP/UDP-based streams are also allowed to add redundancy in the form of FEC and retransmissions when the source rate is lower than the available bandwidth, or to trade some of their throughput and responsiveness for an increased reliability. So, couldn't TCP also trade unused throughput for an increased responsiveness by adding redundancy in the form of sending potentially spurious retransmits? ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 10 06:29:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23234 for ; Mon, 10 Mar 2003 06:29:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ABg9j04072 for tsvwg-archive@odin.ietf.org; Mon, 10 Mar 2003 06:42:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ABfIO04035; Mon, 10 Mar 2003 06:41:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ABelO04008 for ; Mon, 10 Mar 2003 06:40:47 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22900 for ; Mon, 10 Mar 2003 06:27:18 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2ABSs0E001192; Mon, 10 Mar 2003 03:28:54 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEH32326; Mon, 10 Mar 2003 03:28:52 -0800 (PST) Message-ID: <3E6C76F4.4050003@cisco.com> Date: Mon, 10 Mar 2003 05:28:52 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: tsvwg@ietf.org, sctp-impl@external.cisco.com Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-08.txt References: <200303041230.HAA15062@ietf.org> <20030309221449.A1547@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brian: I stated to you (I think this is who you refer to) that our intention is to make it normative whenever it gets incorporated into a new RFC... You should know that all drafts are not normative until they finish the IETF process. Our discussion was in particular about text that you objected to.. my interpretation of your query was that you thought the text could never be normative... and I just don't think that is true.. since our intentions are to close the I-G soon... R Brian F. G. Bidulock wrote: >I have been told by an author of this document that this document is normative. > >Is this the case? > >Could someone please point me to the place in the IETF process >where a draft document is considered normative before advancing? > >--brian > > >On Tue, 04 Mar 2003, Internet-Drafts@ietf.org wrote: > > > >>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 : Stream Control Transmission Protocol (SCTP) >> Implementors Guide >> Author(s) : R. Stewart, L. Ong et al. >> Filename : draft-ietf-tsvwg-sctpimpguide-08.txt >> Pages : 64 >> Date : 2003-3-3 >> >>This document contains a compilation of all defects found up until >>the publishing of this document for the Stream Control Transmission >>Protocol (SCTP) RFC2960 [3]. These defects may be of an editorial or >>technical nature. This document may be thought of as a companion >>document to be used in the implementation of SCTP to clarify errors >>in the original SCTP document. >>This document updates RFC2960 [3] and text within this document >>supersedes the text found in RFC2960 [3]. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-08.txt >> >>To remove yourself from the IETF Announcement list, send a message to >>ietf-announce-request with the word unsubscribe in the body of the message. >> >>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-sctpimpguide-08.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-sctpimpguide-08.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. >> >> > > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 10 08:44:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18347 for ; Mon, 10 Mar 2003 08:44:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ADvoe12118 for tsvwg-archive@odin.ietf.org; Mon, 10 Mar 2003 08:57:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ADvKO12103; Mon, 10 Mar 2003 08:57:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ADuTO12068 for ; Mon, 10 Mar 2003 08:56:29 -0500 Received: from smtp.dave.sonera.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17997 for ; Mon, 10 Mar 2003 08:42:58 -0500 (EST) Received: from gurtoan1-nb2.etela.sonera.fi ([131.177.37.47]:1748 "HELO gurtoannb2") by inside.dave.sonera.fi with SMTP id ; Mon, 10 Mar 2003 15:45:05 +0200 Message-ID: <029e01c2e70b$30df43f0$2f25b183@gurtoannb2> From: "Andrei Gurtov" To: References: <1046969951.24711.78.camel@atcp01.americas.nokia.com> Subject: Re: [Tsvwg] Test environments for congestion response Date: Mon, 10 Mar 2003 15:44:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1123 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Yogesh Prem Swami wrote: > I agree. What is needed is a realistic scenario which can mimic the > network behaviour in a certain way. I am appalled by results which show > 300% improvent in TCP performance, but of course the authors were using > loopback addresses for testing their improved schemes. [Just > exaggerating ...] The scenario we've used in the INFOCOM'03 paper is targeted at a specific environment, namely UMTS-kind of cellular links. Such links have dedicated per-user buffers and are not likely to have many concurrent TCP or real-time flows. Because of the page limit on the paper we have included only the most important scenarios: uncongested (a single TCP flow) and congested (TCP+CBR). However, I agree that it is useful to explore other traffic mix and I'll provide results later on. Still, if we assume that our paper demonstrates the best scenario for Eifel (+300% throughput) and your DCLOR the worst (-10% throughput), I would vote for deploying Eifel. Actuallly, since the difference between all schemes, including the standard TCP, in your tests is below 10%, the scenario does not look interesting to me at all. Furthermore, your tests are impossible to verify as the tools you've used are not publicly available. In the INFOCOM'03 paper we argue why congestion control should be undone after a spurious timeout. If not, ACKs are ignored after a spurious timeout which is a poor idea because it drops the thoughput up to ten times and at the same time *decreases* goodput as more timeouts and hence retransmissions occur. We've also made some measurement of TCP&TFRC over vertical handovers ("subnet changes" in your terms) with significant variation of link characteristics. http://www.cs.helsinki.fi/u/gurtov/papers/vho.html Andrei _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 10 09:32:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26060 for ; Mon, 10 Mar 2003 09:32:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AEj5u15760 for tsvwg-archive@odin.ietf.org; Mon, 10 Mar 2003 09:45:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AEiOO15722; Mon, 10 Mar 2003 09:44:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AEhMO15663 for ; Mon, 10 Mar 2003 09:43:22 -0500 Received: from seraph3.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25942 for ; Mon, 10 Mar 2003 09:29:52 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id EC30D6BA12 for ; Mon, 10 Mar 2003 09:31:58 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h2AEVw7h003422; Mon, 10 Mar 2003 09:31:58 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id JAA73466; Mon, 10 Mar 2003 09:31:58 -0500 (EST) Message-Id: <200303101431.JAA73466@guns.lerc.nasa.gov> To: Reiner Ludwig From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] Dealing with Spurious Retransmits in TCP In-Reply-To: <5.1.0.14.0.20030310061531.028edbd0@mailhost.eed.ericsson.se> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Mexicali Blues Date: Mon, 10 Mar 2003 09:31:58 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > Taking this a step further, one could argue that as long as the > TCP sender uses no more than its fair share of bandwidth, it is > free to send what it wants. > > [...] > > So, couldn't TCP also trade unused throughput for an increased > responsiveness by adding redundancy in the form of sending > potentially spurious retransmits? This seems somewhat dicey to me. We took some measurements a couple of years ago here that showed about 60% of the TCP connections (in and out) of NASA GRC contained only a single data packet. That might still hold or be a little different, but I doubt it's that far fetched today. So, using your notion from above and RFC3390 we could send the same packet 4 times -- which hopefully ensures that one of those packets arrives. Contrast that to sending the one packet and retransmitting as necessary. If you take a high loss rate of like 10% then one out of ten connections will need a retransmit (& so we'll send 11 data packets to deliver 10). In the case of sending redundant data sketched above we would send 40 packets to deliver 10. You can penalize folks a little bit for this bad behavior. But, that doesn't help the above case where a connection spins up and down so fast that no penalty is really meaningful. Now all of the above back-of-the-envelope conjecture might not be exactly right. But, the point is that using your notion could open the door to polluting the network with a whole bunch of data that potentially gets in the way without accomplishing any useful work. And, I wonder if there are cases where performance would actually decrease (when lots and lots of people are firing lots and lots of redundant data into the network to try to improve their performance). allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 10 10:00:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27219 for ; Mon, 10 Mar 2003 10:00:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AFDa017956 for tsvwg-archive@odin.ietf.org; Mon, 10 Mar 2003 10:13:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AFDFO17944; Mon, 10 Mar 2003 10:13:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AFC5O17906 for ; Mon, 10 Mar 2003 10:12:05 -0500 Received: from web10908.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27142 for ; Mon, 10 Mar 2003 09:58:33 -0500 (EST) Message-ID: <20030310150040.78392.qmail@web10908.mail.yahoo.com> Received: from [12.237.229.250] by web10908.mail.yahoo.com via HTTP; Mon, 10 Mar 2003 07:00:40 PST Date: Mon, 10 Mar 2003 07:00:40 -0800 (PST) From: Spencer Dawkins Subject: Re: [Tsvwg] Dealing with Spurious Retransmits in TCP To: tsvwg@ietf.org In-Reply-To: <200303101431.JAA73466@guns.lerc.nasa.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Mark and I have been having a private conversation on a related topic, so when I read --- Mark Allman wrote: > > We took some measurements a couple of years ago here that > showed > about 60% of the TCP connections (in and out) of NASA GRC > contained > only a single data packet. That might still hold or be a > little > different, but I doubt it's that far fetched today. So, using > your > notion from above and RFC3390 we could send the same packet 4 > times > -- which hopefully ensures that one of those packets arrives. > Contrast that to sending the one packet and retransmitting as > necessary. If you take a high loss rate of like 10% then one > out of > ten connections will need a retransmit (& so we'll send 11 > data > packets to deliver 10). In the case of sending redundant data > sketched above we would send 40 packets to deliver 10. and then, a little later on, > And, I wonder if there are cases where performance would > actually > decrease (when lots and lots of people are firing lots and > lots of > redundant data into the network to try to improve their > performance). > > allman I'm wondering why we're thinking abut TCP at all for these applications - or is it just too stupid to imagine another meaningful transport? Because in addition to the problem Mark is identifying, we also sent something like eight packets in order to send one packet with data. An aside - any clue what application we're talking about? I immediately started thinking about HTTP/1.0 and/or "Connection: close", but you should have seen at least one packet in each direction. Backing up slightly, I can imagine that if Mark was looking at HTTP/1.0 connections in his previous work, the percentage really is probably different today (with much wider HTTP/1.1 deployment and use), but how different is it? __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 10 11:10:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00852 for ; Mon, 10 Mar 2003 11:10:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AGNMd23102 for tsvwg-archive@odin.ietf.org; Mon, 10 Mar 2003 11:23:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGMhO23056; Mon, 10 Mar 2003 11:22:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGLwO22979 for ; Mon, 10 Mar 2003 11:21:58 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00811 for ; Mon, 10 Mar 2003 11:08:24 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AGDvF22889 for ; Mon, 10 Mar 2003 18:13:57 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 18:10:30 +0200 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 18:10:30 +0200 Subject: Re: [Tsvwg] Eifel-Response-03 From: Yogesh Prem Swami To: mallman@grc.nasa.gov Cc: "Armando L. Caro Jr." , Ethan Blanton , ext Reiner Ludwig , tsvwg@ietf.org In-Reply-To: <200303071944.OAA38558@guns.lerc.nasa.gov> References: <200303071944.OAA38558@guns.lerc.nasa.gov> Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1047312627.17940.25.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 10 Mar 2003 10:10:27 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2003 16:10:30.0178 (UTC) FILETIME=[92264820:01C2E71F] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Mark, [I am quite backlogged on this list; please bear with me] On Fri, 2003-03-07 at 13:44, ext Mark Allman wrote: > > The ACK clock is how you send new data into the > > network. Congestion response is about how you prevent unnecessary > > packet loss. These two are different issues. Ack clocking *can* be > > used to prevent congestion if these ACKs arrive in a regular > > fashion. If the ACKs don't arrive in a regular fashion, as in case > > of spurious timeout, they don't convey any information. > > I would phrase it "they may not convey any useful information". On Agreed, that's the right wording. But, the fact that a TCP sender will have the right information will only be a coincidence. One cannot design a congestion response based on coincidences. If that weren't the case then AIAD (.. additive decrease) would have been sufficient since in some sunny day scenarios we don't need AIMD. > the other hand, they will serve to prevent a complete line-rate > burst (e.g., send N packets as fast as you can) even in the worst > case. > Could you please justify your claim for the above scenario. What happens if all ACKs except the first and the last get lost into the network. Or, what happens if all the ACKs--instead of the data packets--were stalled on the first router connected to the sender. I think in the worst case the sender will still send data at the line rate. Besides, the comparison with line speed is not of relevance here. If someone had used line-rate that would have been worse, but that does not tell the sender that using the old data is correct. I never drive my car faster than a flying airplane, but does that guarantee that I will not get a speeding ticket. The speeding ticket in this case is posted by the routers on the e2e path, and the sender does not know anout these speed limits. After a spurious timeout, a TCP sender does not have any information about the state of the network. The only information it has is that the longer it waits, the lesser it can rely on the old data rate. In my opinion, an appropriate congestion response will take this into consideration. A congestion response must work in all the cases. Put differently, a congestoin response needs to be slow enough so that even in the worst case where the network is already congested, the response algorithm will not add a single bit to the existing level of congestion. > > I still think that a well defined test can help. Based on the > > simulations, we can decide the right thing to do. > > I bet that with the right simulation I could make either case. > That's the nice thing about simulations! :) > Not if everyone agrees that a particular scenario is the one that most resembles a real scenario. But I do agree it's a hard problem. What other options are there? One cannot analyze the problem mathematically; one cannot run simulation; so shall we have two experimental RFCs (I don't like this idea more than anyone else), but I'm running out of options here. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 10 11:30:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01868 for ; Mon, 10 Mar 2003 11:30:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AGhUO25257 for tsvwg-archive@odin.ietf.org; Mon, 10 Mar 2003 11:43:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGh6O25231; Mon, 10 Mar 2003 11:43:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGgsO25179 for ; Mon, 10 Mar 2003 11:42:54 -0500 Received: from localhost.localdomain (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01804 for ; Mon, 10 Mar 2003 11:29:20 -0500 (EST) Received: (from elb@localhost) by localhost.localdomain (8.11.6/8.11.6) id h2AGVKB27439; Mon, 10 Mar 2003 11:31:20 -0500 Date: Mon, 10 Mar 2003 11:31:20 -0500 From: Ethan Blanton To: Yogesh Prem Swami Cc: mallman@grc.nasa.gov, "Armando L. Caro Jr." , ext Reiner Ludwig , tsvwg@ietf.org Subject: Re: [Tsvwg] Eifel-Response-03 Message-ID: <20030310163120.GD30809@paco.resnet.purdue.edu> Mail-Followup-To: Yogesh Prem Swami , mallman@grc.nasa.gov, "Armando L. Caro Jr." , ext Reiner Ludwig , tsvwg@ietf.org References: <200303071944.OAA38558@guns.lerc.nasa.gov> <1047312627.17940.25.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1047312627.17940.25.camel@atcp01.americas.nokia.com> User-Agent: Mutt/1.4i X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Yogesh Prem Swami spake unto us the following wisdom: > > the other hand, they will serve to prevent a complete line-rate > > burst (e.g., send N packets as fast as you can) even in the worst > > case. > > > > Could you please justify your claim for the above scenario. What happens > if all ACKs except the first and the last get lost into the network. Or, > what happens if all the ACKs--instead of the data packets--were stalled > on the first router connected to the sender. > > I think in the worst case the sender will still send data at the line > rate. No. Because the algorithm sets ssthresh to the previous value of cwnd ... therefore cwnd can open up only as acks arrive, as in initial slow start. > After a spurious timeout, a TCP sender does not have any information > about the state of the network. The only information it has is that the > longer it waits, the lesser it can rely on the old data rate. In my > opinion, an appropriate congestion response will take this into > consideration. So, let me put this in perspective ... an RTO causes the connection to go into slow start, Reiner's draft causes the connection to go into slow start. > > I bet that with the right simulation I could make either case. > > That's the nice thing about simulations! :) > > Not if everyone agrees that a particular scenario is the one that most > resembles a real scenario. But I do agree it's a hard problem. Never going to happen. What sort of real scenario? That's just far too wide a question. > What other options are there? One cannot analyze the problem > mathematically; one cannot run simulation; so shall we have two > experimental RFCs (I don't like this idea more than anyone else), but > I'm running out of options here. If you mean an experimental RFC for Eifel and an experimental RFC for DCLOR, I think it's a fantastic solution. Ethan -- Happiness is a belt-fed weapon. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 10 11:48:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02562 for ; Mon, 10 Mar 2003 11:48:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AH1gl26544 for tsvwg-archive@odin.ietf.org; Mon, 10 Mar 2003 12:01:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AH1AO26493; Mon, 10 Mar 2003 12:01:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AH0VO26400 for ; Mon, 10 Mar 2003 12:00:31 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02473 for ; Mon, 10 Mar 2003 11:46:56 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AGqTF14979 for ; Mon, 10 Mar 2003 18:52:29 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 18:49:02 +0200 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 18:49:01 +0200 Subject: Re: [Tsvwg] Test environments for congestion response From: Yogesh Prem Swami To: ext Andrei Gurtov Cc: tsvwg@ietf.org In-Reply-To: <029e01c2e70b$30df43f0$2f25b183@gurtoannb2> References: <1046969951.24711.78.camel@atcp01.americas.nokia.com> <029e01c2e70b$30df43f0$2f25b183@gurtoannb2> Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1047314939.17940.64.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 10 Mar 2003 10:48:59 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2003 16:49:01.0569 (UTC) FILETIME=[F3D88F10:01C2E724] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Andrei, On Mon, 2003-03-10 at 07:44, ext Andrei Gurtov wrote: > Yogesh Prem Swami wrote: > > > I agree. What is needed is a realistic scenario which can mimic the > > network behaviour in a certain way. I am appalled by results which show > > 300% improvent in TCP performance, but of course the authors were using > > loopback addresses for testing their improved schemes. [Just > > exaggerating ...] > > The scenario we've used in the INFOCOM'03 paper is targeted at a specific > environment, namely UMTS-kind of cellular links. Such links have dedicated > per-user buffers and are not likely to have many concurrent TCP or real-time > flows. I don't know much about UMTS networks, but I am told that this is left to implementation. I will confirm this and comment later on ... > Because of the page limit on the paper we have included only the most > important scenarios: uncongested (a single TCP flow) and congested > (TCP+CBR). > However, I agree that it is useful to explore other traffic mix and I'll > provide results later on. > > Still, if we assume that our paper demonstrates the best scenario for Eifel > (+300% throughput) and your DCLOR the worst (-10% throughput), I would vote I was not talking about your paper in this example. The example I was giving was an exaggeration to emphasize the fact that results could be deceiving. (I explicitly remember making the point that it was an exaggeration. I apologize if I gave a different impression--it was not intentional) > for deploying Eifel. Actuallly, since the difference between all schemes, > including the standard TCP, in your tests is below 10%, the scenario does > not look interesting to me at all. Furthermore, your tests are impossible to > verify as the tools you've used are not publicly available. My tests were run on *real networks*, not on NS-2 simulator (I don't trust NS-2). DCLOR is implemented in Linux. I will make it publically available by tomorrow end of business. I also encourage you to run DCLOR in a real whatever network (UMTS/ wireless lan ...) if you have access to it. It won't give a -10% improvement even in the worst case. But please don't take my word for it, verify it for yourself. > > In the INFOCOM'03 paper we argue why congestion control should be undone > after a spurious timeout. If not, ACKs are ignored after a spurious timeout > which is a poor idea because it drops the thoughput up to ten times and at > the same time *decreases* goodput as more timeouts and hence retransmissions > occur. > That happens if you blindly reduce the data rate to half. A clever implementaion can handle it properly. > We've also made some measurement of TCP&TFRC over vertical handovers Please use "subnet change." Not everyone (read Yogesh) knows about fancy wireless network terminology. > ("subnet changes" in your terms) with significant variation of link > characteristics. http://www.cs.helsinki.fi/u/gurtov/papers/vho.html > Thanks. This certainly helps. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 10 11:55:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02776 for ; Mon, 10 Mar 2003 11:55:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AH8hd28169 for tsvwg-archive@odin.ietf.org; Mon, 10 Mar 2003 12:08:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AH85O28048; Mon, 10 Mar 2003 12:08:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AH2mO26680 for ; Mon, 10 Mar 2003 12:02:48 -0500 Received: from seraph3.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02595 for ; Mon, 10 Mar 2003 11:49:14 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id B6DDF6BA19 for ; Mon, 10 Mar 2003 11:51:21 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h2AGpK7h016939; Mon, 10 Mar 2003 11:51:20 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id LAA75907; Mon, 10 Mar 2003 11:51:20 -0500 (EST) Message-Id: <200303101651.LAA75907@guns.lerc.nasa.gov> To: Yogesh Prem Swami From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: "Armando L. Caro Jr." , Ethan Blanton , ext Reiner Ludwig , tsvwg@ietf.org Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <1047312627.17940.25.camel@atcp01.americas.nokia.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Mexicali Blues Date: Mon, 10 Mar 2003 11:51:20 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > > I would phrase it "they may not convey any useful information". On > > Agreed, that's the right wording. But, the fact that a TCP sender > will have the right information will only be a coincidence. Um. Not sure I would phrase it that way, but OK. > One cannot design a congestion response based on coincidences. OK. So, I agree that the worst case is a fairly substantial bursting behavior (whether it is line rate or slightly less or a lot less... point is we can burst in a fairly significant way). And, we should look at the worst case. > After a spurious timeout, a TCP sender does not have any > information about the state of the network. The only information > it has is that the longer it waits, the lesser it can rely on the > old data rate. In my opinion, an appropriate congestion response > will take this into consideration. I agree with the statement "the longer it waits, the less[er] it can rely on the old data rate". But, I do not agree with the first statement that says just because we RTO means that the previous CC state information is useless. And, so, while I am not convinced that Reiner's scheme of reverting the entire cwnd is right, I do not think that disallowing all reversion is right either. But, now I am just repeating... allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 10 11:55:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02789 for ; Mon, 10 Mar 2003 11:55:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AH8iJ28182 for tsvwg-archive@odin.ietf.org; Mon, 10 Mar 2003 12:08:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AH86O28067; Mon, 10 Mar 2003 12:08:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AH3xO26910 for ; Mon, 10 Mar 2003 12:03:59 -0500 Received: from seraph2.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02646 for ; Mon, 10 Mar 2003 11:50:25 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 327A0689CF for ; Mon, 10 Mar 2003 11:52:33 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h2AGqW7h017298; Mon, 10 Mar 2003 11:52:32 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id LAA75918; Mon, 10 Mar 2003 11:52:32 -0500 (EST) Message-Id: <200303101652.LAA75918@guns.lerc.nasa.gov> To: Ethan Blanton From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: Yogesh Prem Swami , "Armando L. Caro Jr." , ext Reiner Ludwig , tsvwg@ietf.org Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <20030310163120.GD30809@paco.resnet.purdue.edu> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Mexicali Blues Date: Mon, 10 Mar 2003 11:52:31 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > > What other options are there? One cannot analyze the problem > > mathematically; one cannot run simulation; so shall we have two > > experimental RFCs (I don't like this idea more than anyone > > else), but I'm running out of options here. > > If you mean an experimental RFC for Eifel and an experimental RFC > for DCLOR, I think it's a fantastic solution. Agreed. (modulo WG consensus on each independently, of course) allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 10 11:56:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02853 for ; Mon, 10 Mar 2003 11:56:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AH9hF28258 for tsvwg-archive@odin.ietf.org; Mon, 10 Mar 2003 12:09:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AH92O28219; Mon, 10 Mar 2003 12:09:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AH8fO28164 for ; Mon, 10 Mar 2003 12:08:41 -0500 Received: from seraph2.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02730 for ; Mon, 10 Mar 2003 11:55:07 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id D63DF689B1 for ; Mon, 10 Mar 2003 11:57:14 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h2AGvD7h018669; Mon, 10 Mar 2003 11:57:14 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id LAA76016; Mon, 10 Mar 2003 11:57:13 -0500 (EST) Message-Id: <200303101657.LAA76016@guns.lerc.nasa.gov> To: Ethan Blanton From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: Yogesh Prem Swami , "Armando L. Caro Jr." , ext Reiner Ludwig , tsvwg@ietf.org Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <20030310163120.GD30809@paco.resnet.purdue.edu> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Mexicali Blues Date: Mon, 10 Mar 2003 11:57:13 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > So, let me put this in perspective ... an RTO causes the > connection to go into slow start, Reiner's draft causes the > connection to go into slow start. Right. The difference is in the length of this slow start (from cwnd_prev/2 (std case) to cwnd_prev (when allowing state reversion)) (and hence the length of the potentially bursty behavior). allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 10 12:02:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03110 for ; Mon, 10 Mar 2003 12:02:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AHFiK28640 for tsvwg-archive@odin.ietf.org; Mon, 10 Mar 2003 12:15:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHFJO28622; Mon, 10 Mar 2003 12:15:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHAsO28368 for ; Mon, 10 Mar 2003 12:10:55 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02877 for ; Mon, 10 Mar 2003 11:57:20 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2AH2rF21507 for ; Mon, 10 Mar 2003 19:02:53 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Mar 2003 18:59:26 +0200 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Mar 2003 18:59:26 +0200 Subject: Re: [Tsvwg] Eifel-Response-03 From: Yogesh Prem Swami To: mallman@grc.nasa.gov Cc: Ethan Blanton , "Armando L. Caro Jr." , ext Reiner Ludwig , tsvwg@ietf.org In-Reply-To: <200303101652.LAA75918@guns.lerc.nasa.gov> References: <200303101652.LAA75918@guns.lerc.nasa.gov> Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1047315563.17940.75.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 10 Mar 2003 10:59:23 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2003 16:59:26.0531 (UTC) FILETIME=[685A3130:01C2E726] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mon, 2003-03-10 at 10:52, ext Mark Allman wrote: > > > What other options are there? One cannot analyze the problem > > > mathematically; one cannot run simulation; so shall we have two > > > experimental RFCs (I don't like this idea more than anyone > > > else), but I'm running out of options here. > > > > If you mean an experimental RFC for Eifel and an experimental RFC > > for DCLOR, I think it's a fantastic solution. > > Agreed. > (modulo WG consensus on each independently, of course) Agreed. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 10 16:36:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15431 for ; Mon, 10 Mar 2003 16:36:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ALnYA21750 for tsvwg-archive@odin.ietf.org; Mon, 10 Mar 2003 16:49:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ALmOO21711; Mon, 10 Mar 2003 16:48:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ALkCO21600 for ; Mon, 10 Mar 2003 16:46:13 -0500 Received: from gw.openss7.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15294 for ; Mon, 10 Mar 2003 16:32:32 -0500 (EST) Received: from ns.pigworks.openss7.net (IDENT:/SUxwkoR7CuG9kpp1CjxTC4HMfHOzJPI@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h2ALRsD20687; Mon, 10 Mar 2003 14:27:54 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h2ALRsA21280; Mon, 10 Mar 2003 14:27:54 -0700 Date: Mon, 10 Mar 2003 14:27:54 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: tsvwg@ietf.org, sctp-impl@external.cisco.com Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-08.txt Message-ID: <20030310142754.A20295@openss7.org> Reply-To: bidulock@openss7.org References: <200303041230.HAA15062@ietf.org> <20030309221449.A1547@openss7.org> <3E6C76F4.4050003@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E6C76F4.4050003@cisco.com>; from rrs@cisco.com on Mon, Mar 10, 2003 at 05:28:52AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Randall, When I said that the IG is not normative, I meant the current draft. It is my understanding that an implementation is not compelled to follow a draft document. Is that correct? --brian On Mon, 10 Mar 2003, Randall Stewart (cisco) wrote: > Brian: > > I stated to you (I think this is who you refer to) that our intention > is to make it normative whenever it gets incorporated into > a new RFC... You should know that all drafts are not normative > until they finish the IETF process. > > Our discussion was in particular about text that you objected to.. > my interpretation of your query was that you thought the text > could never be normative... and I just don't think that is true.. since > our intentions are to close the I-G soon... > > R > > Brian F. G. Bidulock wrote: > > >I have been told by an author of this document that this document is normative. > > > >Is this the case? > > > >Could someone please point me to the place in the IETF process > >where a draft document is considered normative before advancing? > > > >--brian > > > > > >On Tue, 04 Mar 2003, Internet-Drafts@ietf.org wrote: > > > > > > > >>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 : Stream Control Transmission Protocol (SCTP) > >> Implementors Guide > >> Author(s) : R. Stewart, L. Ong et al. > >> Filename : draft-ietf-tsvwg-sctpimpguide-08.txt > >> Pages : 64 > >> Date : 2003-3-3 > >> > >>This document contains a compilation of all defects found up until > >>the publishing of this document for the Stream Control Transmission > >>Protocol (SCTP) RFC2960 [3]. These defects may be of an editorial or > >>technical nature. This document may be thought of as a companion > >>document to be used in the implementation of SCTP to clarify errors > >>in the original SCTP document. > >>This document updates RFC2960 [3] and text within this document > >>supersedes the text found in RFC2960 [3]. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-08.txt > >> > >>To remove yourself from the IETF Announcement list, send a message to > >>ietf-announce-request with the word unsubscribe in the body of the message. > >> > >>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-sctpimpguide-08.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-sctpimpguide-08.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. > >> > >> > > > > > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 11 05:30:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15047 for ; Tue, 11 Mar 2003 05:30:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BAhbP18979 for tsvwg-archive@odin.ietf.org; Tue, 11 Mar 2003 05:43:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BAgnO18947; Tue, 11 Mar 2003 05:42:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BAfbO18906 for ; Tue, 11 Mar 2003 05:41:37 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15004 for ; Tue, 11 Mar 2003 05:27:41 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BATlwv000174; Tue, 11 Mar 2003 11:29:47 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4KG5KG; Tue, 11 Mar 2003 11:29:46 +0100 Received: from res0010384da36.eed.ericsson.se (rac183pc.edd.ericsson.se [164.48.123.183]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id LAA11978; Tue, 11 Mar 2003 11:29:43 +0100 (MET) Message-Id: <5.1.0.14.0.20030311104535.028037f8@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Mar 2003 11:25:48 +0100 To: mallman@grc.nasa.gov From: Reiner Ludwig Subject: Re: [Tsvwg] Dealing with Spurious Retransmits in TCP Cc: tsvwg@ietf.org In-Reply-To: <200303101431.JAA73466@guns.lerc.nasa.gov> References: <5.1.0.14.0.20030310061531.028edbd0@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Hi Mark, what you describe is not quite what I meant. Let me try again ... I'm suggesting that as long as the TCP sender preserves 'packet conservation' *and* uses the 'ACK clock' to clock out transmissions, it should be the TCP sender's decision of what it sends. In particular, this means that also the mentioned Potentially Spurious Retransmits (PSRs) may only be clocked out by returning ACKs. That should take care of one of your concern: "And, I wonder if there are cases where performance would actually decrease (when lots and lots of people are firing lots and lots of redundant data into the network to try to improve their performance)." I.e., if the TCP sender has only 500 bytes to send and uses RFC3390, it should *not* be allowed to send 4 back-to-back copies of the same segment; only one segment since PSRs may only be clocked out by returning ACKs. Still, I would like to revise the rule I suggested: Those TCPs MUST reduce their cwnd by MSS (alternatively by the amount of spuriously retransmitted data) when a spurious *timeout* has been detected. This is, because only in the case of a spurious timeout has the TCP sender used more than its fair share of bandwidth in the past (due to the spurious retransmit). In the case of a spurious fast retransmit, the TCP sender has actually *not* violated 'packet conservation' in the past. Coming back to your point using an example that should be equivalent to the example you gave (short lived TCP connections). Let's assume MSS = 500 bytes and the TCP sender has 2000 bytes to send. Per RFC3390, it can send the 4 segments in the first RTT back-to-back. With the approach I suggested, the ACK for segment 1 would clock out a PSR of segment 2, the ACK for segment 2 would clock out a PSR of segment 3, etc. Assuming the TCP sender didn't get any loss/congestion indication, it would end up sending 7 segments (3500 bytes) instead of only 4 segments (2000 bytes). So what? The TCP sender didn't use more than its fair share of bandwidth. I'm not totally familiar with all the stream encodings that are being defined for RTP, but I wouldn't be surprised at all if some of those codecs added FEC with a ratio of 3500/2000. And for RTP streams we are saying: "as long as the entire RTP stream behaves TCP-friendly, we are fine." Something is not right here. We are being more strict to TCP than to the non-TCPs. That's not TCP-friendly! ;-) Maybe, I'm missing something essential here ... but my current view is that the approach I suggested should at least be OK as an option that the application could set (or the user if it has to pay per byte for her/his access link). ///Reiner At 15:31 10.03.2003, Mark Allman wrote: > > Taking this a step further, one could argue that as long as the > > TCP sender uses no more than its fair share of bandwidth, it is > > free to send what it wants. > > > > [...] > > > > So, couldn't TCP also trade unused throughput for an increased > > responsiveness by adding redundancy in the form of sending > > potentially spurious retransmits? > >This seems somewhat dicey to me. > >We took some measurements a couple of years ago here that showed >about 60% of the TCP connections (in and out) of NASA GRC contained >only a single data packet. That might still hold or be a little >different, but I doubt it's that far fetched today. So, using your >notion from above and RFC3390 we could send the same packet 4 times >-- which hopefully ensures that one of those packets arrives. >Contrast that to sending the one packet and retransmitting as >necessary. If you take a high loss rate of like 10% then one out of >ten connections will need a retransmit (& so we'll send 11 data >packets to deliver 10). In the case of sending redundant data >sketched above we would send 40 packets to deliver 10. > >You can penalize folks a little bit for this bad behavior. But, >that doesn't help the above case where a connection spins up and >down so fast that no penalty is really meaningful. > >Now all of the above back-of-the-envelope conjecture might not be >exactly right. But, the point is that using your notion could open >the door to polluting the network with a whole bunch of data that >potentially gets in the way without accomplishing any useful work. >And, I wonder if there are cases where performance would actually >decrease (when lots and lots of people are firing lots and lots of >redundant data into the network to try to improve their >performance). > >allman > > >-- >Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 11 05:32:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15112 for ; Tue, 11 Mar 2003 05:32:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BAk5b19104 for tsvwg-archive@odin.ietf.org; Tue, 11 Mar 2003 05:46:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BAhCO18967; Tue, 11 Mar 2003 05:43:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BAfdO18911 for ; Tue, 11 Mar 2003 05:41:39 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15007 for ; Tue, 11 Mar 2003 05:27:44 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BATiwv000157; Tue, 11 Mar 2003 11:29:44 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id GPHJPARQ; Tue, 11 Mar 2003 11:29:44 +0100 Received: from res0010384da36.eed.ericsson.se (rac183pc.edd.ericsson.se [164.48.123.183]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id LAA11969; Tue, 11 Mar 2003 11:29:39 +0100 (MET) Message-Id: <5.1.0.14.0.20030311102516.027ca6e0@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Mar 2003 10:45:23 +0100 To: mallman@grc.nasa.gov From: Reiner Ludwig Subject: Re: [Tsvwg] Eifel-Response-03 Cc: tsvwg@ietf.org In-Reply-To: <200303101657.LAA76016@guns.lerc.nasa.gov> References: <20030310163120.GD30809@paco.resnet.purdue.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 17:57 10.03.2003, Mark Allman wrote: > > So, let me put this in perspective ... an RTO causes the > > connection to go into slow start, Reiner's draft causes the > > connection to go into slow start. > >Right. The difference is in the length of this slow start (from >cwnd_prev/2 (std case) to cwnd_prev (when allowing state reversion)) >(and hence the length of the potentially bursty behavior). Just to make it precise. After a spurious timeout the Eifel response will make the TCP sender either resume transmission in congestion avoidance if it had been in congestion avoidance before the timeout, or in slow start if it had been in slow start before the timeout. From the draft: "We suggest to restore cwnd to the minimum of the previous FlightSize, and the current FlightSize plus IW. [...] In addition, we suggest to restore ssthresh to pipe_prev, i.e., the maximum of the previous value of ssthresh and the value that FlightSize had when loss recovery was unnecessarily entered. As a result, the TCP sender either immediately resumes probing the network for more bandwidth in congestion avoidance, or it first slow starts until it has reached its previous share of the available bandwidth." But, yes, Mark is right in what he says about the "difference in the length of the slow start" for the case where the TCP sender had been in slow start before the timeout. The motivation for our choice are scenarios of high BxD connections and a spurious timeout early in the initial slow start. Note, that such spurious timeout is at least not unlikely since in the beginning of a connection, SRTT and RTTVAR have not yet converged to "good" values (unless they had been initialized from previous or concurrent connections). In the standard case, ssthresh is "clamped" at a low value. As a result the TCP sender is forced to climb up to BxD in congestion avoidance. With the Eifel response, ssthresh is restored to its previous value (likely its initialization value). As a result the TCP sender can resume slow starting to ssthresh which ideally is higher than BxD. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 11 07:30:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17391 for ; Tue, 11 Mar 2003 07:30:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BCiIw26329 for tsvwg-archive@odin.ietf.org; Tue, 11 Mar 2003 07:44:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BChPO26242; Tue, 11 Mar 2003 07:43:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGr6O25946 for ; Mon, 10 Mar 2003 11:53:06 -0500 Received: from uni10mr.unity.ncsu.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02242 for ; Mon, 10 Mar 2003 11:39:31 -0500 (EST) Received: from HD (soyun.csc.ncsu.edu [152.14.53.157]) by uni10mr.unity.ncsu.edu (8.11.6/8.11.6/N.20030204.02) with ESMTP id h2AGfXD27043; Mon, 10 Mar 2003 11:41:33 -0500 (EST) From: "Injong Rhee" To: "'Reiner Ludwig'" , Cc: Date: Mon, 10 Mar 2003 11:40:56 -0500 Message-ID: <000001c2e723$d2b11f10$9d350e98@HD> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <5.1.0.14.0.20030310061531.028edbd0@mailhost.eed.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] RE: [e2e] Dealing with Spurious Retransmits in TCP Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree with Reiner. The main problem lies in unnecessary coupling of recovery and congestion control in TCP. I view CC is an independent from recovery. Whether it can transmit spurious retransmission or simply do no-op, it should left to the application or other layer decision. Therefore, CC must tell the current rate (or window size) that the data (including retransmission) must be sent at and the recovery layer decides on whether it should retransmit, forward-error correction or other data packets. Injong Rhee Computer Science Dept North Carolina State Univ. rhee@csc.ncsu.edu http://www.csc.ncsu.edu/faculty/rhee -----Original Message----- From: end2end-interest-admin@postel.org [mailto:end2end-interest-admin@postel.org] On Behalf Of Reiner Ludwig Sent: Monday, March 10, 2003 4:53 AM To: tsvwg@ietf.org Cc: end2end-interest@postel.org Subject: [e2e] Dealing with Spurious Retransmits in TCP [I have cc:ed end2end-interest@postel.org, but please reply only to tsvwg@ietf.org to avoid double postings.] What about the following rule for those TCPs that are enhanced to detect spurious retransmits? Those TCPs MUST reduce their cwnd by MSS (alternatively by the amount of spuriously retransmitted data) when a spurious retransmit has been detected. The logic would be to say that since the TCP sender has used more than its fair share of bandwidth in the past (due to the spurious retransmit), it has to pay back for that once the spurious retransmit has been detected. With that rule, the policies for adapting RTO and DUPTHRESH would become less crucial. Moreover, a TCP sender for interactive applications (assuming that this implies that response time is more important than throughput) may then have the freedom to use a non-standard retransmission timer (more optimistic; not to say more aggressive), and Early Retransmit without concerns. Taking this a step further, one could argue that as long as the TCP sender uses no more than its fair share of bandwidth, it is free to send what it wants. For example, everytime an acceptable ACK arrives, and the TCP sender does not have new data available, it may retransmit from the queue of unacked data. RTP/UDP-based streams are also allowed to add redundancy in the form of FEC and retransmissions when the source rate is lower than the available bandwidth, or to trade some of their throughput and responsiveness for an increased reliability. So, couldn't TCP also trade unused throughput for an increased responsiveness by adding redundancy in the form of sending potentially spurious retransmits? ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 11 07:30:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17405 for ; Tue, 11 Mar 2003 07:30:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BCiLG26343 for tsvwg-archive@odin.ietf.org; Tue, 11 Mar 2003 07:44:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BChXO26258; Tue, 11 Mar 2003 07:43:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHWiO30306 for ; Mon, 10 Mar 2003 12:32:44 -0500 Received: from cs.bu.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04195 for ; Mon, 10 Mar 2003 12:19:09 -0500 (EST) Received: from cs.bu.edu (matta@memphis [128.197.10.43]) (authenticated bits=0) by cs.bu.edu (8.12.2/8.12.2) with ESMTP id h2AHLDKh026206; Mon, 10 Mar 2003 12:21:13 -0500 (EST) Message-ID: <3E6CC989.A2AA7E95@cs.bu.edu> Date: Mon, 10 Mar 2003 12:21:13 -0500 From: Ibrahim Matta Organization: Boston University, Computer Science Department X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Injong Rhee CC: "'Reiner Ludwig'" , tsvwg@ietf.org, end2end-interest@postel.org References: <000001c2e723$d2b11f10$9d350e98@HD> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Re: [e2e] Dealing with Spurious Retransmits in TCP Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Yes, this is the *well-known* problem of coupling between error control and congestion control in window-based schemes. Rate-based schemes naturally decouple the two - see Keshav's textbook for example. ibrahim Injong Rhee wrote: > > I agree with Reiner. The main problem lies in unnecessary coupling of > recovery and congestion control in TCP. I view CC is an independent from > recovery. Whether it can transmit spurious retransmission or simply do > no-op, it should left to the application or other layer decision. > Therefore, CC must tell the current rate (or window size) that the data > (including retransmission) must be sent at and the recovery layer > decides on whether it should retransmit, forward-error correction or > other data packets. > > Injong Rhee > Computer Science Dept > North Carolina State Univ. > rhee@csc.ncsu.edu > http://www.csc.ncsu.edu/faculty/rhee > > -----Original Message----- > From: end2end-interest-admin@postel.org > [mailto:end2end-interest-admin@postel.org] On Behalf Of Reiner Ludwig > Sent: Monday, March 10, 2003 4:53 AM > To: tsvwg@ietf.org > Cc: end2end-interest@postel.org > Subject: [e2e] Dealing with Spurious Retransmits in TCP > > [I have cc:ed end2end-interest@postel.org, but please reply only to > tsvwg@ietf.org to avoid double postings.] > > What about the following rule for those TCPs that are enhanced to detect > > spurious retransmits? > > Those TCPs MUST reduce their cwnd by MSS (alternatively by the > amount > of spuriously retransmitted data) when a spurious retransmit has > been > detected. > > The logic would be to say that since the TCP sender has used more than > its > fair share of bandwidth in the past (due to the spurious retransmit), it > > has to pay back for that once the spurious retransmit has been detected. > > With that rule, the policies for adapting RTO and DUPTHRESH would become > > less crucial. > > Moreover, a TCP sender for interactive applications (assuming that this > implies that response time is more important than throughput) may then > have > the freedom to use a non-standard retransmission timer (more optimistic; > > not to say more aggressive), and Early Retransmit without concerns. > > Taking this a step further, one could argue that as long as the TCP > sender > uses no more than its fair share of bandwidth, it is free to send what > it > wants. For example, everytime an acceptable ACK arrives, and the TCP > sender > does not have new data available, it may retransmit from the queue of > unacked data. > RTP/UDP-based streams are also allowed to add redundancy in the form of > FEC > and retransmissions when the source rate is lower than the available > bandwidth, or to trade some of their throughput and responsiveness for > an > increased reliability. > So, couldn't TCP also trade unused throughput for an increased > responsiveness by adding redundancy in the form of sending potentially > spurious retransmits? > > ///Reiner -- Ibrahim Matta Dept of Comp Sci, 111 Cummington St, MCS-271 matta@cs.bu.edu Assistant Prof, Boston Univ., Boston, MA 02215 Tel: (617)358-1062, Fax: (617)353-6457, URL: www.cs.bu.edu/fac/matta/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 11 13:02:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29832 for ; Tue, 11 Mar 2003 13:02:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BIFrb18740 for tsvwg-archive@odin.ietf.org; Tue, 11 Mar 2003 13:15:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BIFZO18727; Tue, 11 Mar 2003 13:15:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BIEbO18679 for ; Tue, 11 Mar 2003 13:14:37 -0500 Received: from seraph2.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29802 for ; Tue, 11 Mar 2003 13:00:31 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 4DFF4689D3 for ; Tue, 11 Mar 2003 13:02:40 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h2BI2d7h013457; Tue, 11 Mar 2003 13:02:39 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id NAA00721; Tue, 11 Mar 2003 13:02:39 -0500 (EST) Message-Id: <200303111802.NAA00721@guns.lerc.nasa.gov> To: Reiner Ludwig From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] Dealing with Spurious Retransmits in TCP In-Reply-To: <5.1.0.14.0.20030311104535.028037f8@mailhost.eed.ericsson.se> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Money Date: Tue, 11 Mar 2003 13:02:39 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > what you describe is not quite what I meant. Let me try again ... OK. But, you constructed one case where we can still send a bunch of redundant segments into the network without indication that they were lost -- and, even given the rules you sketch I can come up with other cases, I think. > Coming back to your point using an example that should be > equivalent to the example you gave (short lived TCP > connections). Let's assume MSS = 500 bytes and the TCP sender has > 2000 bytes to send. Per RFC3390, it can send the 4 segments in the > first RTT back-to-back. With the approach I suggested, the ACK for > segment 1 would clock out a PSR of segment 2, the ACK for segment > 2 would clock out a PSR of segment 3, etc. > > Assuming the TCP sender didn't get any loss/congestion indication, > it would end up sending 7 segments (3500 bytes) instead of only 4 > segments (2000 bytes). So what? The TCP sender didn't use more > than its fair share of bandwidth. Two things jump to mind... * Sure, you are sending at your "fair share" rate-wise. But, if we take a wider view we're sending extra stuff which uses network resources and we are essentially spinning our wheels. While this practice might help our connection (sometimes) it also uses resources that other connections could use to accomplish useful work (which we are not in most cases). * The reason you would need to send such retransmits would be because they were lost because the network is congested (using the standard TCP assumption). So, what is the justification here? "Just in case we're congested I'll throw some extra data into the network." Seems like throwing gas on the fire to me. > I'm not totally familiar with all the stream encodings that are > being defined for RTP, but I wouldn't be surprised at all if some > of those codecs added FEC with a ratio of 3500/2000. And for RTP > streams we are saying: "as long as the entire RTP stream behaves > TCP-friendly, we are fine." > > Something is not right here. We are being more strict to TCP than > to the non-TCPs. That's not TCP-friendly! ;-) I will likewise plead ignorance here. But, I think one difference is that the RTP stuff is not reliable and so FEC is the only way to protect the bits. That is just conjecture. And, FEC that blows up the size of the data by a factor of ~2 (which I think is the upper bound of extra stuff you could dump into the network given the scheme you sketched) seems pretty egregious to me (just from thinking about the sorts of things folk around here talk about for satellite channels). (Although, that might be quite different from what gets applied in application-land.) Maybe someone more informed could clue us both in! allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 11 15:38:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11198 for ; Tue, 11 Mar 2003 15:38:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BKpfp30936 for tsvwg-archive@odin.ietf.org; Tue, 11 Mar 2003 15:51:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BKpCO30902; Tue, 11 Mar 2003 15:51:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BKmEO30763 for ; Tue, 11 Mar 2003 15:48:14 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11103 for ; Tue, 11 Mar 2003 15:34:06 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BKaBwv001665; Tue, 11 Mar 2003 21:36:11 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVNXGBT; Tue, 11 Mar 2003 21:36:10 +0100 Received: from res0010384da36.eed.ericsson.se (rac183pc.edd.ericsson.se [164.48.123.183]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id VAA14865; Tue, 11 Mar 2003 21:36:07 +0100 (MET) Message-Id: <5.1.0.14.0.20030311204434.00aaaee8@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Mar 2003 21:34:01 +0100 To: mallman@grc.nasa.gov From: Reiner Ludwig Subject: Re: [Tsvwg] Dealing with Spurious Retransmits in TCP Cc: tsvwg@ietf.org In-Reply-To: <200303111802.NAA00721@guns.lerc.nasa.gov> References: <5.1.0.14.0.20030311104535.028037f8@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , I know, this PSR (sending Potentially Spurious Retransmit without any clue of a loss indication) option for TCP is probably the extreme case of maximum redundancy. And I see your points why this might not be so popular. Independent of whether that would ever fly, I feel (and that's the point I want to make) that we are way too strict to TCP; at least much stricter than we are with RTP/UDP-based streams. And that's not fair ;-( The amount of useful data sent by the current TCP should be pretty close to 100 percent. The amount of useful data sent by some RTP/UDPs (even if they are TCP-friendly) should for certain content encodings be << 100 percent. So, I think we should relax a little when it comes to proposals like Early Retransmit, and also allow TCP a bit more redundancy (within the bounds of packet conservation and the TCP congestion control principles). Loping back to the Eifel response and alternative schemes, I think that ... - a spurious timeout is harmful This is because the resulting spurious retransmit breaks packet conservation. One way to address this is to REQUIRE the rule I suggested earlier for those TCPs that are enhanced to detect spurious timeouts: Those TCPs MUST reduce their cwnd by MSS (alternatively by the amount of spuriously retransmitted data) when a spurious timeout has been detected. However, for those TCPs that followed that rule, the retransmission timer becomes less crucial. Those TCPs should be free to use whatever retransmission timer the implementers choose to use. They MAY use RFC2988, but there should be no more IETF restriction that they MUST use RFC2988 or any successor. Likewise, (if that rule is used) the resonsibility of how the retransmission timer is adapted in response to a detected spurious timeout should lie entirely with the implementor, i.e., the TSVWG should at most suggest what an implementor MAY do to adapt the retransmission timer. - a spurious fast retransmit is *not* harmful This is because the resulting spurious retransmit does *not* break packet conservation. Following the same line of argument as above, I would say that the resonsibility of how DUPTHRESH is set initially or how it is adapted in response to a detected spurious fast retransmit should lie entirely with the implementor (except that cwnd MUST be cut in half for a DUPACK-based congestion indication), i.e., the TSVWG should at most suggest what an implementor MAY do to initialize or adapt the DUPTHRESH (as long as DUPTHRESH <= FlightSizeInMSS, I guess). Furthermore, the Early Retransmit algorithm would become a totally OK thing to do. Implementors MAY simply use it (as long as packet conservation and the TCP congestion control principles are preserved). If that view found consensus in the TSVWG, the problem of how to respond to a detected spurious retransmit (spurious timeout or spurious fast retransmit) would be reduced to the problem of how to reverse the congestion control state. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 11 16:03:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12172 for ; Tue, 11 Mar 2003 16:03:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BLHTV00581 for tsvwg-archive@odin.ietf.org; Tue, 11 Mar 2003 16:17:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BLH7O00540; Tue, 11 Mar 2003 16:17:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BLGIO00507 for ; Tue, 11 Mar 2003 16:16:18 -0500 Received: from palrel10.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12133 for ; Tue, 11 Mar 2003 16:02:10 -0500 (EST) Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel10.hp.com (Postfix) with ESMTP id 1D1181C02263 for ; Tue, 11 Mar 2003 13:04:18 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_24419+JAGae58098)/8.9.3 SMKit7.02) with ESMTP id NAA26586 for ; Tue, 11 Mar 2003 13:04:17 -0800 (PST) Message-ID: <3E6E4F51.595663CF@hp.com> Date: Tue, 11 Mar 2003 13:04:17 -0800 From: Rick Jones Reply-To: raj@cup.hp.com Organization: the Unofficial HP X-Mailer: Mozilla 4.79 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] Dealing with Spurious Retransmits in TCP References: <5.1.0.14.0.20030311104535.028037f8@mailhost.eed.ericsson.se> <5.1.0.14.0.20030311204434.00aaaee8@mailhost.eed.ericsson.se> 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-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Reiner Ludwig wrote: > The amount of useful data sent by the current TCP should be pretty > close to 100 percent. The amount of useful data sent by some RTP/UDPs > (even if they are TCP-friendly) should for certain content encodings > be << 100 percent. So, I think we should relax a little when it comes > to proposals like Early Retransmit, and also allow TCP a bit more > redundancy (within the bounds of packet conservation and the TCP > congestion control principles). Is there a pointer to the ratios of TCP to RTP/UDP traffic for the present and near future? rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 11 16:27:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12895 for ; Tue, 11 Mar 2003 16:27:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BLfVF02440 for tsvwg-archive@odin.ietf.org; Tue, 11 Mar 2003 16:41:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BLfDO02429; Tue, 11 Mar 2003 16:41:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BLeSO02402 for ; Tue, 11 Mar 2003 16:40:28 -0500 Received: from maestra.inria.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12862 for ; Tue, 11 Mar 2003 16:26:20 -0500 (EST) Received: from sophia.inria.fr (localhost [127.0.0.1]) by maestra.inria.fr (8.12.8/8.12.5) with ESMTP id h2BLM3ra002624; Tue, 11 Mar 2003 22:22:03 +0100 X-Authentication-Warning: maestra.inria.fr: Host localhost [127.0.0.1] claimed to be sophia.inria.fr Message-ID: <3E6E537B.4080605@sophia.inria.fr> Date: Tue, 11 Mar 2003 22:22:03 +0100 From: Urtzi Ayesta User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203 X-Accept-Language: fr-FR, en, eu, es-ES MIME-Version: 1.0 To: raj@cup.hp.com CC: tsvwg@ietf.org Subject: Re: [Tsvwg] Dealing with Spurious Retransmits in TCP References: <5.1.0.14.0.20030311104535.028037f8@mailhost.eed.ericsson.se> <5.1.0.14.0.20030311204434.00aaaee8@mailhost.eed.ericsson.se> <3E6E4F51.595663CF@hp.com> In-Reply-To: <3E6E4F51.595663CF@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rick Jones wrote: >Is there a pointer to the ratios of TCP to RTP/UDP traffic for the >present and near future? > >rick jones > you might want to take a look to these papers: C. Fraleigh, S. Moon, B. Lyles, C. Cotton, M. Khan, D. Moll, R. Rockell, T. Seely, C. Diot,. "Packet-level Traffic Measurement from the Sprint IP Backbone" . To be published in IEEE Network Magazine. 2003 Kevin Thompson, Gregory J. Miller, and Rick Wilder. "Wide-area Internet traffic patterns and characteristics". IEEE Network, 11(6), November 1997. urtzi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Mar 12 01:35:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28130 for ; Wed, 12 Mar 2003 01:35:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C6nEO06540 for tsvwg-archive@odin.ietf.org; Wed, 12 Mar 2003 01:49:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C6lhO06452; Wed, 12 Mar 2003 01:47:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C6kiO06428 for ; Wed, 12 Mar 2003 01:46:44 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28097; Wed, 12 Mar 2003 01:32:22 -0500 (EST) Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18szor-0001JZ-00; Tue, 11 Mar 2003 22:34:29 -0800 To: tsvwg@ietf.org, agenda@ietf.org Cc: mankin@psg.com, sob@harvard.edu, jon.peterson@neustar.biz Reply-To: mankin@psg.com Date: Tue, 11 Mar 2003 22:34:26 -0800 From: Allison Mankin Message-Id: Subject: [Tsvwg] Agenda for TSVWG Meeting in SF Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Agenda of the Transport Area Working Group Thursday 20 March 13:00-15:00 Brief intro - Chairs - 5 mins RSVP-change discussion* draft-kompella-rsvp-change-00.txt - Kireeti Kompella - 10 mins. *New task for tsvwg - to help the task of IETF keeping RSVP protocol registrations coherent. Measurement discussion* draft-bennett-ippm-ipmp-01.txt - John Bennett - 15 mins. *An IP measurement protocol, this was considered by the IPPM WG, but seen as broader, so sent here for a discussion by a larger group of transport folks. TCP discussions, two returning* and two new drafts: draft-floyd-tcp-highspeed-02.txt* - Sally Floyd - 15 mins. draft-blanton-dsack-use-02.txt* - Mark Allman - 5 mins. draft-blanton-tcp-reordering-00.txt - Mark Allman - 15 mins. draft-allman-tcp-early-rexmt-00.txt - Mark Allman - 15 mins. Plans for newreno standardization - Sally Floyd - 5 mins. SCTP discussion - thorough review of PR-SCTP draft-stewart-tsvwg-prsctp-03.txt - Randall Stewart - 35 mins. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Mar 12 04:14:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26832 for ; Wed, 12 Mar 2003 04:14:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C9RsU27161 for tsvwg-archive@odin.ietf.org; Wed, 12 Mar 2003 04:27:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C9RTO27153; Wed, 12 Mar 2003 04:27:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C9OTO27058 for ; Wed, 12 Mar 2003 04:24:29 -0500 Received: from smtp.dave.sonera.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26753 for ; Wed, 12 Mar 2003 04:10:07 -0500 (EST) Received: from gurtoan1-nb2.etela.sonera.fi ([131.177.37.47]:2125 "HELO gurtoannb2") by inside.dave.sonera.fi with SMTP id ; Wed, 12 Mar 2003 11:12:19 +0200 Message-ID: <006301c2e877$697a9a30$2f25b183@gurtoannb2> From: "Andrei Gurtov" To: Subject: Re: [Tsvwg] early retransmit Date: Wed, 12 Mar 2003 11:11:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1123 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mark Allman wrote: >Mark Allman, Konstantin Avrachenkov, Urtzi Ayesta, Josh Blanton. Early Retransmit for TCP, February 2003. Internet-Draft draft-allman-tcp-early-rexmt-00.txt (work in progress). http://roland.grc.nasa.gov/~mallman/papers/draft-allman-tcp-early-rexmt-00.txt Another possible hack could be as follows. When cwnd<4 do not trigger fast retransmit even if 3 DUPACKs are received. The rationale is that DUPACKs in such case come from unnecessary retransmissions in the past (or duplication which is less likely). They do not indicate a lost packet since there is unsufficient flight size to trigger enough "good" DUPACKs. I guess this hack conflicts somehow with LT and ER... Andrei _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Mar 12 07:43:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01837 for ; Wed, 12 Mar 2003 07:43:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CCvI508930 for tsvwg-archive@odin.ietf.org; Wed, 12 Mar 2003 07:57:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CCuoO08907; Wed, 12 Mar 2003 07:56:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CCtMO08862 for ; Wed, 12 Mar 2003 07:55:22 -0500 Received: from pop-2.dnv.wideopenwest.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01776 for ; Wed, 12 Mar 2003 07:40:54 -0500 (EST) Received: from thoth.ir.bbn.com (d53-66-209.clv.wideopenwest.com [64.53.209.66]) by pop-2.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h2CCmaV23769; Wed, 12 Mar 2003 06:48:36 -0600 Received: from thoth.ir.bbn.com (localhost [127.0.0.1]) by thoth.ir.bbn.com (8.12.6/8.12.6) with ESMTP id h2CCiYqH067970; Wed, 12 Mar 2003 07:44:35 -0500 (EST) (envelope-from mallman@thoth.ir.bbn.com) Message-Id: <200303121244.h2CCiYqH067970@thoth.ir.bbn.com> To: "Andrei Gurtov" From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit In-Reply-To: <006301c2e877$697a9a30$2f25b183@gurtoannb2> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Money Date: Wed, 12 Mar 2003 07:44:34 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > Another possible hack could be as follows. When cwnd<4 do not > trigger fast retransmit even if 3 DUPACKs are received. The > rationale is that DUPACKs in such case come from unnecessary > retransmissions in the past (or duplication which is less > likely). They do not indicate a lost packet since there is > unsufficient flight size to trigger enough "good" DUPACKs. Ah-ha! Right, so there are lots of such cases. But, I think that using bugfix (ala RFC 2582) alliviates that problem, right? In which case it would be good to add a dependancy of bugfix on implementing ER. Or, are there some corner cases that would not be caught by bugfix? Thanks! allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Mar 12 10:04:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05461 for ; Wed, 12 Mar 2003 10:04:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CFIXV18493 for tsvwg-archive@odin.ietf.org; Wed, 12 Mar 2003 10:18:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFIFO18476; Wed, 12 Mar 2003 10:18:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFHtO18451 for ; Wed, 12 Mar 2003 10:17:55 -0500 Received: from smtp.dave.sonera.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05291 for ; Wed, 12 Mar 2003 10:03:23 -0500 (EST) Received: from gurtoan1-nb2.etela.sonera.fi ([131.177.37.47]:1659 "HELO gurtoannb2") by inside.dave.sonera.fi with SMTP id ; Wed, 12 Mar 2003 17:05:28 +0200 Message-ID: <006d01c2e8a8$c056d0e0$2f25b183@gurtoannb2> From: "Andrei Gurtov" To: Cc: References: <200303121244.h2CCiYqH067970@thoth.ir.bbn.com> Subject: Re: [Tsvwg] early retransmit Date: Wed, 12 Mar 2003 17:04:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1123 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > Another possible hack could be as follows. When cwnd<4 do not > > trigger fast retransmit even if 3 DUPACKs are received. The > > rationale is that DUPACKs in such case come from unnecessary > > retransmissions in the past (or duplication which is less > > likely). They do not indicate a lost packet since there is > > unsufficient flight size to trigger enough "good" DUPACKs. > > Ah-ha! > > Right, so there are lots of such cases. But, I think that using > bugfix (ala RFC 2582) alliviates that problem, right? In which case > it would be good to add a dependancy of bugfix on implementing ER. > Or, are there some corner cases that would not be caught by bugfix? Right, bugfix prevents this problem. However, denying all fast retransmits until the recovery point (what the bugfix does) might be too cruel. This hack is milder and might be more suitable for general use. As an example against the bugfix consider a handover of a TCP connection from a network X with 100-KB buffer to a network Y with 10-KB buffer (I don't argue that this is a common case in the Internet). All outstanding segments get lost, TCP recovers with go-back-N after a timeout. However, since fast retransmits are denied, every CA cycle until the recovery point has to be recovered with a timeout. The throughput is low. Alternatively, it's possible to construct a case where bugfix is very useful to prevent unnecessary retransmits. My point is that there is a slippery tradeoff about bugfix, and I don't know if there is enough consensus to put it on the standard track. Also, this hack prevents against duplication in absence of a timeout, while the bugfix does not. I know duplication is considered rare, but it can occur frequently due to bicasting over several access links. Sally has Newreno on the TSVWG agenda in SF and maybe we will hear what is the plan about bugfix, since it's currently a part of RFC2582. At least this beast needs a better name. Either way, I think that ER draft should mention that DUPACKs after a timeout are not considered. Andrei _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Mar 12 10:14:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06808 for ; Wed, 12 Mar 2003 10:14:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CFSkp19092 for tsvwg-archive@odin.ietf.org; Wed, 12 Mar 2003 10:28:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFSQO19063; Wed, 12 Mar 2003 10:28:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFOrO18839 for ; Wed, 12 Mar 2003 10:24:53 -0500 Received: from seraph3.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06295 for ; Wed, 12 Mar 2003 10:10:23 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 942A16BA0F for ; Wed, 12 Mar 2003 10:12:31 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h2CFCV7h006254; Wed, 12 Mar 2003 10:12:31 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id KAA17906; Wed, 12 Mar 2003 10:12:30 -0500 (EST) Message-Id: <200303121512.KAA17906@guns.lerc.nasa.gov> To: "Andrei Gurtov" From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit In-Reply-To: <006d01c2e8a8$c056d0e0$2f25b183@gurtoannb2> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Nothingman Date: Wed, 12 Mar 2003 10:12:30 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > > > Another possible hack could be as follows. When cwnd<4 do not > > > trigger fast retransmit even if 3 DUPACKs are received. So, maybe I don't understand the "hack". My reading of the above (from your original note) basically says that we wouldn't use ER. That is, ER says that if cwnd<4 you can fast retransmit on less dupacks. The above says we cannot. What am I missing? (And, I agree with you ... our naming scheme is grand. We have "bugfix" and now we're talking about adding a "hack" to a spec! :) allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Mar 12 12:39:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12626 for ; Wed, 12 Mar 2003 12:39:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CHrYj30847 for tsvwg-archive@odin.ietf.org; Wed, 12 Mar 2003 12:53:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHqWO30815; Wed, 12 Mar 2003 12:52:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHpYO30778 for ; Wed, 12 Mar 2003 12:51:34 -0500 Received: from thebe.your-site.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12560 for ; Wed, 12 Mar 2003 12:37:00 -0500 (EST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 13F0B245639; Wed, 12 Mar 2003 12:39:10 -0500 (EST) Date: Wed, 12 Mar 2003 11:40:56 -0600 From: Caitlin Bestler Subject: Re: [Tsvwg] Dealing with Spurious Retransmits in TCP To: Reiner Ludwig , tsvwg@ietf.org, "." <"."@asomi.com> X-Priority: 3 In-Reply-To: <5.1.0.14.0.20030311204434.00aaaee8@mailhost.eed.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 3/11/03, Reiner Ludwig wrote: >I know, this PSR (sending Potentially Spurious Retransmit >without any clue of a loss indication) option for TCP is >probably the extreme case of maximum redundancy. And I see >your points why this might not be so popular. Independent >of whether that would ever fly, I feel (and that's the >point I want to make) that we are way too strict to TCP; >at least much stricter than we are with RTP/UDP-based >streams. And that's not fair ;-( There are at least two signifigant differences. First, the retransmission policy is being applied by the ULP itself. While there is no way to enforce this, typically the redundant packets are not selected at random. They represent critical data which will have a disproportionate impact if lost. For example, an MPEG Stream can more easily tolerate the loss of P and B frames than I frames. The retransmission policy may be limited to critical data and only in response to a retransmit request. In these scenarios the ULP is prioritizing retransmission based upon how critical the data is. When faced with network congestion the ULP responds by dropping less critical data messages, either on retransmission or entirely. PSR adds traffic just in case there may be congestion, and does so at the transport level without any knowledge of the relative importance of the data to the ULP. I'm not judging whether or not there are conditions where this might be valuable, merely that it is far beyond what RTP/UDP applications do the network. A second reason some RTP/UDP applications send redundant packets even with an explicit NACK is that they are laregly one-way protocols. There are no routine reverse-flow acks. This may be because the return path is limited in bandwidth, has a very long round-trip time, or the forward path is multicast. In any event, with every RTP/UDP application I am aware of, any redundant forward packets are minor compared to the network savings of omitting reverse path aks. Additionally, I suspect the trend for these applications will be to encourage their migration to PR-SCTP or DCP to encourage more uniform congestion control. RTP/UDP applications apply rate based control, but do so on their own without central control. This is admittedly unfair, and should be phased out someday. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Mar 12 16:07:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22891 for ; Wed, 12 Mar 2003 16:07:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CLLe215512 for tsvwg-archive@odin.ietf.org; Wed, 12 Mar 2003 16:21:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLLJO15496; Wed, 12 Mar 2003 16:21:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLKVO15390 for ; Wed, 12 Mar 2003 16:20:31 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22758 for ; Wed, 12 Mar 2003 16:05:53 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 165EF328A7; Wed, 12 Mar 2003 16:08:03 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 29102328A6; Wed, 12 Mar 2003 16:08:02 -0500 (EST) Date: Wed, 12 Mar 2003 16:08:02 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Yogesh Prem Swami Cc: , Ethan Blanton , ext Reiner Ludwig , Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <1047312627.17940.25.camel@atcp01.americas.nokia.com> Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On 10 Mar 2003, Yogesh Prem Swami wrote: > On Fri, 2003-03-07 at 13:44, ext Mark Allman wrote: > > > The ACK clock is how you send new data into the > > > network. Congestion response is about how you prevent unnecessary > > > packet loss. These two are different issues. Ack clocking *can* be > > > used to prevent congestion if these ACKs arrive in a regular > > > fashion. If the ACKs don't arrive in a regular fashion, as in case > > > of spurious timeout, they don't convey any information. > > > > I would phrase it "they may not convey any useful information". On > > Agreed, that's the right wording. But, the fact that a TCP sender will > have the right information will only be a coincidence. > > One cannot design a congestion response based on coincidences. If that > weren't the case then AIAD (.. additive decrease) would have been > sufficient since in some sunny day scenarios we don't need AIMD. To me, it seems like you are arguing against TCP's feedback mechanism. Yes, the feedback mechanism _may_ be too slow to convey good/bad information at times. But the feedback mechanism seems to work fine, and it is what we have to work with. Let me flip the perspective on spurious timeouts. Suppose that a spurious timeout occurs when the RTO is 1 sec. Since the timeout was in fact spurious, all we can REALLY infer from this is that the RTO was too low. Ok, that's obvious. Now suppose that instead of the RTO being 1 sec, it was actually 2 secs. Then the spurious timeout would probably not occur at all. Thus, we wouldn't be concerned with the cwnd being stale, would we? The acks would continue clocking out new data as normally done and nobody would complain because maybe the RTT is really just THAT long. The fact that as the RTT increases, the feedback mechanism becomes "less realiable" is a different problem altogether I think. But flows with long or even highly variable RTTs should not be penalized. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Mar 12 18:22:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29444 for ; Wed, 12 Mar 2003 18:22:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CNabn25583 for tsvwg-archive@odin.ietf.org; Wed, 12 Mar 2003 18:36:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CNT6O24928; Wed, 12 Mar 2003 18:29:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BDjsO30787 for ; Tue, 11 Mar 2003 08:45:54 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18874 for ; Tue, 11 Mar 2003 08:31:53 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 11 Mar 2003 05:34:02 -0800 Received: from 210.210.68.4 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 11 Mar 2003 13:34:01 GMT X-Originating-IP: [210.210.68.4] From: "john smith" To: rhee@eos.ncsu.edu, Reiner.Ludwig@eed.ericsson.se, tsvwg@ietf.org Cc: end2end-interest@postel.org Date: Tue, 11 Mar 2003 13:34:01 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Mar 2003 13:34:02.0127 (UTC) FILETIME=[E0D921F0:01C2E7D2] Subject: [Tsvwg] RE: [e2e] Dealing with Spurious Retransmits in TCP Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , i think this would have more to do with RWIN than MSS...... eitherways, why not cap RWIN as was previously suggested once here? >From: "Injong Rhee" >To: "'Reiner Ludwig'" , >CC: >Subject: RE: [e2e] Dealing with Spurious Retransmits in TCP >Date: Mon, 10 Mar 2003 11:40:56 -0500 > >I agree with Reiner. The main problem lies in unnecessary coupling of >recovery and congestion control in TCP. I view CC is an independent from >recovery. Whether it can transmit spurious retransmission or simply do >no-op, it should left to the application or other layer decision. >Therefore, CC must tell the current rate (or window size) that the data >(including retransmission) must be sent at and the recovery layer >decides on whether it should retransmit, forward-error correction or >other data packets. > >Injong Rhee >Computer Science Dept >North Carolina State Univ. >rhee@csc.ncsu.edu >http://www.csc.ncsu.edu/faculty/rhee > >-----Original Message----- >From: end2end-interest-admin@postel.org >[mailto:end2end-interest-admin@postel.org] On Behalf Of Reiner Ludwig >Sent: Monday, March 10, 2003 4:53 AM >To: tsvwg@ietf.org >Cc: end2end-interest@postel.org >Subject: [e2e] Dealing with Spurious Retransmits in TCP > >[I have cc:ed end2end-interest@postel.org, but please reply only to >tsvwg@ietf.org to avoid double postings.] > >What about the following rule for those TCPs that are enhanced to detect > >spurious retransmits? > > Those TCPs MUST reduce their cwnd by MSS (alternatively by the >amount > of spuriously retransmitted data) when a spurious retransmit has >been > detected. > >The logic would be to say that since the TCP sender has used more than >its >fair share of bandwidth in the past (due to the spurious retransmit), it > >has to pay back for that once the spurious retransmit has been detected. > >With that rule, the policies for adapting RTO and DUPTHRESH would become > >less crucial. > >Moreover, a TCP sender for interactive applications (assuming that this >implies that response time is more important than throughput) may then >have >the freedom to use a non-standard retransmission timer (more optimistic; > >not to say more aggressive), and Early Retransmit without concerns. > >Taking this a step further, one could argue that as long as the TCP >sender >uses no more than its fair share of bandwidth, it is free to send what >it >wants. For example, everytime an acceptable ACK arrives, and the TCP >sender >does not have new data available, it may retransmit from the queue of >unacked data. >RTP/UDP-based streams are also allowed to add redundancy in the form of >FEC >and retransmissions when the source rate is lower than the available >bandwidth, or to trade some of their throughput and responsiveness for >an >increased reliability. >So, couldn't TCP also trade unused throughput for an increased >responsiveness by adding redundancy in the form of sending potentially >spurious retransmits? > >///Reiner > > _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 13 03:14:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23546 for ; Thu, 13 Mar 2003 03:14:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2D8Sth04768 for tsvwg-archive@odin.ietf.org; Thu, 13 Mar 2003 03:28:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D8SUO04756; Thu, 13 Mar 2003 03:28:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D8RSO04722 for ; Thu, 13 Mar 2003 03:27:28 -0500 Received: from smtp.inet.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23535 for ; Thu, 13 Mar 2003 03:12:35 -0500 (EST) Received: from hoas-50dd01ba.hoasnet.inet.fi ([80.221.1.186]:32989 "EHLO cs.helsinki.fi") by nauta.media.sonera.net with ESMTP id ; Thu, 13 Mar 2003 10:14:44 +0200 Message-ID: <3E703DEA.3030600@cs.helsinki.fi> Date: Thu, 13 Mar 2003 10:14:34 +0200 From: Andrei Gurtov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@grc.nasa.gov CC: tsvwg@ietf.org Subject: Re: [Tsvwg] early retransmit References: <200303121512.KAA17906@guns.lerc.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mark Allman wrote: >So, maybe I don't understand the "hack". My reading of the above >(from your original note) basically says that we wouldn't use ER. >That is, ER says that if cwnd<4 you can fast retransmit on less >dupacks. The above says we cannot. What am I missing? > > Maybe the solution is to use ER during normal transmission (when not below snd_max after timeout). Otherwise use "bugfix" or "hack". That does not allow the "hack" to protect against duplication. But since ER addressess a much more common case, perhaps it should be used... Andrei _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 14 11:55:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02531 for ; Fri, 14 Mar 2003 11:55:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EHA3X25730 for tsvwg-archive@odin.ietf.org; Fri, 14 Mar 2003 12:10:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EH9bO25655; Fri, 14 Mar 2003 12:09:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EH4SO24589 for ; Fri, 14 Mar 2003 12:04:28 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02426 for ; Fri, 14 Mar 2003 11:48:56 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EGscF18613 for ; Fri, 14 Mar 2003 18:54:38 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 14 Mar 2003 18:51:06 +0200 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 18:51:04 +0200 From: Yogesh Prem Swami To: tsvwg@ietf.org Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1047660663.6672.29.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 14 Mar 2003 10:51:03 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2003 16:51:05.0269 (UTC) FILETIME=[E73AAE50:01C2EA49] Content-Transfer-Encoding: 7bit Subject: [Tsvwg] DCLOR source code Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello folks, Here's the patch for DCLOR (you need to download linux kernel 2.5.40 separately) http://people.nokia.net/~yogesh/dclor-2.5.40.tar.gz Please let me know your experience. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sun Mar 16 14:17:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03448 for ; Sun, 16 Mar 2003 14:17:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GJXL317626 for tsvwg-archive@odin.ietf.org; Sun, 16 Mar 2003 14:33:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GJWdO17537; Sun, 16 Mar 2003 14:32:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GJUCO17453 for ; Sun, 16 Mar 2003 14:30:12 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03274 for ; Sun, 16 Mar 2003 14:13:37 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2GJFmwv029809; Sun, 16 Mar 2003 20:15:48 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id GPHKRR36; Sun, 16 Mar 2003 20:15:47 +0100 Received: from res0010384da36.eed.ericsson.se (rmt160177.am.ericsson.se [138.85.160.177]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id UAA05809; Sun, 16 Mar 2003 20:15:44 +0100 (MET) Message-Id: <5.1.0.14.0.20030316193555.027dabd8@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 16 Mar 2003 19:39:27 +0100 To: Caitlin Bestler From: Reiner Ludwig Subject: Re: [Tsvwg] Dealing with Spurious Retransmits in TCP Cc: tsvwg@ietf.org In-Reply-To: References: <5.1.0.14.0.20030311204434.00aaaee8@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 18:40 12.03.2003, Caitlin Bestler wrote: >In any event, with every RTP/UDP application I am aware of, >any redundant forward packets are minor compared to the >network savings of omitting reverse path aks. But as we move current RTP/UDP unicast applications to RTP/DCCP, we will have ACK traffic of probably the same order as in the case of TCP. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 17 17:00:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04015 for ; Mon, 17 Mar 2003 17:00:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HMGhl08138 for tsvwg-archive@odin.ietf.org; Mon, 17 Mar 2003 17:16:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HMGNO08110; Mon, 17 Mar 2003 17:16:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HMD1O07972 for ; Mon, 17 Mar 2003 17:13:01 -0500 Received: from lawyers.ir.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03822 for ; Mon, 17 Mar 2003 16:55:56 -0500 (EST) Received: from lawyers (mallman@localhost) by lawyers.ir.bbn.com (8.9.3/8.9.3) with ESMTP id NAA09282; Mon, 17 Mar 2003 13:09:49 -0500 Message-Id: <200303171809.NAA09282@lawyers.ir.bbn.com> To: Reiner Ludwig From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: "Armando L. Caro Jr." , tsvwg@ietf.org Subject: Re: [Tsvwg] Eifel-Response-03 In-Reply-To: <5.1.0.14.0.20030307141843.02ae1e18@mailhost.eed.ericsson.se> Organization: BBN Technologies/NASA GRC Song-of-the-Day: You Date: Mon, 17 Mar 2003 13:09:49 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > At 17:28 06.03.2003, Armando L. Caro Jr. wrote: > >I quickly skimmed the draft and saw on page 5, the step for reverting cwnd > >includes the following text: > > > > If the acceptable ACK has the ECN-Echo flag [RFC3168] set > > OR the TCP sender has already taken more than three > > timeouts for the oldest outstanding segment, then proceed > > to step (DONE), > > > >How was the value three chosen? > > Out of the hat. It's up for debate. > > The question is: How many spurious timeouts in a row, i.e., for > the same outstanding sequence number, are OK to still restore > congetsion control state? My vote would be <= 1 RTO for a full restore. > In an earlier proposal, we suggested "full restore" for the first > spurious timeout, "half restore" for the second spurious timeout, > etc. (see > http://iceberg.cs.berkeley.edu/papers/Ludwig-Eifel-Alg/index.html) I like this. But, as I offered before the starting point might need to be variable... If it has been >= RTO since we last sent something then you get to restore to only half the previous value. If it has been <= RTO seconds then you can start by fully restoring. (Followed by having on each subsequent RTO.) allman -- Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 17 17:26:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04878 for ; Mon, 17 Mar 2003 17:26:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HMhRe10151 for tsvwg-archive@odin.ietf.org; Mon, 17 Mar 2003 17:43:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HMh7O10119; Mon, 17 Mar 2003 17:43:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HMe5O10009 for ; Mon, 17 Mar 2003 17:40:05 -0500 Received: from mail.cs.helsinki.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04749 for ; Mon, 17 Mar 2003 17:23:00 -0500 (EST) Received: from melkinpaasi.cs.Helsinki.FI (melkinpaasi.cs.helsinki.fi [::ffff:128.214.10.13]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 18 Mar 2003 00:25:12 +0200 Date: Tue, 18 Mar 2003 00:25:12 +0200 (EET) From: Jukka MJ Manner To: tsvwg@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Presentation of LRSVP on Thursday Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, I'll have a short (very few slides) presentation on the "Localized RSVP" draft at the TSVWG session on Thursday afternoon. Allison asked me to give a pointer to people because this presentation was added to the agenda very recently. In summary, we make use of two unused bits in the Session Object and add two new messages that are in structure copies of Path and PathTear messages. The modification does not prevent or harm standard end-to-end RSVP reservations, only adds a new usage scenario. Regards, Jukka Title : Localized RSVP Author(s) : J. Manner et al. Filename : draft-manner-lrsvp-01.txt Pages : 16 Date : 2003-1-14 Guaranteed QoS for multimedia applications is based on reserved resources in each node on the end-to-end path. Even if the correspondent node does not support QoS, it would be useful to be able to reserve at least local resources at the access network, especially wireless link resources. Additionally, for mobile nodes the continuity of QoS is disturbed due to end-to-end signalling or slow re-reservations of resources after each handover. This draft proposes a simple enhancement to RSVP, so that initial resource reservations and re-reservations due to host mobility can be done locally in an access network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-manner-lrsvp-01.txt _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 18 17:13:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02858 for ; Tue, 18 Mar 2003 17:13:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IMUur25170 for tsvwg-archive@odin.ietf.org; Tue, 18 Mar 2003 17:30:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IMUTO25122; Tue, 18 Mar 2003 17:30:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IMTpO25089 for ; Tue, 18 Mar 2003 17:29:51 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02821 for ; Tue, 18 Mar 2003 17:12:15 -0500 (EST) From: Pasi.Sarolahti@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2IMD4M02128 for ; Wed, 19 Mar 2003 00:13:04 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 19 Mar 2003 00:14:27 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 00:14:28 +0200 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 00:14:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 19 Mar 2003 00:14:27 +0200 Message-ID: <7AB8A321754AC94E9D6753AB81439C2F10951A@esebe021.ntc.nokia.com> Thread-Topic: Spurious RTOs and SCTP Thread-Index: AcLtm75AJZ9vBO/FTCunmJFUKB/zQg== To: X-OriginalArrivalTime: 18 Mar 2003 22:14:28.0412 (UTC) FILETIME=[BE0E57C0:01C2ED9B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2IMTpO25090 Subject: [Tsvwg] Spurious RTOs and SCTP Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, The recent discussions on this list regarding to spurious RTOs have concerned only TCP, but shouldn't SCTP be considered also, since it does RTO-based retransmissions as well? I don't have any hands-on experience with SCTP, but it seems like detecting spurious RTOs by using F-RTO-like logic (see draft-sarolahti-tsvwg-tcp-frto-03.txt) applied to SCTP TSNs and SACKs should work. Or is it a bad idea? I could write a draftlet, but it would be nice to hear what folks think of it before doing that. - Pasi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Mar 19 18:13:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14888 for ; Wed, 19 Mar 2003 18:13:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JNVFL17397 for tsvwg-archive@odin.ietf.org; Wed, 19 Mar 2003 18:31:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JNUdO17370; Wed, 19 Mar 2003 18:30:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JNSEO17285 for ; Wed, 19 Mar 2003 18:28:14 -0500 Received: from gurtoan-nb2 (wl-130-141.wireless.ietf56.ietf.org [130.129.130.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14519 for ; Wed, 19 Mar 2003 18:10:08 -0500 (EST) Message-ID: <004501c2ee6c$c6a25040$8d828182@gurtoannb2> From: "Andrei Gurtov" To: Date: Wed, 19 Mar 2003 15:10:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1123 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] TCP trash-friendliness and TFRC Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, The TCP rate formulae for TFRC includes only loss rate, RTT (and MSS) as factors determining the TCP friendly sending rate. Consequently, if a TFRC flow runs concurrently with a TCP flow over a path with packet reordering, duplication or delay spikes, TFRC can significantly overshoot TCP. It would be nice to improve the TCP-friendly rate formulae to reflect reduction of the TCP rate during these events. The second thing is that TCP Reno seems to be widely recognized as a reference rate flow that does not cause congestion collapse under any circumstances. However, TCP Reno does send a significant amount of unnecessary data due to (spurious) timeouts and spurious fast retransmits. We can define TCP trash-friendliness as the amount of unnecessary data sent by TCP Reno over given network conditions. Since everybody finds TCP Reno acceptable, other TCPs could implement different features as long as they remain TCP friendly and trash-friendly. A first guess about the formulae looks like follows: t=(Cd*Rd+Cr*Rd+Cs*Rs+Ct*Rt)/w Where t - the fraction of unnecessary delivered packets w - average TCP window (can be computed using rate from TFRC formulae and RTT) Rd - rate of "bad"* duplication events Cd - number of retransmitted segments per duplication event (default 1) Rr - rate of "bad" reordering events Cr - number of retransmitted segments per reordering event (default 1) Rs - rate of "bad" timeouts Cs - number of retransmitted segments per spurious timeout (default w) Rt - rate of "good" timeouts (due to several lost packets) Ct - number of retransmitted segments per good timeout (default w/2) (Reno uses go-back-N which retransmits many packets unnecessarily) *Since not all delay spikes, reordering length or duplication patterns cause troubles we only account for "bad" cases which do cause retransmissions. Given this formulae, TCP SACK could for example apply a more aggressive retransmission timer because its more efficient loss recovery allows to keep t low. Furthermore, TCPs detecting spurious timeouts and fast retransmits do not have to use complicated adaptation schemes for RTO and dupthresh as long as their t is below Reno's. Probably, those are completely wild ideas... Andrei _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Mar 19 18:34:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15961 for ; Wed, 19 Mar 2003 18:34:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JNpkX19613 for tsvwg-archive@odin.ietf.org; Wed, 19 Mar 2003 18:51:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JNpCO19579; Wed, 19 Mar 2003 18:51:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JNoPO19539 for ; Wed, 19 Mar 2003 18:50:25 -0500 Received: from eve.icir.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15911 for ; Wed, 19 Mar 2003 18:32:18 -0500 (EST) Received: from eve.icir.org (localhost [127.0.0.1]) by eve.icir.org (8.12.7/8.12.2) with ESMTP id h2JNYDbC005199; Wed, 19 Mar 2003 15:34:13 -0800 (PST) From: Mark Handley X-Organisation: ICIR To: "Andrei Gurtov" cc: tsvwg@ietf.org Subject: Re: [Tsvwg] TCP trash-friendliness and TFRC In-reply-to: Your message of "Wed, 19 Mar 2003 15:10:08 PST." <004501c2ee6c$c6a25040$8d828182@gurtoannb2> Date: Wed, 19 Mar 2003 15:34:13 -0800 Message-ID: <5198.1048116853@eve.icir.org> Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , >The TCP rate formulae for TFRC includes only loss rate, RTT (and MSS) as >factors determining the TCP friendly sending rate. Consequently, if a TFRC >flow runs concurrently with a TCP flow over a path with packet reordering, >duplication or delay spikes, TFRC can significantly overshoot TCP. It would >be nice to improve the TCP-friendly rate formulae to reflect reduction of >the TCP rate during these events. There is absolutely no good reason why TCP can't cope with significant re-ordering, and there are several good papers on how to solve this issue. The correct solution is to fix TCP. If TFRC beats up TCP under these circumstances, they that may provide a good incentive to fix TCP. Cheers, Mark _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 20 00:34:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26509 for ; Thu, 20 Mar 2003 00:34:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K5puS12380 for tsvwg-archive@odin.ietf.org; Thu, 20 Mar 2003 00:51:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K5pVO12363; Thu, 20 Mar 2003 00:51:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K5nvO12312 for ; Thu, 20 Mar 2003 00:49:57 -0500 Received: from cougar.icir.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26446 for ; Thu, 20 Mar 2003 00:31:23 -0500 (EST) Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.3/8.12.3) with ESMTP id h2K5XdDX070244 for ; Wed, 19 Mar 2003 21:33:39 -0800 (PST) (envelope-from floyd@cougar.icir.org) Message-Id: <200303200533.h2K5XdDX070244@cougar.icir.org> To: tsvwg@ietf.org From: Sally Floyd Date: Wed, 19 Mar 2003 21:33:39 -0800 Subject: [Tsvwg] viewgraphs for two presentations in tsvwg tomorrow Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , HighSpeed TCP and Quick-Start for Fast Long-Distance Networks tsvwg, IETF, March 2003. http://www.icir.org/floyd/talks/hstcp-Mar03.ps http://www.icir.org/floyd/talks/hstcp-Mar03.pdf Moving NewReno from Experimental to Proposed Standard? tsvwg, IETF, March 2003. http://www.icir.org/floyd/talks/newreno-Mar03.ps http://www.icir.org/floyd/talks/newreno-Mar03.pd - Sally _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 20 11:03:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22824 for ; Thu, 20 Mar 2003 11:03:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KGKxJ30835 for tsvwg-archive@odin.ietf.org; Thu, 20 Mar 2003 11:20:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KGKXO30729; Thu, 20 Mar 2003 11:20:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KGDhO30445 for ; Thu, 20 Mar 2003 11:13:43 -0500 Received: from cougar.icir.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22503 for ; Thu, 20 Mar 2003 10:55:16 -0500 (EST) Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.3/8.12.3) with ESMTP id h2KFvVDX073972; Thu, 20 Mar 2003 07:57:31 -0800 (PST) (envelope-from floyd@cougar.icir.org) Message-Id: <200303201557.h2KFvVDX073972@cougar.icir.org> To: Jeffrey Hsu cc: tsvwg@ietf.org From: Sally Floyd Subject: Re: [Tsvwg] viewgraphs for two presentations in tsvwg tomorrow Date: Thu, 20 Mar 2003 07:57:31 -0800 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , >Hello. The following 2 links aren't found. Perhaps I jumped the gun? >http://www.icir.org/floyd/talks/newreno-Mar03.ps >http://www.icir.org/floyd/talks/newreno-Mar03.pd Sorry, they should be there now: http://www.icir.org/floyd/talks/newreno-Mar03.pdf - Sally _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 20 11:37:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23945 for ; Thu, 20 Mar 2003 11:37:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KGtWb03817 for tsvwg-archive@odin.ietf.org; Thu, 20 Mar 2003 11:55:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KGt9O03714; Thu, 20 Mar 2003 11:55:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KGsLO03642 for ; Thu, 20 Mar 2003 11:54:21 -0500 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23866 for ; Thu, 20 Mar 2003 11:35:54 -0500 (EST) Received: from isi.edu ([66.114.232.36]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id h2KGc6v09097; Thu, 20 Mar 2003 08:38:06 -0800 (PST) Message-ID: <3E79EE5C.2040308@isi.edu> Date: Thu, 20 Mar 2003 08:37:48 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Handley CC: Andrei Gurtov , tsvwg@ietf.org Subject: Re: [Tsvwg] TCP trash-friendliness and TFRC References: <5198.1048116853@eve.icir.org> In-Reply-To: <5198.1048116853@eve.icir.org> X-Enigmail-Version: 0.73.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mark Handley wrote: ... > There is absolutely no good reason why TCP can't cope with significant > re-ordering, and there are several good papers on how to solve this > issue. The correct solution is to fix TCP. If TFRC beats up TCP > under these circumstances, they that may provide a good incentive to > fix TCP. > > Cheers, > Mark Fix TCP because TCP-"friendly" rate control beats up TCP? With "friends" like that, who needs enemies! Joe _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 20 12:07:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25015 for ; Thu, 20 Mar 2003 12:07:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KHPNj06907 for tsvwg-archive@odin.ietf.org; Thu, 20 Mar 2003 12:25:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KHP1O06816; Thu, 20 Mar 2003 12:25:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KH3iO04344 for ; Thu, 20 Mar 2003 12:03:44 -0500 Received: from eve.icir.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24112 for ; Thu, 20 Mar 2003 11:45:16 -0500 (EST) Received: from eve.icir.org (localhost [127.0.0.1]) by eve.icir.org (8.12.7/8.12.2) with ESMTP id h2KGlQbC018604; Thu, 20 Mar 2003 08:47:26 -0800 (PST) From: Mark Handley X-Organisation: ICIR To: Joe Touch cc: Andrei Gurtov , tsvwg@ietf.org Subject: Re: [Tsvwg] TCP trash-friendliness and TFRC In-reply-to: Your message of "Thu, 20 Mar 2003 08:37:48 PST." <3E79EE5C.2040308@isi.edu> Date: Thu, 20 Mar 2003 08:47:26 -0800 Message-ID: <18603.1048178846@eve.icir.org> Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , >Fix TCP because TCP-"friendly" rate control beats up TCP? No. Fix TCP because a decent standards-compliant TCP implementation that didn't trip over its own showlaces in the face of reordering would beat up existing TCP implementations. >With "friends" like that, who needs enemies! :-) - Mark _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 20 12:50:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27016 for ; Thu, 20 Mar 2003 12:50:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KI8Nq11068 for tsvwg-archive@odin.ietf.org; Thu, 20 Mar 2003 13:08:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KI87O11029; Thu, 20 Mar 2003 13:08:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KI7kO11006 for ; Thu, 20 Mar 2003 13:07:46 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27000 for ; Thu, 20 Mar 2003 12:49:17 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2KHo6M13514 for ; Thu, 20 Mar 2003 19:50:07 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 20 Mar 2003 19:51:32 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Mar 2003 19:51:32 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Mar 2003 19:51:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Tsvwg] Spurious RTOs and SCTP Date: Thu, 20 Mar 2003 19:51:32 +0200 Message-ID: Thread-Topic: Spurious RTOs and SCTP Thread-Index: AcLtm75AJZ9vBO/FTCunmJFUKB/zQgBbWgyA To: , X-OriginalArrivalTime: 20 Mar 2003 17:51:32.0387 (UTC) FILETIME=[57A37730:01C2EF09] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2KI7kO11007 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, Actually, this brings up a more broad question - as SCTP and TCP share (basically) the same mechanisms for congestion control, etc., is it worthwhile for TCP mechanisms also to discuss their applicability for SCTP? My opinion is that they should. br, John > -----Original Message----- > From: ext Pasi.Sarolahti@nokia.com [mailto:Pasi.Sarolahti@nokia.com] > Sent: 19 March, 2003 00:14 > To: tsvwg@ietf.org > Subject: [Tsvwg] Spurious RTOs and SCTP > > > Hi, > > The recent discussions on this list regarding to spurious > RTOs have concerned only TCP, but shouldn't SCTP be > considered also, since it does RTO-based retransmissions as > well? I don't have any hands-on experience with SCTP, but it > seems like detecting spurious RTOs by using F-RTO-like logic > (see draft-sarolahti-tsvwg-tcp-frto-03.txt) applied to SCTP > TSNs and SACKs should work. Or is it a bad idea? I could > write a draftlet, but it would be nice to hear what folks > think of it before doing that. > > - Pasi > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 20 16:00:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06351 for ; Thu, 20 Mar 2003 16:00:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KLI1627527 for tsvwg-archive@odin.ietf.org; Thu, 20 Mar 2003 16:18:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KLHSO27474; Thu, 20 Mar 2003 16:17:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KLG3O27418 for ; Thu, 20 Mar 2003 16:16:03 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06235 for ; Thu, 20 Mar 2003 15:57:31 -0500 (EST) Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18w78b-000LZs-00; Thu, 20 Mar 2003 12:59:45 -0800 To: tsvwg@ietf.org Cc: mankin@psg.com, jon.peterson@neustar.biz Reply-To: mankin@psg.com Date: Thu, 20 Mar 2003 12:59:45 -0800 From: Allison Mankin Message-Id: Subject: [Tsvwg] updated agenda for TSVWG meeting Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Times slightly reduced on some talks and two small items added Transport Area Working Group (tsvwg) Thursday, March 20 at 1300-1500 ================================= CHAIRS: Allison Mankin Jon Peterson AGENDA: Brief intro - Chairs - 5 mins RSVP-change discussion draft-kompella-rsvp-change-00.txt - Kireeti Kompella - 5 mins. New task for tsvwg - to help the task of IETF keeping RSVP protocol registrations coherent. RSVP-localization - Jukka Manner - 10 mins. IP measurement OAM problem problem statement - John Bennett 10 mins TCP discussions, two returning and two new drafts: draft-floyd-tcp-highspeed-02.txt - Sally Floyd - 15 mins. draft-blanton-dsack-use-02.txt - Ethan Blanton - 5 mins. draft-blanton-tcp-reordering-00.txt - Ethan Blanton - 15 mins. draft-allman-tcp-early-rexmt-00.txt - Mark Allman - 15 mins. Proposal for newreno standardization - Sally Floyd - 5 mins. Redundant data in TCP? - Reiner Ludwig - 5 mins. SCTP discussion - thorough review of PR-SCTP draft-stewart-tsvwg-prsctp-03.txt - Randall Stewart - 25 mins. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 20 17:39:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10630 for ; Thu, 20 Mar 2003 17:39:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KMvbs03506 for tsvwg-archive@odin.ietf.org; Thu, 20 Mar 2003 17:57:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KMvFO03440; Thu, 20 Mar 2003 17:57:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KMZEO01773 for ; Thu, 20 Mar 2003 17:35:14 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10127 for ; Thu, 20 Mar 2003 17:16:40 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 67DCA328D0; Thu, 20 Mar 2003 17:18:56 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id A562E328A3; Thu, 20 Mar 2003 17:18:55 -0500 (EST) Date: Thu, 20 Mar 2003 17:18:55 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Cc: , Subject: RE: [Tsvwg] Spurious RTOs and SCTP In-Reply-To: Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Hi John! reply inline... On Thu, 20 Mar 2003 john.loughney@nokia.com wrote: > Actually, this brings up a more broad question - as SCTP and TCP > share (basically) the same mechanisms for congestion control, etc., > is it worthwhile for TCP mechanisms also to discuss their applicability > for SCTP? My opinion is that they should. I agree. What would be ideal is for new mechanisms to somehow abstract the problem and solution so that they can be applied to both protocols. It may not always be possible though, but at least a discussion of applicability to both protocols is useful. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 20 18:32:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14135 for ; Thu, 20 Mar 2003 18:32:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KNogP08343 for tsvwg-archive@odin.ietf.org; Thu, 20 Mar 2003 18:50:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KNoJO08327; Thu, 20 Mar 2003 18:50:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KNlSO08237 for ; Thu, 20 Mar 2003 18:47:28 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14046 for ; Thu, 20 Mar 2003 18:28:52 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2KNV8HQ026041 for ; Fri, 21 Mar 2003 00:31:08 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id HH5ML035; Fri, 21 Mar 2003 00:31:04 +0100 Received: from res0010384da36.eed.ericsson.se (rmt160232.am.ericsson.se [138.85.160.232]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id AAA25715 for ; Fri, 21 Mar 2003 00:30:55 +0100 (MET) Message-Id: <5.1.0.14.0.20030321002321.02879788@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 21 Mar 2003 00:30:52 +0100 To: tsvwg@ietf.org From: Reiner Ludwig Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Tsvwg] Adding Redundancy to TCP & SCTP? Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , here are the slides I presented at the meeting: http://www.cs.helsinki.fi/u/gurtov/reiner/TCP_FEC.pdf http://www.cs.helsinki.fi/u/gurtov/reiner/TCP_FEC.ppt (thanks to Andrei Gurtov for providing the web space) It would be nice to get some feedback from the community on the issue that is raised in the slides; in particular on these questions: The IETF Mandates Flows to be TCP-Friendly. Fine, but ... - For a Flow that is TCP-Friendly, can the IETF Further Mandate what "good" and "bad" Packets/Bytes are? - If yes, how? Quotas on Potentially Useless Packets/Bytes? ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 20 19:56:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16220 for ; Thu, 20 Mar 2003 19:56:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2L1EnI14179 for tsvwg-archive@odin.ietf.org; Thu, 20 Mar 2003 20:14:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L1EPO14166; Thu, 20 Mar 2003 20:14:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L1DlO14125 for ; Thu, 20 Mar 2003 20:13:47 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16177 for ; Thu, 20 Mar 2003 19:55:08 -0500 (EST) From: Pasi.Sarolahti@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2L0u0M15487 for ; Fri, 21 Mar 2003 02:56:00 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 21 Mar 2003 02:57:24 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Mar 2003 02:57:24 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Mar 2003 02:57:24 +0200 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Mar 2003 02:57:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Tsvwg] Spurious RTOs and SCTP Date: Fri, 21 Mar 2003 02:57:23 +0200 Message-ID: <7AB8A321754AC94E9D6753AB81439C2F10951C@esebe021.ntc.nokia.com> Thread-Topic: [Tsvwg] Spurious RTOs and SCTP Thread-Index: AcLvLrR328RpBm81Qfqd6mkip+3xsAADigYw To: , Cc: X-OriginalArrivalTime: 21 Mar 2003 00:57:23.0838 (UTC) FILETIME=[D57D79E0:01C2EF44] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2L1DlO14126 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > > Actually, this brings up a more broad question - as SCTP and TCP > > share (basically) the same mechanisms for congestion control, etc., > > is it worthwhile for TCP mechanisms also to discuss their > > applicability for SCTP? My opinion is that they should. > > I agree. What would be ideal is for new mechanisms to somehow > abstract the problem and solution so that they can be applied to both > protocols. It may not always be possible though, but at least a > discussion of applicability to both protocols is useful. I agree in general. But I see roughly three options: 1) Write the spec so that TCP and SCTP are handled side by side. This could make detailed algorithm descriptions pain, since TCP and SCTP have different set of variables and conventions. Additionally, SCTP has nice features such as SACKs and duplicate TSNs, which are optional in TCP and not always available. 2) Create a dedicated section for TCP and another section for SCTP in the same draft. 3) Have one small document for TCP and another for SCTP (if needed). I guess you meant something like (1) and John had something closer to (2) in mind? Considering our F-RTO draft, I feel (1) quite undesirable, as the algorithm description currently refers to TCP-specific parameters, and patching the algorithms with SCTP could be difficult to read. (2) & (3) would seem easier cases, of which I would favour (3), because I believe the TCP F-RTO is in pretty good shape, and I wouldn't want to delay it unnecessarily because of tweaking with the SCTP-side. Besides, it seems somewhat logical to me to have different documents for handling different transport protocols. However, I'd be happy to hear opinions on this. - Pasi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 21 03:08:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07450 for ; Fri, 21 Mar 2003 03:08:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2L8Qkx18296 for tsvwg-archive@odin.ietf.org; Fri, 21 Mar 2003 03:26:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L8QGO18284; Fri, 21 Mar 2003 03:26:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L8NPO18167 for ; Fri, 21 Mar 2003 03:23:25 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07424 for ; Fri, 21 Mar 2003 03:04:40 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 7854B328E0; Fri, 21 Mar 2003 03:06:56 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id BBD78328DF; Fri, 21 Mar 2003 03:06:55 -0500 (EST) Date: Fri, 21 Mar 2003 03:06:55 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Cc: , , Subject: RE: [Tsvwg] Spurious RTOs and SCTP In-Reply-To: <7AB8A321754AC94E9D6753AB81439C2F10951C@esebe021.ntc.nokia.com> Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Fri, 21 Mar 2003 Pasi.Sarolahti@nokia.com wrote: > I agree in general. But I see roughly three options: > > 1) Write the spec so that TCP and SCTP are handled side by side. This > could make detailed algorithm descriptions pain, since TCP and SCTP > have different set of variables and conventions. Additionally, SCTP > has nice features such as SACKs and duplicate TSNs, which are optional > in TCP and not always available. > 2) Create a dedicated section for TCP and another section for SCTP in > the same draft. > 3) Have one small document for TCP and another for SCTP (if needed). > > I guess you meant something like (1) and John had something closer to > (2) in mind? > > Considering our F-RTO draft, I feel (1) quite undesirable, as the > algorithm description currently refers to TCP-specific parameters, and > patching the algorithms with SCTP could be difficult to read. (2) & Actually, I had in mind a combination of (1) and (2). A draft can have the problem statement generic for the two transport protocols, and then dedicate a separate section for specific solutions for TCP and SCTP. > (3) would seem easier cases, of which I would favour (3), because I > believe the TCP F-RTO is in pretty good shape, and I wouldn't want to > delay it unnecessarily because of tweaking with the SCTP-side. > Besides, it seems somewhat logical to me to have different documents > for handling different transport protocols. I understand your point, but my concern is that we'll end up with some solutions for TCP and some for SCTP... when all or most solutions can be applied to both. Then someone has to go through a second pass and apply the TCP solutions to SCTP and vice-versa. If the solutions are drastically (or even moderately) different, maybe it makes more sense to have separate drafts. I think a good example of when both protocols can be addressed in one draft is when spurious rtxs need to be identified via duplicate tsn reports. TCP uses DSACKs and SCTP uses DupTSNs, but there is very little difference in the two. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 21 12:30:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19723 for ; Fri, 21 Mar 2003 12:30:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LHnGA22184 for tsvwg-archive@odin.ietf.org; Fri, 21 Mar 2003 12:49:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHmkO22089; Fri, 21 Mar 2003 12:48:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHecO21689 for ; Fri, 21 Mar 2003 12:40:38 -0500 Received: from thebe.your-site.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19439 for ; Fri, 21 Mar 2003 12:21:41 -0500 (EST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id B59492451C8; Fri, 21 Mar 2003 12:24:01 -0500 (EST) Date: Fri, 21 Mar 2003 11:25:53 -0600 From: Caitlin Bestler Subject: RE: [Tsvwg] Spurious RTOs and SCTP To: Pasi.Sarolahti@nokia.com Cc: acaro@acm.org, john.loughney@nokia.com, tsvwg@ietf.org X-Priority: 3 In-Reply-To: <7AB8A321754AC94E9D6753AB81439C2F10951C@esebe021.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 3/21/03, Pasi.Sarolahti@nokia.com wrote: >> > Actually, this brings up a more broad question - as SCTP and TCP >> > share (basically) the same mechanisms for congestion control, etc., >> > is it worthwhile for TCP mechanisms also to discuss their >> > applicability for SCTP? My opinion is that they should. >> >> I agree. What would be ideal is for new mechanisms to >> somehow abstract the problem and solution so that they >> can be applied to both protocols. It may not always be >> possible though, but at least a discussion of >> applicability to both protocols is useful. > >I agree in general. But I see roughly three options: > >1) Write the spec so that TCP and SCTP are handled side by >side. This could make detailed algorithm descriptions >pain, since TCP and SCTP have different set of variables >and conventions. Additionally, SCTP has nice features such >as SACKs and duplicate TSNs, which are optional in TCP and >not always available. >2) Create a dedicated section for TCP and another section for SCTP in the same draft. >3) Have one small document for TCP and another for SCTP (if needed). > Would it be feasible to define a single document which specified a set of transport neutral terms that would be compatible with TCP, TCP with SACKs, SCTP and DCP (and the mapping of those terms to each congestion controlling transport protocol)? That way new algorithms can be proposed once, and the mapping to each transport would be known. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 21 14:16:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23182 for ; Fri, 21 Mar 2003 14:16:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LJYiW30598 for tsvwg-archive@odin.ietf.org; Fri, 21 Mar 2003 14:34:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJYQO30565; Fri, 21 Mar 2003 14:34:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LJSnO30273 for ; Fri, 21 Mar 2003 14:28:49 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22933 for ; Fri, 21 Mar 2003 14:09:49 -0500 (EST) From: Pasi.Sarolahti@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2LJFku26848 for ; Fri, 21 Mar 2003 21:15:46 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 21 Mar 2003 21:12:10 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Mar 2003 21:12:04 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Mar 2003 21:12:04 +0200 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Mar 2003 21:12:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Tsvwg] Spurious RTOs and SCTP Date: Fri, 21 Mar 2003 21:12:02 +0200 Message-ID: <7AB8A321754AC94E9D6753AB81439C2F10951E@esebe021.ntc.nokia.com> Thread-Topic: [Tsvwg] Spurious RTOs and SCTP Thread-Index: AcLvzqn9Vn6H0zN9S/KGAOaOS9iJ9wADPV0g To: Cc: , , X-OriginalArrivalTime: 21 Mar 2003 19:12:03.0916 (UTC) FILETIME=[C1DE08C0:01C2EFDD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2LJSnO30274 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > Would it be feasible to define a single document which > specified a set of transport neutral terms that would be > compatible with TCP, TCP with SACKs, SCTP and DCP (and the > mapping of those terms to each congestion controlling > transport protocol)? > > That way new algorithms can be proposed once, and the > mapping to each transport would be known. That may turn out to be difficult. To give an example, TCP DSACK and SCTP dupTSN are not exactly the same. You don't know if the other TCP end point implements DSACK, so one cannot draw very strong conclusions from the lack of DSACK blocks. In SCTP, dupTSNs is mandatory (right?), so stronger algorithms can probably be implemented on top of that. - Pasi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sun Mar 23 22:00:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19584 for ; Sun, 23 Mar 2003 22:00:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2O3K5a16113 for tsvwg-archive@odin.ietf.org; Sun, 23 Mar 2003 22:20:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O3JcO16066; Sun, 23 Mar 2003 22:19:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O3IZO16028 for ; Sun, 23 Mar 2003 22:18:35 -0500 Received: from web10906.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19503 for ; Sun, 23 Mar 2003 21:58:27 -0500 (EST) Message-ID: <20030324030044.39437.qmail@web10906.mail.yahoo.com> Received: from [12.237.229.250] by web10906.mail.yahoo.com via HTTP; Sun, 23 Mar 2003 19:00:44 PST Date: Sun, 23 Mar 2003 19:00:44 -0800 (PST) From: Spencer Dawkins Subject: RE: [Tsvwg] Spurious RTOs and SCTP To: tsvwg@ietf.org In-Reply-To: <7AB8A321754AC94E9D6753AB81439C2F10951E@esebe021.ntc.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At the Triggers for Transport BoF at IETF 56, Allison Mankin asked Carl Williams and I to propose a charter which included "link up" notification, and a suggested response function. Of course, the response function (at this time) must be specified for at least two or three transports. I'm just pointing out that we'd ALSO like to see a single document with these transport mechanisms, because it would make TRIGTRAN a HECKUVA lot easier for us to knock out. And I believe Pasi about a single specification being difficult - the problem is, having a bunch of per-transport specifications just spreads the work around for anyone who's trying to work on transport-independent mechanisms... Spencer, who believes Mark Allman when Mark says it's unfortunate that we didn't get traction with ECM... --- Pasi.Sarolahti@nokia.com wrote: > > Would it be feasible to define a single document which > > specified a set of transport neutral terms that would be > > compatible with TCP, TCP with SACKs, SCTP and DCP (and the > > mapping of those terms to each congestion controlling > > transport protocol)? > > > > That way new algorithms can be proposed once, and the > > mapping to each transport would be known. > > That may turn out to be difficult. To give an example, TCP > DSACK and SCTP dupTSN are not exactly the same. You don't know > if the other TCP end point implements DSACK, so one cannot > draw very strong conclusions from the lack of DSACK blocks. In > SCTP, dupTSNs is mandatory (right?), so stronger algorithms > can probably be implemented on top of that. > > - Pasi __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 24 19:21:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10889 for ; Mon, 24 Mar 2003 19:21:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P0feE14934 for tsvwg-archive@odin.ietf.org; Mon, 24 Mar 2003 19:41:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0fMO14921; Mon, 24 Mar 2003 19:41:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0emO14897 for ; Mon, 24 Mar 2003 19:40:48 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10873 for ; Mon, 24 Mar 2003 19:20:15 -0500 (EST) From: Yogesh.Swami@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2P0MXs06095 for ; Mon, 24 Mar 2003 18:22:33 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 24 Mar 2003 18:22:33 -0600 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 24 Mar 2003 18:22:33 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Mon, 24 Mar 2003 18:22:33 -0600 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE016E8009@daebe004.americas.nokia.com> Thread-Topic: RFC status in popular OSes Thread-Index: AcLyZKCAI1xaqrqxQQOZU3qeFLQ8Bg== To: X-OriginalArrivalTime: 25 Mar 2003 00:22:33.0541 (UTC) FILETIME=[A13A7750:01C2F264] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2P0emO14898 Subject: [Tsvwg] RFC status in popular OSes Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, Does anybody know which all TCP related RFCs are implemented in Windows 98/2000/XP. The same for Solaris, and HP? --Yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 25 06:02:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06305 for ; Tue, 25 Mar 2003 06:02:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PBNAd03156 for tsvwg-archive@odin.ietf.org; Tue, 25 Mar 2003 06:23:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PBMdO03141; Tue, 25 Mar 2003 06:22:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PBLTO03107 for ; Tue, 25 Mar 2003 06:21:29 -0500 Received: from c.psc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06256 for ; Tue, 25 Mar 2003 06:00:42 -0500 (EST) Received: by c.psc.edu; Tue, 25 Mar 2003 6:02:59 -0500 Date: Tue, 25 Mar 2003 6:02:59 -0500 From: "Raghurama 'REDDY'" Reply-To: rreddy@psc.edu To: Yogesh.Swami@nokia.com CC: TSVWG@ietf.org Message-Id: <03032506025977.2320613b.2463217@psc.edu> Subject: RE: [Tsvwg] RFC status in popular OSes Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Yougesh, This document may be helpful (starting on page 4) for Windows OS: http://rdweb.cns.vt.edu/public/notes/tcpip2000.pdf This link was found in: http://rdweb.cns.vt.edu/public/notes/win2k-tcpip.htm which also has a link to an MS website. Hope this helps! --rr From: SMTP%"Yogesh.Swami@nokia.com" 24-MAR-2003 19:23:43.96 To: tsvwg@ietf.org CC: Subj: [Tsvwg] RFC status in popular OSes Hi, Does anybody know which all TCP related RFCs are implemented in Windows 98/2000/XP. The same for Solaris, and HP? --Yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 25 17:39:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07461 for ; Tue, 25 Mar 2003 17:39:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PN0Av23732 for tsvwg-archive@odin.ietf.org; Tue, 25 Mar 2003 18:00:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMxpO23686; Tue, 25 Mar 2003 17:59:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMl1O23039 for ; Tue, 25 Mar 2003 17:47:01 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07102 for ; Tue, 25 Mar 2003 17:26:00 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2PMSJHQ022664; Tue, 25 Mar 2003 23:28:19 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id HK1VCG9V; Tue, 25 Mar 2003 23:28:19 +0100 Received: from res0010384da36.eed.ericsson.se (rac182pc.edd.ericsson.se [164.48.123.182]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id XAA25131; Tue, 25 Mar 2003 23:28:17 +0100 (MET) Message-Id: <5.1.0.14.0.20030325221003.00aa6300@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Mar 2003 23:22:46 +0100 To: tsvwg@ietf.org From: Reiner Ludwig Cc: Phil Karn Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Tsvwg] Rethinking Karn's algorithm Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , instead of an explicit out-of-band "Link Up"-Trigger to jump-start a TCP sender that is stuck with a backed-off RTO, we could also rethink Karn's algorithm ... The motivation for the backoff of the RTO is to eventually "catch" a valid RTT timing which - according to Karn's algorithm - should not be taken from data segments that had been retransmitted (retransmission ambiguity). But: 1. With timestamps, we can also take valid RTTs from retransmitted segments. 2. Without timestamps and a timeout for segment N, we could delay making the RTO more conservative until the ACK for N is received. According to Karn's algorithm we should not take an RTT for segment N, anyway. What really matters is that the RTO has been made more conservative when segment N+1 is sent. The question of how the RTO is made more conservative is a separate issue. Probably different alternatives exist. Either way, we could allow the TCP sender to retransmit the oldest outstanding segment every RTO, i.e., without backoff! There might be an (academic?) issue with persistent congestion, although that was not a consideration in Karn's SIGCOMM '87 paper. Still, sending one packet every RTO (without backoff) seems sufficiently conservative. Anyway, backing off to ultimately 64 seconds seems far too conservative. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Mar 25 19:04:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12274 for ; Tue, 25 Mar 2003 19:04:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q0OcD30728 for tsvwg-archive@odin.ietf.org; Tue, 25 Mar 2003 19:24:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q0OKO30713; Tue, 25 Mar 2003 19:24:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q0NoO30656 for ; Tue, 25 Mar 2003 19:23:50 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12233 for ; Tue, 25 Mar 2003 19:02:47 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 7D85132925; Tue, 25 Mar 2003 19:05:05 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 9F6E63288F; Tue, 25 Mar 2003 19:05:04 -0500 (EST) Date: Tue, 25 Mar 2003 19:05:04 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Reiner Ludwig Cc: , Phil Karn Subject: Re: [Tsvwg] Rethinking Karn's algorithm In-Reply-To: <5.1.0.14.0.20030325221003.00aa6300@mailhost.eed.ericsson.se> Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Tue, 25 Mar 2003, Reiner Ludwig wrote: > instead of an explicit out-of-band "Link Up"-Trigger to jump-start a TCP > sender that is stuck with a backed-off RTO, we could also rethink Karn's > algorithm ... > > The motivation for the backoff of the RTO is to eventually "catch" a valid > RTT timing which - according to Karn's algorithm - should not be taken from > data segments that had been retransmitted (retransmission ambiguity). > > But: > 1. With timestamps, we can also take valid RTTs from retransmitted segments. > 2. Without timestamps and a timeout for segment N, we could delay making > the RTO more conservative until the ACK for N is received. According to > Karn's algorithm we should not take an RTT for segment N, anyway. What > really matters is that the RTO has been made more conservative when > segment N+1 is sent. The question of how the RTO is made more conservative > is a separate issue. Probably different alternatives exist. Yes I agree. Although the motivation is different... We have investigated using Timestamps in SCTP for obtaining a more accurate RTT estimate of alternate destination paths. In SCTP, the alternate destinations are used only for retransmissions (and heartbeats). Hence, the RTO of the alternate destinations generally are more conservative than necessary... reducing throughput of the association. We found that using Timestamps significantly improves performance simply because more RTT measurements are obtained for the alternate destinations, and thus the RTOs are more accurate. The motivation for and a BRIEF description of the SCTP TIMESTAMP Chunk is in the following paper: Transport Layer Multihoming For Fault Tolerance In FCS Networks Armando L. Caro Jr., Paul D. Amer, Randall R. Stewart CTA 2003, April 2003 www.cis.udel.edu/~acaro/papers We are currently writing the paper which presents the results. The paper should be available in a couple of weeks. > Either way, we could allow the TCP sender to retransmit the oldest > outstanding segment every RTO, i.e., without backoff! > > There might be an (academic?) issue with persistent congestion, although > that was not a consideration in Karn's SIGCOMM '87 paper. Still, sending > one packet every RTO (without backoff) seems sufficiently conservative. > Anyway, backing off to ultimately 64 seconds seems far too conservative. I agree that 64 seconds (60 secs with SCTP) is much too conservative. However, I don't understand why you think multiple RTOs without backoff is ok or even conservative. I think I am missing something here... If the timeout occurs because the RTO is too small, how will the sender know to increase the RTO? ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 27 07:11:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24456 for ; Thu, 27 Mar 2003 07:11:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RCWPS11577 for tsvwg-archive@odin.ietf.org; Thu, 27 Mar 2003 07:32:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RCVtO11540; Thu, 27 Mar 2003 07:31:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RCS9O11388 for ; Thu, 27 Mar 2003 07:28:09 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24314 for ; Thu, 27 Mar 2003 07:06:22 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2RC8fbh020498; Thu, 27 Mar 2003 13:08:42 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id HKFYFH4T; Thu, 27 Mar 2003 13:08:39 +0100 Received: from res0010384da36.eed.ericsson.se (dhcp5-197.eed.ericsson.se [164.48.135.197]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id NAA18664; Thu, 27 Mar 2003 13:08:36 +0100 (MET) Message-Id: <5.1.0.14.0.20030327124629.00aada08@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 Mar 2003 13:08:14 +0100 To: "Armando L. Caro Jr." From: Reiner Ludwig Subject: Re: [Tsvwg] Rethinking Karn's algorithm Cc: tsvwg@ietf.org, Phil Karn In-Reply-To: References: <5.1.0.14.0.20030325221003.00aa6300@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 01:05 26.03.2003, Armando L. Caro Jr. wrote: > > Either way, we could allow the TCP sender to retransmit the oldest > > outstanding segment every RTO, i.e., without backoff! > > > > There might be an (academic?) issue with persistent congestion, although > > that was not a consideration in Karn's SIGCOMM '87 paper. Still, sending > > one packet every RTO (without backoff) seems sufficiently conservative. > > Anyway, backing off to ultimately 64 seconds seems far too conservative. > >I agree that 64 seconds (60 secs with SCTP) is much too conservative. >However, I don't understand why you think multiple RTOs without backoff is >ok or even conservative. I think I am missing something here... I didn't mean conservative in terms of adapting the RTO to a potentially increased RTT, but conservative in terms of impact on the congestion state in the network. For a potentially severly congested bottleneck, having the end-points send one packet per RTO seems sufficiently conservative. I.e., every router in today's Internet should at least be able to handle a certain peak number of flows (depending on some worst case traffic estimate for that location in the topology) each sending with a minimum rate of one packet per RTO. I guess the times when LANs where interconnected by slow dial-up connections are long gone ... and if they still exist then they certainly don't pose a threat to the stability of the (public) Internet. >If the >timeout occurs because the RTO is too small, If that was the reason for the timeout, it is quite likely that the ACK for the retransmitted segment will arrive shortly after the RTO, and even more likely before a second timeout with a non-backed-off RTO. >how will the sender know [how] to >increase the RTO? I guess several options exist. One option would be to allow timing of retransmitted segments even without timestamps by taking as the RTT the time between sending the original segment and the receipt of the ACK, independent of whether that ACK was triggered by the original or some retransmit. Alternatively, with the current retransmission timer [RFC2988] we could require that when timestamps are not used then SRTT should be doubled once the ACK for oldest outstanding segment arrives after a timeout. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 27 11:05:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04988 for ; Thu, 27 Mar 2003 11:05:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RGQb528512 for tsvwg-archive@odin.ietf.org; Thu, 27 Mar 2003 11:26:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RGPfO28486; Thu, 27 Mar 2003 11:25:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RGGqO28078 for ; Thu, 27 Mar 2003 11:16:52 -0500 Received: from web14809.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04707 for ; Thu, 27 Mar 2003 10:55:01 -0500 (EST) Message-ID: <20030327155722.78041.qmail@web14809.mail.yahoo.com> Received: from [65.213.193.49] by web14809.mail.yahoo.com via HTTP; Thu, 27 Mar 2003 07:57:22 PST Date: Thu, 27 Mar 2003 07:57:22 -0800 (PST) From: CAITR Reply-To: info@caitr.org To: tsvwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1938616965-1048780642=:76096" Subject: [Tsvwg] Internetworking 2003: Call for Papers Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --0-1938616965-1048780642=:76096 Content-Type: text/plain; charset=us-ascii Dear Colleagues: Our sincere apologies if you receive multiple copies of this announcement. CONFERENCE ANNOUNCEMENT AND CALL FOR PRESENTATIONS Internetworking 2003 June 22-24, 2003 San Jose, California In technical cooperation with IEEE, IFIP, and ACM (Pending) Internetworking 2003 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following: - Voice over IP (VoIP) - IP Video Conferencing - Storage Area Networks (SANs) - Unicast and Multicast Routing and Convergence - QoS Routing - Network Security and Service Integration - Operational Support Systems - Virtual Private Networks - Internetworking Wireless LANs and 3G Wireless Networks - IP-based Infrastructure for Wireless Networks - Internetworking IP and Optical Networks - Internetworking MPLS with Legacy ATM and Frame Relay Networks - Transition from IPv4 to IPv6 and interworking - Pervasive Computing - High Speed Transport Layer Protocols - Peer to Peer Networking and Grid Computing - Video Teleconferencing (VTC) - 802.11 Hotspots The Internetworking 2003 event in June will include participation from industry, government agencies, and academia. If you need additional technical information, please contact the Technical Cochairs Professor Maurice GAGNAIRE , or Daniel Awduche . --0-1938616965-1048780642=:76096 Content-Type: text/html; charset=us-ascii

Dear Colleagues:

Our sincere apologies if you receive multiple copies of this announcement.

     CONFERENCE ANNOUNCEMENT AND CALL FOR PRESENTATIONS

                   Internetworking 2003
                      June 22-24, 2003
                   San Jose, California
      In technical cooperation with IEEE, IFIP, and ACM (Pending)


Internetworking 2003 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following:

- Voice over IP (VoIP)
- IP Video Conferencing
- Storage Area Networks (SANs)
- Unicast and Multicast Routing and Convergence
- QoS Routing
- Network Security and Service Integration
- Operational Support Systems
- Virtual Private Networks
- Internetworking Wireless LANs and 3G Wireless Networks
- IP-based Infrastructure for Wireless Networks
- Internetworking IP and Optical Networks
- Internetworking MPLS with Legacy ATM and Frame Relay Networks
- Transition from IPv4 to IPv6 and interworking
- Pervasive Computing
- High Speed Transport Layer Protocols
- Peer to Peer Networking and Grid Computing
- Video Teleconferencing (VTC)
- 802.11 Hotspots


The Internetworking 2003 event in June will include participation from industry, government agencies, and academia. If you need additional technical information, please contact the Technical Cochairs Professor Maurice GAGNAIRE <gagnaire@enst.fr>, or Daniel Awduche <Awduche@awduche.com>.

--0-1938616965-1048780642=:76096-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 27 13:39:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11723 for ; Thu, 27 Mar 2003 13:39:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RJ17209747 for tsvwg-archive@odin.ietf.org; Thu, 27 Mar 2003 14:01:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RJ0dO09702; Thu, 27 Mar 2003 14:00:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RIw1O09561 for ; Thu, 27 Mar 2003 13:58:01 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11618 for ; Thu, 27 Mar 2003 13:36:06 -0500 (EST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 38C84328CA; Thu, 27 Mar 2003 13:38:23 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 7226A328B9; Thu, 27 Mar 2003 13:38:22 -0500 (EST) Date: Thu, 27 Mar 2003 13:38:22 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Reiner Ludwig Cc: , Phil Karn Subject: Re: [Tsvwg] Rethinking Karn's algorithm In-Reply-To: <5.1.0.14.0.20030327124629.00aada08@mailhost.eed.ericsson.se> Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Reiner, Thanks for the clarification... I like this idea. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 On Thu, 27 Mar 2003, Reiner Ludwig wrote: > At 01:05 26.03.2003, Armando L. Caro Jr. wrote: > > > Either way, we could allow the TCP sender to retransmit the oldest > > > outstanding segment every RTO, i.e., without backoff! > > > > > > There might be an (academic?) issue with persistent congestion, although > > > that was not a consideration in Karn's SIGCOMM '87 paper. Still, sending > > > one packet every RTO (without backoff) seems sufficiently conservative. > > > Anyway, backing off to ultimately 64 seconds seems far too conservative. > > > >I agree that 64 seconds (60 secs with SCTP) is much too conservative. > >However, I don't understand why you think multiple RTOs without backoff is > >ok or even conservative. I think I am missing something here... > > I didn't mean conservative in terms of adapting the RTO to a potentially > increased RTT, but conservative in terms of impact on the congestion state > in the network. > For a potentially severly congested bottleneck, having the end-points send > one packet per RTO seems sufficiently conservative. I.e., every router in > today's Internet should at least be able to handle a certain peak number of > flows (depending on some worst case traffic estimate for that location in > the topology) each sending with a minimum rate of one packet per RTO. > > I guess the times when LANs where interconnected by slow dial-up > connections are long gone ... and if they still exist then they certainly > don't pose a threat to the stability of the (public) Internet. > > > >If the > >timeout occurs because the RTO is too small, > > If that was the reason for the timeout, it is quite likely that the ACK for > the retransmitted segment will arrive shortly after the RTO, and even more > likely before a second timeout with a non-backed-off RTO. > > > >how will the sender know [how] to > >increase the RTO? > > I guess several options exist. One option would be to allow timing of > retransmitted segments even without timestamps by taking as the RTT the > time between sending the original segment and the receipt of the ACK, > independent of whether that ACK was triggered by the original or some > retransmit. Alternatively, with the current retransmission timer [RFC2988] > we could require that when timestamps are not used then SRTT should be > doubled once the ACK for oldest outstanding segment arrives after a timeout. > > ///Reiner > > > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Mar 27 16:14:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19570 for ; Thu, 27 Mar 2003 16:14:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RLZrg22516 for tsvwg-archive@odin.ietf.org; Thu, 27 Mar 2003 16:35:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RLTYO22105; Thu, 27 Mar 2003 16:29:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RLRIO21905 for ; Thu, 27 Mar 2003 16:27:18 -0500 Received: from seraph3.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19084 for ; Thu, 27 Mar 2003 16:05:19 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 6C7506BA8D for ; Thu, 27 Mar 2003 16:07:42 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h2RL7N7h009572; Thu, 27 Mar 2003 16:07:37 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id QAA12359; Thu, 27 Mar 2003 16:07:23 -0500 (EST) Message-Id: <200303272107.QAA12359@guns.lerc.nasa.gov> To: Reiner Ludwig From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org, Phil Karn Subject: Re: [Tsvwg] Rethinking Karn's algorithm In-Reply-To: <5.1.0.14.0.20030325221003.00aa6300@mailhost.eed.ericsson.se> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Cheap Sunglasses Date: Thu, 27 Mar 2003 16:07:22 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , I don't follow this at all... > The motivation for the backoff of the RTO is to eventually "catch" > a valid RTT timing which - according to Karn's algorithm - should > not be taken from data segments that had been retransmitted > (retransmission ambiguity). > > [...] > > There might be an (academic?) issue with persistent congestion, > although that was not a consideration in Karn's SIGCOMM '87 paper. The Karn and Partridge paper was about managing the RTO estimator and timer. The 1988 Jacobson paper motivated the backoff in terms of congestion control: "Another timer mistake is in the backoff after a retransmit: If a packet has to be retransmitted more than once, how should the retransmits be spaced? For a transport endpoint embedded in a network of unknown topology and with an unknown, unknowable and constantly changing population of competing conversations, only one scheme has any hope of working---exponential backoff" My own intuition says that backoff is simply continuing the notion of halving the sending rate that drives the cwnd adjustments. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 28 03:39:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20951 for ; Fri, 28 Mar 2003 03:39:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2S91IB17321 for tsvwg-archive@odin.ietf.org; Fri, 28 Mar 2003 04:01:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S90hO17259; Fri, 28 Mar 2003 04:00:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S8xkO17177 for ; Fri, 28 Mar 2003 03:59:46 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20885 for ; Fri, 28 Mar 2003 03:37:33 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2S8drbh000850; Fri, 28 Mar 2003 09:39:53 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id HKFYNGSN; Fri, 28 Mar 2003 09:39:53 +0100 Received: from res0010384da36.eed.ericsson.se (dhcp5-197.eed.ericsson.se [164.48.135.197]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id JAA14560; Fri, 28 Mar 2003 09:39:52 +0100 (MET) Message-Id: <5.2.0.9.0.20030328091141.00b11d80@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Mar 2003 09:39:54 +0100 To: mallman@grc.nasa.gov From: Reiner Ludwig Subject: Re: [Tsvwg] Rethinking Karn's algorithm Cc: tsvwg@ietf.org, Phil Karn In-Reply-To: <200303272107.QAA12359@guns.lerc.nasa.gov> References: <5.1.0.14.0.20030325221003.00aa6300@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 22:07 27.03.2003, Mark Allman wrote: >The Karn and Partridge paper was about managing the RTO estimator >and timer. The 1988 Jacobson paper motivated the backoff in terms >of congestion control: > > "Another timer mistake is in the backoff after a retransmit: If > a packet has to be retransmitted more than once, how should the > retransmits be spaced? For a transport endpoint embedded in a > network of unknown topology and with an unknown, unknowable and > constantly changing population of competing conversations, only > one scheme has any hope of working---exponential backoff" > >My own intuition says that backoff is simply continuing the notion >of halving the sending rate that drives the cwnd adjustments. I definitely believe that this was the right approach for the Internet some 15 years ago. At that time the Internet was really a collection of LANs interconnected by slow dial-up lines (potentially even only semi-permanent). But today's Internet looks different. For example, quoting from ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-iab-research-funding-00.txt: "One of the factors that has blunted the demand for QoS has been the transition of the Internet infrastructure from heavy congestion in the early 1990s, to overprovisioning in backbones and in many international links now." So, in general I strongly believe that we have to ask ourselves - and not only with respect to Karn's algorithm - whether we still need to be so ultra-conservative with end-point algorithms. Concerning Karn's algorithm, I'm not advocating "retransmit every non-backed-off RTO forever". We do not want to see the Internet poluted with a bunch of half-broken TCP connections that would do that. But, there are certainly different alternatives. For example, a TCP sender could retransmit every non-backed-off RTO for the first 30 seconds, every 2xRTO for the following 60 seconds, every 4xRTO for the following 120 seconds, etc. until the sending application gives up, or after some upper bound R2 as defined in RFC1122. That is also an exponential backoff. ///Reiner PS.: Apart from Karn's algorithm, I even believe that with the current economics behind the operation of today's (best-effort) Internet, it should be possible to allow end-points a minimum send rate (e.g., 5 kb/s) as long as they get receiver feedback every N RTTs. I think that this is needed if we are serious about wide-scale deployment of decent-quality services like streaming and VoIP over best-effort. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 28 09:19:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29269 for ; Fri, 28 Mar 2003 09:19:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SEfBD08198 for tsvwg-archive@odin.ietf.org; Fri, 28 Mar 2003 09:41:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SEefO08176; Fri, 28 Mar 2003 09:40:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SEdFO08106 for ; Fri, 28 Mar 2003 09:39:15 -0500 Received: from seraph2.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29219 for ; Fri, 28 Mar 2003 09:16:57 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id A7A7D68A07 for ; Fri, 28 Mar 2003 09:19:19 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h2SEJG7h010432; Fri, 28 Mar 2003 09:19:16 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id JAA21327; Fri, 28 Mar 2003 09:19:16 -0500 (EST) Message-Id: <200303281419.JAA21327@guns.lerc.nasa.gov> To: Reiner Ludwig Cc: tsvwg@ietf.org, Phil Karn From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: Re: [Tsvwg] Rethinking Karn's algorithm In-Reply-To: <5.2.0.9.0.20030328091141.00b11d80@mailhost.eed.ericsson.se> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Hey Jealousy Date: Fri, 28 Mar 2003 09:19:16 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > So, in general I strongly believe that we have to ask ourselves - > and not only with respect to Karn's algorithm - whether we still > need to be so ultra-conservative with end-point algorithms. That's a fine question and a fertile area for research maybe. But, I'll disagree quite strongly that anything like this is ready for the IETF. I don't think you have made the case that the RTO should be the lower bound on the sending rate. An RTO of 30 or 60 seconds doesn't "just happen"; rather it takes lots of repeated losses to make it happen. Clearly, in that environment you have a network that is badly busted in some way (which you have direct evidence of). I don't understand the motivation in being terribly aggressive in this situation. (And, I am still firmly in the camp that says that the RTO should be the last resort for loss repair and we should continue to refine other mechanisms to avoid RTOs. And, if we can largely do that then I don't much care how conservative the RTO is.) allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 28 11:38:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06511 for ; Fri, 28 Mar 2003 11:38:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SH0GB19438 for tsvwg-archive@odin.ietf.org; Fri, 28 Mar 2003 12:00:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SGxrO19374; Fri, 28 Mar 2003 11:59:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SGwiO19258 for ; Fri, 28 Mar 2003 11:58:44 -0500 Received: from moutng.kundenserver.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06408; Fri, 28 Mar 2003 11:36:21 -0500 (EST) Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 18ywsP-00015P-00; Fri, 28 Mar 2003 17:38:45 +0100 Received: from [217.231.234.146] (helo=hp001323) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 18ywsO-0004eR-00; Fri, 28 Mar 2003 17:38:44 +0100 Message-ID: <00ce01c2f549$f7addea0$0200a8c0@hp001323> From: "Heinz Prantner" To: , , References: Date: Fri, 28 Mar 2003 17:49:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Re: [Sigtran] New e-mail address Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit actually , this reminds me on something - for those of you I had the chance to meet on several occasions : me too, can be reached on a new address: heinz.prantner@onlinehome.de kind regards, Heinz ----- Original Message ----- From: "Tuexen Michael" To: ; ; Sent: Friday, March 28, 2003 2:37 PM Subject: [Sigtran] New e-mail address > Dear all, > > my Siemens e-mail address will no longer work. > Please use > > tuexen@fh-muenster.de > > in case you want to contact me. > > Best regards > Michael > > Michael Tuexen Tel.: +49 89 722 47210 > Siemens AG Fax: +49 89 722 48212 > ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Mar 28 13:02:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10182 for ; Fri, 28 Mar 2003 13:02:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SIOh426645 for tsvwg-archive@odin.ietf.org; Fri, 28 Mar 2003 13:24:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SIONO26627; Fri, 28 Mar 2003 13:24:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SIMIO26571 for ; Fri, 28 Mar 2003 13:22:18 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10088 for ; Fri, 28 Mar 2003 12:59:55 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2SI0lU19536 for ; Fri, 28 Mar 2003 20:00:47 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 28 Mar 2003 20:02:13 +0200 Received: from danh02-nrcws56.americas.nokia.com ([172.19.62.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 28 Mar 2003 20:02:14 +0200 From: Yogesh Prem Swami To: tsvwg@ietf.org Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1048874532.23674.28.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 28 Mar 2003 12:02:12 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Mar 2003 18:02:14.0907 (UTC) FILETIME=[29EA3CB0:01C2F554] Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Lightweight mobility detection and response algorithm Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, We've submitted a new draft "Lightweight mobility detection and response algorithm for TCP," which will become available in a couple of days from IETF web site. The draft is also available from http://people.nokia.net/~yogesh/draft-swami-tcp-lmdr-00.txt This draft allows a TCP host to propagate its subnet change information to its peer and specifies the congestion response that the peer must follow subsequent to such a change. The draft uses one of the bits from the reserved bits field of TCP header. We would like to have feedback from the working group on whether we should define a TCP option instead of using this bit. The pros and cons of the two approach have been identified in the draft. The mechanism is secure to the extent to sequence number guessing (i.e., as secure as any other TCP mechanism), but we can make it more secure (without using any key exchange protocol) if the working group demands it (it won't be free of cost in terms of number of bytes carried in each packet). Any comment, criticism, words of advice, ... are very welcome. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 31 04:30:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00175 for ; Mon, 31 Mar 2003 04:30:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2V9rUQ21384 for tsvwg-archive@odin.ietf.org; Mon, 31 Mar 2003 04:53:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V9qoO21363; Mon, 31 Mar 2003 04:52:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V9prO21332 for ; Mon, 31 Mar 2003 04:51:53 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00166 for ; Mon, 31 Mar 2003 04:28:10 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2V9UXUE000730; Mon, 31 Mar 2003 11:30:33 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2AG4JNKD; Mon, 31 Mar 2003 11:30:34 +0200 Received: from res0010384da36.eed.ericsson.se (dhcp5-197.eed.ericsson.se [164.48.135.197]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id LAA28975; Mon, 31 Mar 2003 11:30:32 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030331111450.00b0a2e8@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 31 Mar 2003 11:30:34 +0200 To: mallman@grc.nasa.gov From: Reiner Ludwig Subject: Re: [Tsvwg] Rethinking Karn's algorithm Cc: tsvwg@ietf.org, Phil Karn In-Reply-To: <200303281419.JAA21327@guns.lerc.nasa.gov> References: <5.2.0.9.0.20030328091141.00b11d80@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 16:19 28.03.2003, Mark Allman wrote: > > So, in general I strongly believe that we have to ask ourselves - > > and not only with respect to Karn's algorithm - whether we still > > need to be so ultra-conservative with end-point algorithms. > >That's a fine question and a fertile area for research maybe. But, >I'll disagree quite strongly that anything like this is ready for >the IETF. > >I don't think you have made the case that the RTO should be the >lower bound on the sending rate. An RTO of 30 or 60 seconds doesn't >"just happen"; rather it takes lots of repeated losses to make it >happen. Clearly, in that environment you have a network that is >badly busted in some way (which you have direct evidence of). I >don't understand the motivation in being terribly aggressive in this >situation. There is certainly a broad range for viable solutions between "terribly aggressive" and "ultra-conservative". If you think that "Rethinking Karn's algorithm" to make it less conservative in *some* way is not ready for the IETF, I wonder about your view on an explicit out-of-band "Link Up"-Trigger. How ready is that for the IETF? I mean, *the least* we could do is to discuss a new upper bound for the RTO back-off. What's the motivation for the current upper bound of 60 seconds? ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 31 07:19:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04316 for ; Mon, 31 Mar 2003 07:19:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VCgxZ31855 for tsvwg-archive@odin.ietf.org; Mon, 31 Mar 2003 07:42:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VCgWO31845; Mon, 31 Mar 2003 07:42:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VCfsO31821 for ; Mon, 31 Mar 2003 07:41:54 -0500 Received: from pop-3.dnv.wideopenwest.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04310 for ; Mon, 31 Mar 2003 07:18:10 -0500 (EST) Received: from thoth.ir.bbn.com (d53-66-209.clv.wideopenwest.com [64.53.209.66]) by pop-3.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h2VCiQY32143; Mon, 31 Mar 2003 06:44:26 -0600 Received: from thoth.ir.bbn.com (localhost [127.0.0.1]) by thoth.ir.bbn.com (8.12.6/8.12.6) with ESMTP id h2VCS5qH021100; Mon, 31 Mar 2003 07:28:06 -0500 (EST) (envelope-from mallman@thoth.ir.bbn.com) Message-Id: <200303311228.h2VCS5qH021100@thoth.ir.bbn.com> To: Reiner Ludwig From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: tsvwg@ietf.org, Phil Karn Subject: Re: [Tsvwg] Rethinking Karn's algorithm In-Reply-To: <5.2.0.9.0.20030331111450.00b0a2e8@mailhost.eed.ericsson.se> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Hey Jealousy Date: Mon, 31 Mar 2003 07:28:05 -0500 X-RAVMilter-Version: 8.4.1(snapshot 20020919) (pop-3.dnv.wideopenwest.com) Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > If you think that "Rethinking Karn's algorithm" to make it less > conservative in *some* way is not ready for the IETF, I wonder > about your view on an explicit out-of-band "Link Up"-Trigger. How > ready is that for the IETF? It's a decent question. Personally, I think it's OK. I think we can craft a transport-level response to be reasonable when receiving explicit information from the network. On the other hand, the RTO backoff is done in the abscence of any information. > I mean, *the least* we could do is to discuss a new upper bound > for the RTO back-off. What's the motivation for the current upper > bound of 60 seconds? ?? The only thing I have to say about this is that the current maximum is of the right order of magnitude, I think. Trying to optimize the value after that is dubious, I think. (That is, I believe it should be conservative. And, if it is then that means that it will be gross in some situations.) If we can get explicit information to cut a very long backoff down then maybe that is OK. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 31 07:56:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05221 for ; Mon, 31 Mar 2003 07:56:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VDJqd01583 for tsvwg-archive@odin.ietf.org; Mon, 31 Mar 2003 08:19:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VDJLO01554; Mon, 31 Mar 2003 08:19:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VDIcO01530 for ; Mon, 31 Mar 2003 08:18:38 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05183 for ; Mon, 31 Mar 2003 07:54:53 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2VCvGUE007155; Mon, 31 Mar 2003 14:57:16 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2AGQ506C; Mon, 31 Mar 2003 14:57:16 +0200 Received: from res0010384da36.eed.ericsson.se (dhcp5-197.eed.ericsson.se [164.48.135.197]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id OAA10931; Mon, 31 Mar 2003 14:57:14 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030331143603.025d98e8@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 31 Mar 2003 14:56:15 +0200 To: mallman@grc.nasa.gov From: Reiner Ludwig Subject: Re: [Tsvwg] Rethinking Karn's algorithm Cc: tsvwg@ietf.org, Phil Karn In-Reply-To: <200303311228.h2VCS5qH021100@thoth.ir.bbn.com> References: <5.2.0.9.0.20030331111450.00b0a2e8@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 14:28 31.03.2003, Mark Allman wrote: > > If you think that "Rethinking Karn's algorithm" to make it less > > conservative in *some* way is not ready for the IETF, I wonder > > about your view on an explicit out-of-band "Link Up"-Trigger. How > > ready is that for the IETF? > >It's a decent question. Personally, I think it's OK. I think we >can craft a transport-level response to be reasonable when receiving >explicit information from the network. With a less conservative version of Karn's algorithm, we would instead have a true end-to-end solution to the problem. That is, with a few changed lines of TCP sender code (or even only a single '#define') we would save the IETF extra work (a TRIGTRAN WG), and would avoid the deployment issues associated with "Link Up"-Triggers & corresponding TCP sender responses. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 31 08:09:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05461 for ; Mon, 31 Mar 2003 08:09:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VDWsx02150 for tsvwg-archive@odin.ietf.org; Mon, 31 Mar 2003 08:32:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VDW6O02115; Mon, 31 Mar 2003 08:32:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VDV9O02055 for ; Mon, 31 Mar 2003 08:31:09 -0500 Received: from pop-3.dnv.wideopenwest.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05419 for ; Mon, 31 Mar 2003 08:07:24 -0500 (EST) Received: from thoth.ir.bbn.com (d53-66-209.clv.wideopenwest.com [64.53.209.66]) by pop-3.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h2VDXjY05435; Mon, 31 Mar 2003 07:33:45 -0600 Received: from thoth.ir.bbn.com (localhost [127.0.0.1]) by thoth.ir.bbn.com (8.12.6/8.12.6) with ESMTP id h2VDHOqH021259; Mon, 31 Mar 2003 08:17:24 -0500 (EST) (envelope-from mallman@thoth.ir.bbn.com) Message-Id: <200303311317.h2VDHOqH021259@thoth.ir.bbn.com> To: Reiner Ludwig From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: tsvwg@ietf.org, Phil Karn Subject: Re: [Tsvwg] Rethinking Karn's algorithm In-Reply-To: <5.2.0.9.0.20030331143603.025d98e8@mailhost.eed.ericsson.se> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Hey Jealousy Date: Mon, 31 Mar 2003 08:17:24 -0500 X-RAVMilter-Version: 8.4.1(snapshot 20020919) (pop-3.dnv.wideopenwest.com) Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > With a less conservative version of Karn's algorithm, we would > instead have a true end-to-end solution to the problem. I doubt it. My own opinion is that any end2end "solution" that would obviate the need for a link-up trigger would be too aggressive. I.e., there is fundemental tension between (1) probing often enough to be very responsive on paths that have links that go down and (2) not sending a whole lot of chud into a network that is dropping your packets and is quite unresponsive. > That is, with a few changed lines of TCP sender code (or even only > a single '#define') we would save the IETF extra work (a TRIGTRAN > WG), and would avoid the deployment issues associated with "Link > Up"-Triggers & corresponding TCP sender responses. IETF resources are not the only costs here. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 31 08:31:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05887 for ; Mon, 31 Mar 2003 08:31:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VDt7T03793 for tsvwg-archive@odin.ietf.org; Mon, 31 Mar 2003 08:55:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VDsVO03762; Mon, 31 Mar 2003 08:54:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VDraO03718 for ; Mon, 31 Mar 2003 08:53:36 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05850 for ; Mon, 31 Mar 2003 08:29:50 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2VDWEUE018342; Mon, 31 Mar 2003 15:32:14 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2AG4L0RQ; Mon, 31 Mar 2003 15:32:14 +0200 Received: from res0010384da36.eed.ericsson.se (dhcp5-197.eed.ericsson.se [164.48.135.197]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id PAA18811; Mon, 31 Mar 2003 15:32:14 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030331152101.025e7e00@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 31 Mar 2003 15:31:56 +0200 To: mallman@grc.nasa.gov From: Reiner Ludwig Subject: Re: [Tsvwg] Rethinking Karn's algorithm Cc: tsvwg@ietf.org, Phil Karn In-Reply-To: <200303311317.h2VDHOqH021259@thoth.ir.bbn.com> References: <5.2.0.9.0.20030331143603.025d98e8@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 15:17 31.03.2003, Mark Allman wrote: >My own opinion is that any end2end "solution" that >would obviate the need for a link-up trigger would be too >aggressive. I.e., there is fundemental tension between (1) probing >often enough to be very responsive on paths that have links that go >down and (2) not sending a whole lot of chud into a network that is >dropping your packets and is quite unresponsive. I think, you have nicely summarized the tension that needs to be debated, but I would add that (2) needs to be weighed against the extra traffic that such triggers would cause. I.e., the traffic caused by all the routers that send explicit out-of-band link-up triggers (at some rate?) to a potentially large number of flows active in those routers. [In addition, some of the trigger-receivers might not (cannot) even care, e.g., because they don't have any new data to sent, or because they don't understand the trigger, or because they never get them because the trigger was filtered by a firewall, etc.] ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 31 08:55:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06548 for ; Mon, 31 Mar 2003 08:55:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VEIUH05485 for tsvwg-archive@odin.ietf.org; Mon, 31 Mar 2003 09:18:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VEI8O05462; Mon, 31 Mar 2003 09:18:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VEH1O05424 for ; Mon, 31 Mar 2003 09:17:01 -0500 Received: from web10908.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06488 for ; Mon, 31 Mar 2003 08:53:13 -0500 (EST) Message-ID: <20030331135536.74415.qmail@web10908.mail.yahoo.com> Received: from [12.237.229.250] by web10908.mail.yahoo.com via HTTP; Mon, 31 Mar 2003 05:55:36 PST Date: Mon, 31 Mar 2003 05:55:36 -0800 (PST) From: Spencer Dawkins Subject: Re: [Tsvwg] Rethinking Karn's algorithm To: Reiner Ludwig , mallman@grc.nasa.gov Cc: tsvwg@ietf.org, Phil Karn In-Reply-To: <5.2.0.9.0.20030331152101.025e7e00@mailhost.eed.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Hi, Reiner, I believe that post-IETF 56, what's actually on the table in TRIGTRAN is end-systems resending one "last packet" at link-up time, not routers sending triggers. The considerations you're listing would make explicit requests for TRIGTRAN coverage more attractive, but what's been expressed to me is that explicit requests would have to be a LOT more attractive to require (even edge) routers to maintain per-connection state - so that's why I've backed off on routers sending triggers, at this time. Spencer --- Reiner Ludwig wrote: > > I think, you have nicely summarized the tension that needs to > be debated, > but I would add that (2) needs to be weighed against the extra > traffic that > such triggers would cause. I.e., the traffic caused by all the > routers that > send explicit out-of-band link-up triggers (at some rate?) to > a potentially > large number of flows active in those routers. > > [In addition, some of the trigger-receivers might not (cannot) > even care, > e.g., because they don't have any new data to sent, or because > they don't > understand the trigger, or because they never get them because > the trigger > was filtered by a firewall, etc.] _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 31 09:19:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07027 for ; Mon, 31 Mar 2003 09:19:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VEgwv07292 for tsvwg-archive@odin.ietf.org; Mon, 31 Mar 2003 09:42:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VEgfO07253; Mon, 31 Mar 2003 09:42:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VEY5O06114 for ; Mon, 31 Mar 2003 09:34:05 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06832 for ; Mon, 31 Mar 2003 09:10:17 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2VECfUE002765; Mon, 31 Mar 2003 16:12:41 +0200 (MEST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2AG6HZX9; Mon, 31 Mar 2003 16:12:41 +0200 Received: from res0010384da36.eed.ericsson.se (dhcp5-197.eed.ericsson.se [164.48.135.197]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id QAA26750; Mon, 31 Mar 2003 16:12:40 +0200 (MET DST) Message-Id: <5.2.0.9.0.20030331160237.02607f48@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 31 Mar 2003 16:12:42 +0200 To: Spencer Dawkins From: Reiner Ludwig Subject: Re: [Tsvwg] Rethinking Karn's algorithm Cc: Reiner Ludwig , mallman@grc.nasa.gov, tsvwg@ietf.org, Phil Karn In-Reply-To: <20030331135536.74415.qmail@web10908.mail.yahoo.com> References: <5.2.0.9.0.20030331152101.025e7e00@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 15:55 31.03.2003, Spencer Dawkins wrote: >I believe that post-IETF 56, what's actually on the table in >TRIGTRAN is end-systems resending one "last packet" at link-up >time, not routers sending triggers. Fine. But don't we have exactly that already in section 8.2 ("Recovery from Subnetwork Outages") of draft-ietf-pilc-link-design-13.txt which is a soon-to-be-BCP-RFC: "[...] It is therefore highly desirable that a subnetwork subject to outages not silently discard packets during an outage. Ideally, it should define an interface to the next higher layer (i.e., IP) that allows it to refuse packets during an outage, and to automatically ask IP for new packets when it is again able to deliver them. If it cannot do this, then the subnetwork should hold onto at least some of the packets it accepts during an outage and attempt to deliver them when the subnetwork comes back up. When packets are discarded, IP should be notified so that the appropriate ICMP messages can be sent. Note that it is *not* necessary to completely avoid dropping packets during an outage. The purpose of holding onto a packet during an outage, either in the subnetwork or at the IP layer, is so that its eventual delivery will implicitly notify TCP that the subnetwork is again operational. [...]" And this works for both, hosts and routers. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 31 09:22:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07092 for ; Mon, 31 Mar 2003 09:22:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VEjJW07450 for tsvwg-archive@odin.ietf.org; Mon, 31 Mar 2003 09:45:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VEj4O07443; Mon, 31 Mar 2003 09:45:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VEimO07402 for ; Mon, 31 Mar 2003 09:44:48 -0500 Received: from web10903.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07084 for ; Mon, 31 Mar 2003 09:21:01 -0500 (EST) Message-ID: <20030331142325.76284.qmail@web10903.mail.yahoo.com> Received: from [12.237.229.250] by web10903.mail.yahoo.com via HTTP; Mon, 31 Mar 2003 06:23:25 PST Date: Mon, 31 Mar 2003 06:23:25 -0800 (PST) From: Spencer Dawkins Subject: Re: [Tsvwg] Rethinking Karn's algorithm To: tsvwg@ietf.org In-Reply-To: <5.2.0.9.0.20030331160237.02607f48@mailhost.eed.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Hi, Reiner, Yeah, exactly - what I'm talking about is a more completely specified variant of this. For instance, we might (this is an observation, not a suggestion) recommend that host implementations resend a packet, but not router implementations (as your posting notes, the recommendation in LINK allows both, but doesn't prefer one or the other). Spencer --- Reiner Ludwig wrote: > At 15:55 31.03.2003, Spencer Dawkins wrote: > >I believe that post-IETF 56, what's actually on the table in > >TRIGTRAN is end-systems resending one "last packet" at > link-up > >time, not routers sending triggers. > > Fine. But don't we have exactly that already in section 8.2 > ("Recovery from > Subnetwork Outages") of draft-ietf-pilc-link-design-13.txt > which is a > soon-to-be-BCP-RFC: > > "[...] > It is therefore highly desirable that a subnetwork subject > to outages > not silently discard packets during an outage. Ideally, it > should > define an interface to the next higher layer (i.e., IP) > that allows > it to refuse packets during an outage, and to > automatically ask IP > for new packets when it is again able to deliver them. If > it cannot > do this, then the subnetwork should hold onto at least > some of the > packets it accepts during an outage and attempt to deliver > them when > the subnetwork comes back up. When packets are discarded, > IP should > be notified so that the appropriate ICMP messages can be > sent. > > Note that it is *not* necessary to completely avoid > dropping packets > during an outage. The purpose of holding onto a packet > during an > outage, either in the subnetwork or at the IP layer, is so > that its > eventual delivery will implicitly notify TCP that the > subnetwork is > again operational. [...]" > > And this works for both, hosts and routers. > > ///Reiner > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 31 13:11:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17426 for ; Mon, 31 Mar 2003 13:11:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VIYqa06016 for tsvwg-archive@odin.ietf.org; Mon, 31 Mar 2003 13:34:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VIYOK05987; Mon, 31 Mar 2003 13:34:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VIPGK05524 for ; Mon, 31 Mar 2003 13:25:16 -0500 Received: from seraph3.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17012 for ; Mon, 31 Mar 2003 13:01:25 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 091766BA31 for ; Mon, 31 Mar 2003 13:03:50 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h2VI3m7h023227; Mon, 31 Mar 2003 13:03:48 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id NAA78566; Mon, 31 Mar 2003 13:03:48 -0500 (EST) Message-Id: <200303311803.NAA78566@guns.lerc.nasa.gov> To: Reiner Ludwig From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org, Phil Karn Subject: Re: [Tsvwg] Rethinking Karn's algorithm In-Reply-To: <5.2.0.9.0.20030331152101.025e7e00@mailhost.eed.ericsson.se> Organization: BBN Technologies/NASA GRC Song-of-the-Day: And We Danced Date: Mon, 31 Mar 2003 13:03:48 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > I think, you have nicely summarized the tension that needs to be > debated, but I would add that (2) needs to be weighed against the > extra traffic that such triggers would cause. I.e., the traffic > caused by all the routers that send explicit out-of-band link-up > triggers (at some rate?) to a potentially large number of flows > active in those routers. > > [In addition, some of the trigger-receivers might not (cannot) > even care, e.g., because they don't have any new data to sent, or > because they don't understand the trigger, or because they never > get them because the trigger was filtered by a firewall, etc.] Yes, you'd want to consider that. The trigger traffic is bounded, though, by the number of flows (per some window of time). Whereas, it is fairly difficult to quantify the probing approach in any sort of realistic or meaningful way, it would seem to me. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Mar 31 18:29:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02271 for ; Mon, 31 Mar 2003 18:29:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VNqlc28347 for tsvwg-archive@odin.ietf.org; Mon, 31 Mar 2003 18:52:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VNqNK28327; Mon, 31 Mar 2003 18:52:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VNpAK28301 for ; Mon, 31 Mar 2003 18:51:10 -0500 Received: from cougar.icir.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02222 for ; Mon, 31 Mar 2003 18:27:12 -0500 (EST) Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.9/8.12.3) with ESMTP id h2VNTZFU081315; Mon, 31 Mar 2003 15:29:35 -0800 (PST) (envelope-from floyd@cougar.icir.org) Message-Id: <200303312329.h2VNTZFU081315@cougar.icir.org> To: tsvwg@ietf.org cc: "Henderson, Thomas R" From: Sally Floyd Date: Mon, 31 Mar 2003 15:29:35 -0800 Subject: [Tsvwg] Moving NewReno from Experimental to Proposed Standard Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At the tsvwg meeting in San Francisco two weeks ago, I gave up my five-minute slot for discussing "Moving NewReno from Experimental to Proposed Standard" because of a shortage of time, and said I would send email to the list instead. So finally here it is. (We did take a quick hum at the meeting to verify that people generally thought that taking NewReno to Proposed was a good idea, as I recall.) The viewgraphs for this talk are at: http://www.icir.org/floyd/talks/newreno-Mar03.ps http://www.icir.org/floyd/talks/newreno-Mar03.pdf Here is basically what would have been the text part of the talk: * NewReno was been widely deployed for many years now, and has been an Experimental RFC since 1999, so it seems time to move it from Experimental to Proposed. * NewReno performs dramatically better than Reno when multiple packets are dropped from a window of data, and we would recommend NewReno over Reno, for TCP connections where the other end does not support SACK. However, in the interests of full disclosure, we do know of one scenario where Reno (and Sack) both perform better than NewReno. This is when there are reordered packets but no lost packets, and the sender gets three dup acks from the reordering alone. This is illustrated in slides 4, 5, and 6 of the viewgraphs, for Reno, NewReno, and Sack respectively. * We know of only one change that we want to make to the NewReno RFC. That RFC describes a Careful and Less Careful variant, and recommends the Careful variant. A revision would *require* the Careful instead of the Less Careful variant. The reason for this is illustrated on slide 8 of the viewgraphs, and has to do with the Less Careful's quite bad response to a Fast Retransmit that is due to reordering alone. (The Careful and Less Careful variants are two variants of what is called "bugfix" in the NS simulator. The name "bugfix" dates from the days when Steve McCanne and I were the only users of the NS simulator, and we had not yet made the simulator publically available, so I was also less careful in the names that I attached to things...) * If anyone knows of any other changes that should be made to the NewReno spec as it goes to Proposed, please let Tom and I know. * For all of the simulations in the viewgraphs, the bottom line gives the command needed to run that simulation in the NS simulator, in the directory "tcl/test". Thanks, - Sally _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg