From mailman-owner@ietf.org Fri Dec 1 05:06:04 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07496 for ; Fri, 1 Dec 2000 05:06:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA16574 for ; Fri, 1 Dec 2000 05:06:04 -0500 (EST) Date: Fri, 1 Dec 2000 05:06:04 -0500 (EST) Message-Id: <200012011006.FAA16574@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: tsvwg-archive@ns.ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, tsvwg-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for tsvwg-archive@optimus.ietf.org: List Password // URL ---- -------- tsvwg@ietf.org kfQi http://www1.ietf.org/mailman/options/tsvwg/tsvwg-archive@optimus.ietf.org From tsvwg-admin@ietf.org Mon Dec 4 03:20:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09411 for ; Mon, 4 Dec 2000 03:20:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12765; Mon, 4 Dec 2000 03:15:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12737 for ; Mon, 4 Dec 2000 03:15:45 -0500 (EST) Received: from mail2.itu.int (mail2.itu.ch [156.106.192.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07747 for ; Mon, 4 Dec 2000 03:15:43 -0500 (EST) Received: by mail2.itu.ch with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 09:10:11 +0100 Message-ID: <905DD86907DAD3119DE70000778D770F017496E9@mailsrv1.itu.ch> From: "Jones, Leslie" To: "'L.Wood@eim.surrey.ac.uk'" Cc: "'tsvwg@ietf.org'" Subject: RE: [Tsvwg] Communication from ITU-T Study Group 16 to IETF Trans port Area Date: Mon, 4 Dec 2000 09:15:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Dear Mr. Wood Excuses us for any kind of inconvenience the e-mail might have caused. You may find the Communication (LS3/16) under: http://ties.itu.int/u/tsg16/sg16/ls/outgoing/ Best regards Leslie Jones TSB, Assistant SG16 -----Original Message----- From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] Sent: mercredi, 29. novembre 2000 15:33 To: Bigi, Fabio Cc: 'tsvwg@ietf.org' Subject: Re: [Tsvwg] Communication from ITU-T Study Group 16 to IETF Transport Area On Tue, 28 Nov 2000, Bigi, Fabio wrote: > Attached please find a communication prepared during ITU-T SG16 last meeting > (Geneva, 13-17 November 2000). Um. If you want to communicate with the IETF you might wish to try something other than Word... a pointer to the document on the webserver, rather than 150K mails, would be appreciated. L. V.moip (modem-over-IP)? barking. > Best regards > > Fabio Bigi > TSB, Senior Counsellor > > <> > PGP _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Mon Dec 4 07:01:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21670 for ; Mon, 4 Dec 2000 07:01:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15180; Mon, 4 Dec 2000 06:56:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15151 for ; Mon, 4 Dec 2000 06:56:09 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19973 for ; Mon, 4 Dec 2000 06:56:08 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 142uE0-0004Xn-00; Mon, 04 Dec 2000 11:56:04 +0000 Date: Mon, 4 Dec 2000 11:56:04 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: "Jones, Leslie" cc: "'tsvwg@ietf.org'" Subject: RE: [Tsvwg] Communication from ITU-T Study Group 16 to IETF Trans port Area In-Reply-To: <905DD86907DAD3119DE70000778D770F017496E9@mailsrv1.itu.ch> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org On Mon, 4 Dec 2000, Jones, Leslie wrote: > > You may find the Communication (LS3/16) under: > > http://ties.itu.int/u/tsg16/sg16/ls/outgoing/ It's passworded... L. > Best regards > Leslie Jones > TSB, Assistant SG16 > > -----Original Message----- > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > Sent: mercredi, 29. novembre 2000 15:33 > To: Bigi, Fabio > Cc: 'tsvwg@ietf.org' > Subject: Re: [Tsvwg] Communication from ITU-T Study Group 16 to IETF > Transport Area > > > On Tue, 28 Nov 2000, Bigi, Fabio wrote: > > > Attached please find a communication prepared during ITU-T SG16 last > meeting > > (Geneva, 13-17 November 2000). > > Um. If you want to communicate with the IETF you might wish to try > something other than Word... a pointer to the document on the > webserver, rather than 150K mails, would be appreciated. > > L. > > V.moip (modem-over-IP)? barking. > > > Best regards > > > > Fabio Bigi > > TSB, Senior Counsellor > > > > <> > > > > PGP > > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > http://www1.ietf.org/mailman/listinfo/tsvwg > PGP _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Mon Dec 4 16:17:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02408 for ; Mon, 4 Dec 2000 16:17:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25554; Mon, 4 Dec 2000 16:09:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25523 for ; Mon, 4 Dec 2000 16:09:19 -0500 (EST) Received: from mail0.epfl.ch (mail0.epfl.ch [128.178.50.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00599 for ; Mon, 4 Dec 2000 16:09:17 -0500 (EST) Received: (qmail 1487 invoked from network); 4 Dec 2000 21:09:16 -0000 Received: from lrcsun14.epfl.ch (HELO paul8ozb96x37k) (128.178.156.56) by mail0.epfl.ch with SMTP; 4 Dec 2000 21:09:16 -0000 From: "Paul Hurley" To: Cc: "Jean-Yves Leboudec" Date: Mon, 4 Dec 2000 22:08:30 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Internet Draft on ABE Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I would like to draw your attention to the following Internet Draft, "The ABE Service" draft-hurley-alternative-best-effort-01.txt I enclose the abstract at the bottom. The draft itself can be found from the usual locations or from: http://www.abeservice.org/papers/draft-hurley-alternative-best-effort- 01.txt Any comments etc. are most welcome. Thanks, Paul. Abstract ABE (Alternative Best-Effort) is a novel service for IP networks. It offers applications the choice between receiving a lower end-to-end delay and receiving more overall throughput. Every best effort packet is tagged as either green or blue. Green packets receive a low, bounded queueing delay. To ensure blue packets do not suffer as a result, green flows receive less throughput during bouts of congestion. The unique combination of lower delay with reduced throughput for green makes it different from existing differentiated service proposals such as expedited forwarding and assured forwarding. The incentive to choose one or other is based on the nature of one's traffic and on traffic conditions. Typically, green flows have real-time deadlines (e.g. interactive audio), while blue traffic (e.g. bulk data transfer) seeks to minimise overall transfer time. There is benefit for all traffic in that green traffic achieves a low delay and blue traffic will receive at least as much throughput as it would in a flat best-effort network and usually more. Neither traffic type can be said to be better, thus flat rate pricing may be maintained, and there is no need for reservations or profiles. In this document we define the ABE service, discuss its usefulness, and describe the requirements of router algorithms for ABE support. We outline one particular router implementation, its implementation in dummynet, and present initial experimental results of it on a testbed. Note that ABE is not restricted to any specific implementation and other implementations such as those based on per-flow queueing are certainly do-able. As such, we invite universities and research centres to define other implementations. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use iQA/AwUBOiv5vhN0M9APRei2EQK7hwCfYuABH8OA+c36Q/TSPdaYw5/2p70An00l 7lpbE3nRs3K5g1EdSOV5ioXZ =JAbS -----END PGP SIGNATURE----- _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Sat Dec 9 13:40:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05762 for ; Sat, 9 Dec 2000 13:40:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00211; Sat, 9 Dec 2000 13:34:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00175 for ; Sat, 9 Dec 2000 13:34:00 -0500 (EST) Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04987; Sat, 9 Dec 2000 13:33:39 -0500 (EST) Message-Id: <200012091833.NAA04987@ietf.org> From: Mail Sender To: tststs@gmx.de CC: tsubo@global-commons.co.jp, tsuka@alpha.net.ph, tsurban@home.net, tsvwg@ietf.org, tsvwg-request@ietf.org Reply-To: mailsender@mailsender.ru Date: 09.12.2000 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Tsvwg] Russian Goods and Service from Moscow Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org www.rusgoods.com www.rusgoods.ru ================================================================ We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes watches for the Russian Air Forces , Russian Naval Forces. All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any middlemans. The submarine "Kursk" had on board mechanical marine hronometr 6MX. =============================================================== The "table" of orders. Here you can to order, to find, to know almost everything, than the Russia is rich, everything that does not contradict Russian Federation laws. Here you can receive or order: The information about any enterprise, firm, organization, or person in Russia The production or any goods of Russian manufactories, and other things if it is possible. =============================================================== www.rusgoods.com www.rusgoods.ru _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Mon Dec 11 23:33:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00585 for ; Mon, 11 Dec 2000 23:33:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24371; Mon, 11 Dec 2000 23:27:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24340 for ; Mon, 11 Dec 2000 23:27:46 -0500 (EST) Received: from breeze.lcs.mit.edu (IDENT:root@breeze.lcs.mit.edu [18.31.0.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28933 for ; Mon, 11 Dec 2000 23:27:43 -0500 (EST) Received: from breeze.lcs.mit.edu (IDENT:hari@localhost.localdomain [127.0.0.1]) by breeze.lcs.mit.edu (8.11.0/8.9.3) with ESMTP id eBC4Rjv06383; Mon, 11 Dec 2000 23:27:45 -0500 Message-Id: <200012120427.eBC4Rjv06383@breeze.lcs.mit.edu> X-Mailer: exmh version 2.1.1 10/15/1999 X-url: http://nms.lcs.mit.edu/~hari/ From: Hari Balakrishnan Reply-to: Hari Balakrishnan To: tsvwg@ietf.org cc: snoeren@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Dec 2000 23:27:45 -0500 Subject: [Tsvwg] I-D on TCP Connection Migration Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Alex Snoeren and I recently submitted a draft (draft-snoeren-tcp-migrate-00.txt) on TCP connection migration. We are hoping to get comments on it from this group, and take suggestions on how to improve it, and ideally, to get a discussion going on it. Thanks, Hari PS: Abstract below: This document describes a set of TCP options to support the migration of an active TCP connection across IP addresses and TCP port numbers. Using this option, a TCP peer can open a migrateable connection, transfer one or more bytes on it, and continue the connection from another IP address/TCP port pair in an application-transparent fashion. The set of addresses or ports from where a connection might be continued need not be known in advance. Security against connection hijacking is achieved using a secret cryptographic cookie negotiated through an Elliptic Curve Diffie-Hellman [ANSI-X962] exchange during connection establishment. The initiation of migration can be done either by one of the communicating peers, or by a trusted third-party that presents the negotiated cryptographic cookie. TCP connection migration has several applications, including preserving TCP communication across host mobility in the Internet, and inter-host migration of connections for fault-tolerance or load- balancing. Furthermore, unlike previous approaches such as ETCP [Huitema95], the Migrate options require no modification to the TCP header, packet format, or semantics, and can be initiated by a trusted node different from the communicating peers. _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Tue Dec 12 00:01:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06111 for ; Tue, 12 Dec 2000 00:01:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24918; Mon, 11 Dec 2000 23:57:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24887 for ; Mon, 11 Dec 2000 23:57:20 -0500 (EST) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05580 for ; Mon, 11 Dec 2000 23:57:16 -0500 (EST) From: mankin@isi.edu Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14]) by east.isi.edu (8.9.2/8.9.2) with SMTP id XAA25595 for ; Mon, 11 Dec 2000 23:57:24 -0500 (EST) Date: Tue, 12 Dec 00 00:01:04 EST Posted-Date: Tue, 12 Dec 00 00:01:04 EST Message-Id: <10012120501.AA07769@maia.east.isi.edu> Received: by maia.east.isi.edu (4.1/4.0.3-6) id ; Tue, 12 Dec 00 00:01:04 EST To: tsvwg@ietf.org Subject: [Tsvwg] Working Group Last Call on ECN i-d Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org TSV working group, The sense of the meeting (that we are still in now) was that we should do working group last call on the spec for explicit congestion notification towards advancement to Proposed Standard. The i-d is draft-ietf-tsvwg-ecn-00.txt. Section 6.1.1.2 is to be removed in entirety. This working group last call will end on Jan 3, 2001 (two weeks from now gets us to Dec 25...) Scott and Allison _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Mon Dec 18 12:27:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11687 for ; Mon, 18 Dec 2000 12:27:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03654; Mon, 18 Dec 2000 12:13:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03628 for ; Mon, 18 Dec 2000 12:13:40 -0500 (EST) Received: from mailgate3.austin.ibm.com (mg03.austin.ibm.com [192.35.232.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11423 for ; Mon, 18 Dec 2000 12:13:39 -0500 (EST) Received: from austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96]) by mailgate3.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id LAA33184 for ; Mon, 18 Dec 2000 11:12:37 -0600 Received: from austin.ibm.com (ambika.austin.ibm.com [9.53.150.77]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id LAA46132 for ; Mon, 18 Dec 2000 11:13:39 -0600 Message-ID: <3A3E45C3.9DD01F67@austin.ibm.com> Date: Mon, 18 Dec 2000 11:13:39 -0600 From: venkat venkatsubra Organization: IBM X-Mailer: Mozilla 4.75i [en] (X11; U; AIX 4.3) X-Accept-Language: en MIME-Version: 1.0 To: tsvwg@ietf.org References: <200011031700.MAA01879@optimus.ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Re: new I-D for SACK-based recovery Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Mark and Ethan, In Section 4 ("Algorithm Details"), under (D), are we allowed to send only one segment ? Can't we send multiple segments ? In rfc2018 in section 5.1 it mentions about limiting the number of segments sent in response to each ACK. Can this limit be more than one ? Venkat > Today's Topics: > > 1. new I-D for SACK-based loss recovery (Mark Allman) > > --__--__-- > > Message: 1 > To: tsvwg@ietf.org > Cc: "Ethan Blanton" > From: Mark Allman > Reply-To: mallman@grc.nasa.gov > Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio > Date: Fri, 03 Nov 2000 10:33:17 -0500 > Subject: [Tsvwg] new I-D for SACK-based loss recovery > > > Folks- > > Ethan Blanton and I put together a draft outlining a conservative > SACK-based loss recovery algorithm. The pointer is appended. This > algorithm (hopefully) is implicitly allowed by RFC 2581. We'd love > it if people would take a look at this draft and let us know if you > have comments. > > Thanks, > allman > > ------- Forwarded Message > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : A Conservative SACK-based Loss Recovery Algorithm for > TCP > Author(s) : M. Allman, E. Blanton > Filename : draft-allman-tcp-sack-00.txt > Pages : 6 > Date : 02-Nov-00 > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-allman-tcp-sack-00.txt > _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Mon Dec 18 13:28:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12582 for ; Mon, 18 Dec 2000 13:28:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04478; Mon, 18 Dec 2000 13:21:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04449 for ; Mon, 18 Dec 2000 13:21:26 -0500 (EST) Received: from julia.penguinpowered.com (ppp137.c5300-1.midd-oh.siscom.net [209.251.6.137]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12439 for ; Mon, 18 Dec 2000 13:21:21 -0500 (EST) Received: (from elb@localhost) by julia.penguinpowered.com (8.11.0/8.11.0) id eBIILGj12733; Mon, 18 Dec 2000 13:21:16 -0500 Date: Mon, 18 Dec 2000 13:21:16 -0500 From: Ethan Blanton To: tsvwg@ietf.org Cc: mallman@grc.nasa.gov, venkat venkatsubra Subject: Re: [Tsvwg] Re: new I-D for SACK-based recovery Message-ID: <20001218132116.A12720@entropy.chaos.int> Mail-Followup-To: tsvwg@ietf.org, mallman@grc.nasa.gov, venkat venkatsubra References: <200011031700.MAA01879@optimus.ietf.org> <3A3E45C3.9DD01F67@austin.ibm.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A3E45C3.9DD01F67@austin.ibm.com>; from venkats@austin.ibm.com on Mon, Dec 18, 2000 at 11:13:39AM -0600 X-Operating-System: Linux 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable venkat venkatsubra spake unto us the following wisdom: > In Section 4 ("Algorithm Details"), under (D), > are we allowed to send only one segment ? > Can't we send multiple segments ? > In rfc2018 in section 5.1 it mentions about > limiting the number of segments sent in response > to each ACK. Can this limit be more than one ? My gut feeling is that you can send precisely the number of bytes that were ACKed... This may or may not be one segment, I suppose. Perhaps this needs clarification? Mark, any feelings on this? Ethan --=20 *Notice*: My GPG key has changed. Please retrieve the new key via: gpg --keyserver wwwkeys.us.pgp.net --recv-key 883C1C14 Sorry for the inconvenience. Please note that the new key is signed with my old key for preliminary verification. --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6PlWcr9kA9Ig8HBQRAuKLAJ9aEF7p/cdcu3XwWBf0GnKzmKc2SACgiQkA 8AEYdxbHftcaP3kywet2MRU= =+ogO -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Mon Dec 18 14:15:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13379 for ; Mon, 18 Dec 2000 14:15:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05270; Mon, 18 Dec 2000 14:09:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05241 for ; Mon, 18 Dec 2000 14:09:19 -0500 (EST) Received: from julia.penguinpowered.com (ppp137.c5300-1.midd-oh.siscom.net [209.251.6.137]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13331 for ; Mon, 18 Dec 2000 14:09:18 -0500 (EST) Received: (from elb@localhost) by julia.penguinpowered.com (8.11.0/8.11.0) id eBIJ9HH12860 for tsvwg@ietf.org; Mon, 18 Dec 2000 14:09:17 -0500 Date: Mon, 18 Dec 2000 14:09:17 -0500 From: Ethan Blanton To: tsvwg@ietf.org Message-ID: <20001218140917.A12829@entropy.chaos.int> Mail-Followup-To: tsvwg@ietf.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: Linux X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 Subject: [Tsvwg] draft-allman-tcp-sack-00.txt Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello all, As mentioned at the meeting on 12/11, Mark and I would like to see http://www.ietf.org/internet-drafts/draft-allman-tcp-sack-00.txt, "A Conservative SACK-based Loss Recovery Algorithm for TCP", go to Proposed Standard soon provided that it meets with the approval of this working group. Due to this, we would greatly appreciate feedback from anyone who has time= =20 to read and comment on it. Thanks, Ethan --=20 *Notice*: My GPG key has changed. Please retrieve the new key via: gpg --keyserver wwwkeys.us.pgp.net --recv-key 883C1C14 Sorry for the inconvenience. Please note that the new key is signed with my old key for preliminary verification. --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6PmDdr9kA9Ig8HBQRAgcpAJ97eGoboFm2BPX9wSEPeYgWnVRqTgCfWAdB wbx5JpWP5fa1lQgCJcxrc5g= =3pkB -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Tue Dec 19 09:37:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14494 for ; Tue, 19 Dec 2000 09:37:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28988; Tue, 19 Dec 2000 09:26:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28957 for ; Tue, 19 Dec 2000 09:26:45 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14192 for ; Tue, 19 Dec 2000 09:26:41 -0500 (EST) Received: from lawyers.grc.nasa.gov (IDENT:root@lawyers.lerc.nasa.gov [139.88.87.34]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA06013 for ; Tue, 19 Dec 2000 09:26:38 -0500 (EST) Received: from lawyers.grc.nasa.gov (mallman@localhost) by lawyers.grc.nasa.gov (8.9.3/8.9.3) with ESMTP id XAA18324; Mon, 18 Dec 2000 23:26:51 -0500 Message-Id: <200012190426.XAA18324@lawyers.grc.nasa.gov> To: venkat venkatsubra , Ethan Blanton From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: tsvwg@ietf.org Subject: Re: [Tsvwg] Re: new I-D for SACK-based recovery Organization: NASA GRC/BBN Technologies Song-of-the-Day: Everybody Wants You Date: Mon, 18 Dec 2000 23:26:51 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org > My gut feeling is that you can send precisely the number of bytes > that were ACKed... This may or may not be one segment, I suppose. > Perhaps this needs clarification? > > Mark, any feelings on this? Hmm... My first hit is that you're right, I guess. Although, I am not sure we send *precisle* the number of bytes possible. I would say we would want to send the greatest number of full-sized segments possible (i.e., there could -- in theory -- be some slop and we could end up starting to create runt packets this way I think). I think that when we receive every ACK that this means we'll send one segment in response to each ACK). However, if we lose an ACK we'll get more new SACK information on the subsequent ACK and therefore there is a chance we could squeeze out more than one segment, which is probably the right thing to do. (And, this likely prevents some small burst at the end of recovery if we have a bunch of ACK loss). We should clean this up in the draft, assuming there are no further objections. Thanks! allman --- Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Tue Dec 19 14:06:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21832 for ; Tue, 19 Dec 2000 14:06:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03934; Tue, 19 Dec 2000 13:52:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03905 for ; Tue, 19 Dec 2000 13:52:38 -0500 (EST) Received: from mailgate3.austin.ibm.com (mg03.austin.ibm.com [192.35.232.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21381 for ; Tue, 19 Dec 2000 13:52:35 -0500 (EST) Received: from austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96]) by mailgate3.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id MAA07180; Tue, 19 Dec 2000 12:51:32 -0600 Received: from austin.ibm.com (ambika.austin.ibm.com [9.53.150.77]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id MAA39506; Tue, 19 Dec 2000 12:52:33 -0600 Message-ID: <3A3FAE71.134F917@austin.ibm.com> Date: Tue, 19 Dec 2000 12:52:33 -0600 From: venkat venkatsubra Organization: IBM X-Mailer: Mozilla 4.75i [en] (X11; U; AIX 4.3) X-Accept-Language: en MIME-Version: 1.0 To: mallman@grc.nasa.gov CC: Ethan Blanton , tsvwg@ietf.org Subject: Re: [Tsvwg] Re: new I-D for SACK-based recovery References: <200012190426.XAA18324@lawyers.grc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Mark, Ethan, Thanks for the response. When retransmitting after the third duplicate ACK, should the retransmitted packet be added to the ``pipe'' or not ? The algorithm does not add it. Thanks! Venkat Mark Allman wrote: > > My gut feeling is that you can send precisely the number of bytes > > that were ACKed... This may or may not be one segment, I suppose. > > Perhaps this needs clarification? > > > > Mark, any feelings on this? > > Hmm... My first hit is that you're right, I guess. Although, I am > not sure we send *precisle* the number of bytes possible. I would > say we would want to send the greatest number of full-sized segments > possible (i.e., there could -- in theory -- be some slop and we > could end up starting to create runt packets this way I think). I > think that when we receive every ACK that this means we'll send one > segment in response to each ACK). However, if we lose an ACK we'll > get more new SACK information on the subsequent ACK and therefore > there is a chance we could squeeze out more than one segment, which > is probably the right thing to do. (And, this likely prevents some > small burst at the end of recovery if we have a bunch of ACK loss). > > We should clean this up in the draft, assuming there are no further > objections. > > Thanks! > > allman > > --- > Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Tue Dec 19 15:35:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23917 for ; Tue, 19 Dec 2000 15:35:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06317; Tue, 19 Dec 2000 15:27:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06289 for ; Tue, 19 Dec 2000 15:27:51 -0500 (EST) Received: from cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23758 for ; Tue, 19 Dec 2000 15:27:48 -0500 (EST) Received: (from mbashyam@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA02029; Tue, 19 Dec 2000 12:26:44 -0800 (PST) From: Murali Bashyam Message-Id: <200012192026.MAA02029@cisco.com> Subject: Re: [Tsvwg] Re: new I-D for SACK-based recovery To: venkats@austin.ibm.com (venkat venkatsubra) Date: Tue, 19 Dec 2000 12:26:44 -0800 (PST) Cc: mallman@grc.nasa.gov, eblanton@cs.ohiou.edu (Ethan Blanton), tsvwg@ietf.org In-Reply-To: <3A3FAE71.134F917@austin.ibm.com> from "venkat venkatsubra" at Dec 19, 2000 12:52:33 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit > > Mark, Ethan, > Thanks for the response. > When retransmitting after the third duplicate ACK, should > the retransmitted packet be added to the ``pipe'' or not ? > The algorithm does not add it. Isn't it already accounted for in the setting of pipe to HighData - HighACK - AmountSACKed ? The fast retransmit is going to send HighACK, isn't it? Murali > Thanks! > Venkat > > Mark Allman wrote: > > > > My gut feeling is that you can send precisely the number of bytes > > > that were ACKed... This may or may not be one segment, I suppose. > > > Perhaps this needs clarification? > > > > > > Mark, any feelings on this? > > > > Hmm... My first hit is that you're right, I guess. Although, I am > > not sure we send *precisle* the number of bytes possible. I would > > say we would want to send the greatest number of full-sized segments > > possible (i.e., there could -- in theory -- be some slop and we > > could end up starting to create runt packets this way I think). I > > think that when we receive every ACK that this means we'll send one > > segment in response to each ACK). However, if we lose an ACK we'll > > get more new SACK information on the subsequent ACK and therefore > > there is a chance we could squeeze out more than one segment, which > > is probably the right thing to do. (And, this likely prevents some > > small burst at the end of recovery if we have a bunch of ACK loss). > > > > We should clean this up in the draft, assuming there are no further > > objections. > > > > Thanks! > > > > allman > > > > --- > > Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > http://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Tue Dec 19 16:01:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24709 for ; Tue, 19 Dec 2000 16:01:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06741; Tue, 19 Dec 2000 15:51:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06710 for ; Tue, 19 Dec 2000 15:51:46 -0500 (EST) Received: from cisco.com (omega.cisco.com [171.69.63.141]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24476 for ; Tue, 19 Dec 2000 15:51:42 -0500 (EST) Received: (from mbashyam@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA03934; Tue, 19 Dec 2000 12:49:31 -0800 (PST) From: Murali Bashyam Message-Id: <200012192049.MAA03934@cisco.com> Subject: Re: [Tsvwg] Re: new I-D for SACK-based recovery To: mallman@grc.nasa.gov Date: Tue, 19 Dec 2000 12:49:31 -0800 (PST) Cc: venkats@austin.ibm.com (venkat venkatsubra), eblanton@cs.ohiou.edu (Ethan Blanton), tsvwg@ietf.org In-Reply-To: <200012190426.XAA18324@lawyers.grc.nasa.gov> from "Mark Allman" at Dec 18, 2000 11:26:51 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Shouldn't there be a call to MarkRetran in step D, in the scenario when NextSeg returns a sequence number corresponding to a previously sent segment? Murali > > > > My gut feeling is that you can send precisely the number of bytes > > that were ACKed... This may or may not be one segment, I suppose. > > Perhaps this needs clarification? > > > > Mark, any feelings on this? > > Hmm... My first hit is that you're right, I guess. Although, I am > not sure we send *precisle* the number of bytes possible. I would > say we would want to send the greatest number of full-sized segments > possible (i.e., there could -- in theory -- be some slop and we > could end up starting to create runt packets this way I think). I > think that when we receive every ACK that this means we'll send one > segment in response to each ACK). However, if we lose an ACK we'll > get more new SACK information on the subsequent ACK and therefore > there is a chance we could squeeze out more than one segment, which > is probably the right thing to do. (And, this likely prevents some > small burst at the end of recovery if we have a bunch of ACK loss). > > We should clean this up in the draft, assuming there are no further > objections. > > Thanks! > > allman > > > --- > Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > http://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Tue Dec 19 16:04:21 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24806 for ; Tue, 19 Dec 2000 16:04:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06827; Tue, 19 Dec 2000 15:56:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06796 for ; Tue, 19 Dec 2000 15:56:41 -0500 (EST) Received: from julia.penguinpowered.com (ppp155.c5300-1.midd-oh.siscom.net [209.251.6.155]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24568 for ; Tue, 19 Dec 2000 15:56:31 -0500 (EST) Received: (from elb@localhost) by julia.penguinpowered.com (8.11.0/8.11.0) id eBJKu3s13963; Tue, 19 Dec 2000 15:56:03 -0500 Date: Tue, 19 Dec 2000 15:56:03 -0500 From: Ethan Blanton To: Murali Bashyam Cc: mallman@grc.nasa.gov, venkat venkatsubra , tsvwg@ietf.org Subject: Re: [Tsvwg] Re: new I-D for SACK-based recovery Message-ID: <20001219155603.A13945@entropy.chaos.int> Mail-Followup-To: Murali Bashyam , mallman@grc.nasa.gov, venkat venkatsubra , tsvwg@ietf.org References: <200012190426.XAA18324@lawyers.grc.nasa.gov> <200012192049.MAA03934@cisco.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200012192049.MAA03934@cisco.com>; from mbashyam@cisco.com on Tue, Dec 19, 2000 at 12:49:31PM -0800 X-Operating-System: Linux 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Murali Bashyam spake unto us the following wisdom: > Shouldn't there be a call to MarkRetran in step D, in the scenario > when NextSeg returns a sequence number corresponding to a previously > sent segment? You are absolutely correct. Consider it added. Ethan --=20 *Notice*: My GPG key has changed. Please retrieve the new key via: gpg --keyserver wwwkeys.us.pgp.net --recv-key 883C1C14 Sorry for the inconvenience. Please note that the new key is signed with my old key for preliminary verification. --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6P8tjr9kA9Ig8HBQRAmhlAKCQyTjBV5MUeVT2VypWymLL3Bb1gwCgr3SC NlNKUjawdkI35DkKF3UvkEc= =gRCA -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Wed Dec 20 13:18:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08431 for ; Wed, 20 Dec 2000 13:18:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26302; Wed, 20 Dec 2000 12:54:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26271 for ; Wed, 20 Dec 2000 12:53:52 -0500 (EST) Received: from sabre.sjf.novell.com (sabre.sjf.novell.com [130.57.82.42]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06753 for ; Wed, 20 Dec 2000 12:53:50 -0500 (EST) Received: (from mahdavi@localhost) by sabre.sjf.novell.com (8.9.3/8.9.3) id JAA02922; Wed, 20 Dec 2000 09:52:48 -0800 Reply-To: mahdavi@novell.com To: tsvwg@ietf.org Cc: Mark Allman , Tan Gao Subject: Re: [Tsvwg] Re: new I-D for SACK-based recovery From: Jamshid Mahdavi Date: 20 Dec 2000 09:51:27 -0800 In-Reply-To: Mark Allman's message of "Mon, 18 Dec 2000 23:26:51 -0500" Message-ID: Lines: 29 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Mark, This looks like a very nice draft. We have also suggested the possibility that NextSeg() could duplicate the 3 dupacks check for each sequence number range it returns; this would fix the (admittedly unlikely) case where a packet was reordered at just the right point in time after the loss which started recovery. (The reordering would emit a SACK block which looks like a loss until the next SACK block comes in which indicates the arrival of the out-of-order segment). It also occurs to me to ask whether you mean "segment" in this definition of NextSeg() or whether you actually just mean a byte-range. (I.e. does NextSeg() decide how to segment the data or does the caller of NextSeg()?) Another minor point, but maybe worth clarifying. As far as justification for this I-D, Tan Gao did some work for me this summer which provides some very compelling examples of problems in numerous implementations. I have put this work on line at the following URL: http://www.neticus.com/users/mahdavi/papers/tcp_behavior.ps If anyone has any doubt for the need of drafts such as this one, they should look at this paper (and perhaps be terrified...). --Jamshid _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Wed Dec 20 20:15:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21027 for ; Wed, 20 Dec 2000 20:15:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01588; Wed, 20 Dec 2000 20:08:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01558 for ; Wed, 20 Dec 2000 20:08:40 -0500 (EST) Received: from primus.cs.ohiou.edu (ppp83.c5300-1.midd-oh.siscom.net [209.251.6.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20927 for ; Wed, 20 Dec 2000 20:08:37 -0500 (EST) Received: (from elb@localhost) by primus.cs.ohiou.edu (8.11.0/8.11.0) id eBL18GF22334; Wed, 20 Dec 2000 20:08:16 -0500 Date: Wed, 20 Dec 2000 20:08:15 -0500 From: Ethan Blanton To: Jamshid Mahdavi Cc: tsvwg@ietf.org, Mark Allman , Tan Gao Subject: Re: [Tsvwg] Re: new I-D for SACK-based recovery Message-ID: <20001220200815.B22318@entropy.chaos.int> Mail-Followup-To: Jamshid Mahdavi , tsvwg@ietf.org, Mark Allman , Tan Gao References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="7iMSBzlTiPOCCT2k" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mahdavi@novell.com on Wed, Dec 20, 2000 at 09:51:27AM -0800 X-Operating-System: Linux 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org --7iMSBzlTiPOCCT2k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jamshid Mahdavi spake unto us the following wisdom: > This looks like a very nice draft. We have also suggested the > possibility that NextSeg() could duplicate the 3 dupacks check for > each sequence number range it returns; this would fix the > (admittedly unlikely) case where a packet was reordered at just the > right point in time after the loss which started recovery. (The > reordering would emit a SACK block which looks like a loss until the > next SACK block comes in which indicates the arrival of the > out-of-order segment). Hmm, this seems reasonable to me as long as it does not prevent a packet being sent altogether... i.e. it seems like a good enough reason to send *new* data, but not a good enough reason to send nothing at all. If there is no new data I think the first non-ACKed non-SACKed non-rexmtd packet should go all the same. Comments? > It also occurs to me to ask whether you mean "segment" in this > definition of NextSeg() or whether you actually just mean a > byte-range. (I.e. does NextSeg() decide how to segment the data or > does the caller of NextSeg()?) Another minor point, but maybe worth > clarifying. I feel it should return a byte range that is the precise size of the segment to be sent. This seems most reasonable to me... This range would be 1 SMSS for new data or large holes, and could conceivably be less if a small packet was lost for some reason. > If anyone has any doubt for the need of drafts such as this one, they > should look at this paper (and perhaps be terrified...). I have been reading it this afternoon, and I am indeed frightened... Ethan --=20 *Notice*: My GPG key has changed. Please retrieve the new key via: gpg --keyserver wwwkeys.us.pgp.net --recv-key 883C1C14 Sorry for the inconvenience. Please note that the new key is signed with my old key for preliminary verification. --7iMSBzlTiPOCCT2k Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6QVf/r9kA9Ig8HBQRAjqoAJ9A08fJXQIuLsLjQlapzqJx9fOdzQCdES9D h9RD+ZFdAfPBa/vBwSHs32M= =OJXZ -----END PGP SIGNATURE----- --7iMSBzlTiPOCCT2k-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Thu Dec 21 05:59:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14591 for ; Thu, 21 Dec 2000 05:59:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13963; Thu, 21 Dec 2000 05:53:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13933 for ; Thu, 21 Dec 2000 05:53:40 -0500 (EST) Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14557 for ; Thu, 21 Dec 2000 05:53:39 -0500 (EST) Received: from localhost (root@porsta.cs.Helsinki.FI [128.214.48.124]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with ESMTP id MAA16633; Thu, 21 Dec 2000 12:53:38 +0200 Date: Thu, 21 Dec 2000 12:53:38 +0200 (EET) From: Andrei Gurtov To: pilc@grc.nasa.gov, tsvwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Tsvwg] yet another TCP thesis Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Hello! Reiner and others have pointed out that slow wireless links are often heavily overbuffered, but not so much work have been done to determine an optimal buffer size and/or determine appropriate parameters for RED in the last-hop buffer. Matthew have mentioned the problem of the slow-start overshot in the FACK paper and suggested the overdumping algorithm to prevent it. There can be other ways also. BSD-clone OSes have been a long time a de-facto standard for TCP research. However, currently also the upcoming Linux kernel 2.4 can be used for serious TCP research. BSD has somewhat deteriorated from past "high-conformance" standards: for example FreeBSD-latest have no slow start in the same subnetwork that doesn't look very nice over a dial-up PPP link. A master thesis "TCP performance at the presence of congestion and corruption losses" available at http://www.cs.Helsinki.FI/research/iwtcp/papers/ addresses these issues and evaluation of the effect of the increased initial window, reduced receiver window, new reno and sack on TCP over an emulated wireless link. Comments? Andrei _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Thu Dec 21 10:43:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22519 for ; Thu, 21 Dec 2000 10:43:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17047; Thu, 21 Dec 2000 10:34:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17016 for ; Thu, 21 Dec 2000 10:34:22 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22324 for ; Thu, 21 Dec 2000 10:34:22 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA10477; Thu, 21 Dec 2000 10:34:16 -0500 (EST) Received: from guns (mallman@localhost) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id KAA25412; Thu, 21 Dec 2000 10:34:16 -0500 (EST) Message-Id: <200012211534.KAA25412@guns.lerc.nasa.gov> To: Jamshid Mahdavi From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: Ethan Blanton , tsvwg@ietf.org, Tan Gao Subject: Re: [Tsvwg] Re: new I-D for SACK-based recovery Organization: NASA GRC/BBN Technologies Song-of-the-Day: Fly By Night Date: Thu, 21 Dec 2000 10:34:16 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Jamshid- Thanks for the comments! > > This looks like a very nice draft. We have also suggested the > > possibility that NextSeg() could duplicate the 3 dupacks check > > for each sequence number range it returns; this would fix the > > (admittedly unlikely) case where a packet was reordered at just > > the right point in time after the loss which started recovery. > > (The reordering would emit a SACK block which looks like a loss > > until the next SACK block comes in which indicates the arrival > > of the out-of-order segment). > > Hmm, this seems reasonable to me as long as it does not prevent a > packet being sent altogether... i.e. it seems like a good enough > reason to send *new* data, but not a good enough reason to send > nothing at all. If there is no new data I think the first > non-ACKed non-SACKed non-rexmtd packet should go all the same. > Comments? I understand the desire to be robust in the face of reordering. However, I want to push back a little here -- or, at least get a clarification. Say we're using timestamps so we can send at most 3 SACK blocks in each ACK. Now consider the following situation: rcv seg 40 [everything before 40 has been received] snd ACK seg 40 rcv seg 42 snd ACK seg 40, SACK 42 rcv seg 44 snd ACK seg 40, SACK 44,42 rcv seg 46 snd ACK seg 40, SACK 46,44,42 rcv seg 48 snd ACK seg 40, SACK 48,46,44 So, assume that all the ACKs arrive. It would seem to me that ACKs 2, 3 and 4 explicitly indicate that segment 41 is missing -- meeting the criteria to retransmit. However, if ACK 2 is lost we will not see 3 SACKs explicitly pointing out that 41 is missing. However, we can note that ACKs 3 and 4 do not contain 42 in the first SACK block, so we can conclude that we missed an ACK and therefore we could trigger a retransmit. What if we lose ACK 4? We don't get 3 specific indications that segment 41 is missing. And, unlike the last example, it is not necessarily simple to *know* we missed a SACK (although you can likely untangle this all later by noting that we never received a SACK with 46 in the first SACK block -- but, I think this ugly quick). So, we likely can't hit the threshold for retransmission. Or, is is good enough to get 3 SACKs for segment 42 *or a higher segment* before retransmitting segment 41? If this is OK, I think I'm OK with the algorithm. If you need three specific indications then I don't think I am a fan given that I think the algorithm is fragile in the face of ACK loss. allman --- Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Fri Dec 29 14:23:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11916 for ; Fri, 29 Dec 2000 14:23:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02528; Fri, 29 Dec 2000 14:17:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02497 for ; Fri, 29 Dec 2000 14:17:41 -0500 (EST) Received: from sabre.sjf.novell.com ([130.57.82.42]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11826 for ; Fri, 29 Dec 2000 14:17:41 -0500 (EST) Received: (from mahdavi@localhost) by sabre.sjf.novell.com (8.9.3/8.9.3) id LAA20324; Fri, 29 Dec 2000 11:16:33 -0800 Reply-To: mahdavi@novell.com To: mallman@grc.nasa.gov Cc: Ethan Blanton , tsvwg@ietf.org, Tan Gao Subject: Re: [Tsvwg] Re: new I-D for SACK-based recovery References: <200012211534.KAA25412@guns.lerc.nasa.gov> From: Jamshid Mahdavi Date: 29 Dec 2000 11:16:33 -0800 In-Reply-To: Mark Allman's message of "Thu, 21 Dec 2000 10:34:16 -0500" Message-ID: Lines: 32 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org To follow up on two notes from before the holiday: 1. As Ethan wrote, you would still send new data if there are holes in the scoreboard which have not been SACKed 3 times, and your window permits you to send something. 2. As Mark wrote, you would accept any SACK higher than the hole in question as an indication that the hole is in fact a hole. (As opposed to just a SACK containing N+1 specificly). Happy New Year everyone! --Jamshid Ethan Blanton writes: ... > Hmm, this seems reasonable to me as long as it does not prevent a > packet being sent altogether... i.e. it seems like a good enough > reason to send *new* data, but not a good enough reason to send > nothing at all. If there is no new data I think the first non-ACKed > non-SACKed non-rexmtd packet should go all the same. Comments? Mark Allman writes: ... > Or, is is good enough to get 3 SACKs for segment 42 *or a higher > segment* before retransmitting segment 41? If this is OK, I think > I'm OK with the algorithm. If you need three specific indications > then I don't think I am a fan given that I think the algorithm is > fragile in the face of ACK loss. _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-admin@ietf.org Fri Dec 29 15:50:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12923 for ; Fri, 29 Dec 2000 15:50:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03213; Fri, 29 Dec 2000 15:46:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03182 for ; Fri, 29 Dec 2000 15:46:56 -0500 (EST) Received: from primus.cs.ohiou.edu ([209.251.6.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12888 for ; Fri, 29 Dec 2000 15:46:55 -0500 (EST) Received: (from elb@localhost) by primus.cs.ohiou.edu (8.11.0/8.11.0) id eBTKkam05989; Fri, 29 Dec 2000 15:46:36 -0500 Date: Fri, 29 Dec 2000 15:46:36 -0500 From: Ethan Blanton To: Jamshid Mahdavi Cc: mallman@grc.nasa.gov, tsvwg@ietf.org, Tan Gao Subject: Re: [Tsvwg] Re: new I-D for SACK-based recovery Message-ID: <20001229154636.A5975@entropy.chaos.int> Mail-Followup-To: Jamshid Mahdavi , mallman@grc.nasa.gov, tsvwg@ietf.org, Tan Gao References: <200012211534.KAA25412@guns.lerc.nasa.gov> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mahdavi@novell.com on Fri, Dec 29, 2000 at 11:16:33AM -0800 X-Operating-System: Linux 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jamshid Mahdavi spake unto us the following wisdom: > To follow up on two notes from before the holiday: >=20 > 1. As Ethan wrote, you would still send new data if there are holes > in the scoreboard which have not been SACKed 3 times, and your > window permits you to send something. =2E.. AND if there is no new data to be sent but there are holes, you=20 retransmit a hole regardless of whether or not it has been SACKed as a hole three times. > 2. As Mark wrote, you would accept any SACK higher than the hole in > question as an indication that the hole is in fact a hole. (As > opposed to just a SACK containing N+1 specificly). With that caveat, I like these. Ethan --=20 I was young and foolish then, I feel old and foolish now. -- They Might Be Giants, "Ball & Chain" --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6TPgsr9kA9Ig8HBQRAh8HAJ9KpmLIJqUQJF26V95VjXpWEQV31QCgkIfc KaSGvWhVt69sJFx6hkdya8k= =AQmd -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg