From exim@www1.ietf.org Mon Mar 1 12:46:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24181 for ; Mon, 1 Mar 2004 12:46:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrUJ-0004O7-37 for tcpm-archive@odin.ietf.org; Mon, 01 Mar 2004 12:45:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21HjtTi016861 for tcpm-archive@odin.ietf.org; Mon, 1 Mar 2004 12:45:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrUI-0004Ns-Qo for tcpm-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 12:45:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24159 for ; Mon, 1 Mar 2004 12:45:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxrUH-0000mC-00 for tcpm-web-archive@ietf.org; Mon, 01 Mar 2004 12:45:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxrTM-0000gO-00 for tcpm-web-archive@ietf.org; Mon, 01 Mar 2004 12:44:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxrSU-0000aj-00 for tcpm-web-archive@ietf.org; Mon, 01 Mar 2004 12:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrSS-0004Ji-Lb; Mon, 01 Mar 2004 12:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrRb-0004GG-1U for tcpm@optimus.ietf.org; Mon, 01 Mar 2004 12:43:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24103 for ; Mon, 1 Mar 2004 12:43:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxrRZ-0000U3-00 for tcpm@ietf.org; Mon, 01 Mar 2004 12:43:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxrQp-0000Nl-00 for tcpm@ietf.org; Mon, 01 Mar 2004 12:42:20 -0500 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 1AxrQE-0000F8-00 for tcpm@ietf.org; Mon, 01 Mar 2004 12:41:42 -0500 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 1940232BAF; Mon, 1 Mar 2004 12:41: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 D21B832A74; Mon, 1 Mar 2004 12:41:40 -0500 (EST) Date: Mon, 1 Mar 2004 12:41:40 -0500 (EST) From: Janardhan Iyengar X-X-Sender: iyengar@stimpy.eecis.udel.edu To: Mark Allman Cc: "Armando L. Caro Jr." , tcpm@ietf.org, Sourabh Ladha , "Paul D. Amer" Subject: Re: [tcpm] TCP consolidation doc In-Reply-To: <20040301041243.548FE10D09B@lawyers.icir.org> Message-ID: References: <20040301041243.548FE10D09B@lawyers.icir.org> 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: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi all, > I find myself really wondering what a longer document would buy us. > It'd be damn hard to write and agree on, I bet. And, it'd be cumbersome > to change -- and, I think one lesson we have learned is that TCP is > always evolving. So, especially if one puts experimental things into > the document I think it'd be way hard to make that work. Think about > this... say one wanted to include early retransmit and we have this > mega-doc. Now we have to open up the document to put in this one > change. But, while the document is open people want to throw other > things in. Can they? Do we now have charter lines that say "open > section X of The TCP Thome only"? I agree. I was thinking along the same lines myself, and was wondering whether a document like this could be written up with mass consent *before* another enhancement pops up and becomes important. IMHO, the roadmap should be able to provide what, with mass consent, the "latest and greatest" TCP includes. It seems to me that a practical goal is a good consolidation doc that would include pointers and have discussion about interoperations between the different extensions (Sourabh is looking into something similar at this time) and maybe implementation notes about possible pitfalls during consolidation (from implementers' experiences). Granted that for an implementer, it is a headache to get n documents and piece together the n extensions/enhancements, and leaves room for error in the implementation. regards, jana --------------------------------------------------------------- Visit www.narmada.org, www.indiatogether.org --------------------------------------------------------------- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Mar 1 13:05:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25472 for ; Mon, 1 Mar 2004 13:05:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrms-00068q-SX for tcpm-archive@odin.ietf.org; Mon, 01 Mar 2004 13:05:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21I56T8023607 for tcpm-archive@odin.ietf.org; Mon, 1 Mar 2004 13:05:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrms-00068g-N1 for tcpm-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 13:05:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25452 for ; Mon, 1 Mar 2004 13:05:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axrmq-0003ON-00 for tcpm-web-archive@ietf.org; Mon, 01 Mar 2004 13:05:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axrlp-0003G5-00 for tcpm-web-archive@ietf.org; Mon, 01 Mar 2004 13:04:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axrkt-00038W-00 for tcpm-web-archive@ietf.org; Mon, 01 Mar 2004 13:03:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrkq-00063h-Uq; Mon, 01 Mar 2004 13:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrkh-000639-9G for tcpm@optimus.ietf.org; Mon, 01 Mar 2004 13:02:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25286 for ; Mon, 1 Mar 2004 13:02:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axrkf-00036A-00 for tcpm@ietf.org; Mon, 01 Mar 2004 13:02:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axrjj-0002yt-00 for tcpm@ietf.org; Mon, 01 Mar 2004 13:01:51 -0500 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 1Axrip-0002pP-00 for tcpm@ietf.org; Mon, 01 Mar 2004 13:00:55 -0500 Received: from argos.ee.surrey.ac.uk ([131.227.89.15] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 1Axri3-0002Z3-00; Mon, 01 Mar 2004 18:00:07 +0000 Date: Mon, 1 Mar 2004 18:00:04 +0000 (GMT) From: Lloyd Wood X-X-Sender: eep1lw@argos.ee.surrey.ac.uk To: Janardhan Iyengar cc: Mark Allman , "Armando L. Caro Jr." , "" , Sourabh Ladha , "Paul D. Amer" Subject: Re: [tcpm] TCP consolidation doc In-Reply-To: Message-ID: References: <20040301041243.548FE10D09B@lawyers.icir.org> 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 X-Scanner: exiscan *1Axri3-0002Z3-00*9Zm80m3J62w* (SECM, UniS) Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 allman wrote: > I find myself really wondering what a longer document would buy us. > It'd be damn hard to write and agree on, I bet. Note the history of aborted/unpublished TCP documents. RFC1323bis, the whole SACK thing. A long document is doomed before you start. Adding new/experimental stuff dooms you too. What you really want is a very short RFC relying heavily on the normative mechanism, commenting on the current standards-track RFCs as normative references, saying what is considered important to implement, what is worthwhile implementing, possibly known implementation gotchas, etc. This RFC would go BCP, and be updated by subsequent BCP docs replacing it. You'd expct a yearly or two-yearly commentary on the state of the art of TCP, really. Given the existing IETF document focus on TCP and the narrow focus of this doc on that, it's the one instance where normative references in a BCP doc actually make sense. L. I can't believe I just said that. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Mar 1 19:37:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15878 for ; Mon, 1 Mar 2004 19:37:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxuD-0006ts-4a for tcpm-archive@odin.ietf.org; Mon, 01 Mar 2004 19:37:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220b5ZP026517 for tcpm-archive@odin.ietf.org; Mon, 1 Mar 2004 19:37:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxuC-0006tU-Iv for tcpm-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:37:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15822 for ; Mon, 1 Mar 2004 19:37:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxuB-0000J7-00 for tcpm-web-archive@ietf.org; Mon, 01 Mar 2004 19:37:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxtB-0000AB-00 for tcpm-web-archive@ietf.org; Mon, 01 Mar 2004 19:36:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxsE-00003d-00 for tcpm-web-archive@ietf.org; Mon, 01 Mar 2004 19:35:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxsD-0006F8-1c; Mon, 01 Mar 2004 19:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxrL-0006BQ-5H for tcpm@optimus.ietf.org; Mon, 01 Mar 2004 19:34:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15723 for ; Mon, 1 Mar 2004 19:34:04 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxrJ-0007lD-00 for tcpm@ietf.org; Mon, 01 Mar 2004 19:34:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxqQ-0007fH-00 for tcpm@ietf.org; Mon, 01 Mar 2004 19:33:11 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AxxpY-0007Yj-00 for tcpm@ietf.org; Mon, 01 Mar 2004 19:32:16 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i220W9T24346; Tue, 2 Mar 2004 02:32:09 +0200 (EET) X-Scanned: Tue, 2 Mar 2004 02:31:41 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i220VfXE003928; Tue, 2 Mar 2004 02:31:41 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 008eChpO; Tue, 02 Mar 2004 02:31:39 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i220VdO03506; Tue, 2 Mar 2004 02:31:39 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Mar 2004 02:31:39 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] TCP consolidation doc Date: Tue, 2 Mar 2004 02:31:38 +0200 Message-ID: Thread-Topic: [tcpm] TCP consolidation doc thread-index: AcP/t3ukhRagK3sYS9ehsOLTTGW2WAANgQ4Q To: , Cc: , , , , X-OriginalArrivalTime: 02 Mar 2004 00:31:39.0549 (UTC) FILETIME=[BA5CECD0:01C3FFED] Content-Transfer-Encoding: quoted-printable Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Lloyd & others, > > I find myself really wondering what a longer document would buy us. > > It'd be damn hard to write and agree on, I bet. >=20 > Note the history of aborted/unpublished TCP documents. RFC1323bis, the > whole SACK thing. A long document is doomed before you start. Adding > new/experimental stuff dooms you too. >=20 > What you really want is a very short RFC relying heavily on the > normative mechanism, commenting on the current standards-track RFCs as > normative references, saying what is considered important to > implement, what is worthwhile implementing, possibly known > implementation gotchas, etc. This RFC would go BCP, and be updated by > subsequent BCP docs replacing it. You'd expct a yearly or two-yearly > commentary on the state of the art of TCP, really. >=20 > Given the existing IETF document focus on TCP and the narrow focus of > this doc on that, it's the one instance where normative references in > a BCP doc actually make sense. Because I'm a lazy coder, I always like to look for prior work before starting something. On this topic, I'd like to note a draft that I have been editor on, and wonder if a similar approach to TCP would be one possible way to tackle this topic. See: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-08.= txt br, John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 2 03:14:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25051 for ; Tue, 2 Mar 2004 03:14:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay521-0005J9-QU for tcpm-archive@odin.ietf.org; Tue, 02 Mar 2004 03:13:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i228DbTY020403 for tcpm-archive@odin.ietf.org; Tue, 2 Mar 2004 03:13:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay521-0005J0-BX for tcpm-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 03:13:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25029 for ; Tue, 2 Mar 2004 03:13:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay51z-00040P-00 for tcpm-web-archive@ietf.org; Tue, 02 Mar 2004 03:13:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay50y-0003s7-00 for tcpm-web-archive@ietf.org; Tue, 02 Mar 2004 03:12:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay50a-0003kx-00 for tcpm-web-archive@ietf.org; Tue, 02 Mar 2004 03:12:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay50V-0004yu-4G; Tue, 02 Mar 2004 03:12:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4zs-0004xB-JG for tcpm@optimus.ietf.org; Tue, 02 Mar 2004 03:11:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24897 for ; Tue, 2 Mar 2004 03:11:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4zo-0003i6-00 for tcpm@ietf.org; Tue, 02 Mar 2004 03:11:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4ys-0003bl-00 for tcpm@ietf.org; Tue, 02 Mar 2004 03:10:22 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4y4-0003Pe-00; Tue, 02 Mar 2004 03:09:32 -0500 Received: from jurassic.eng.sun.com ([129.146.83.36]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i22893dO008296; Tue, 2 Mar 2004 00:09:03 -0800 (PST) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i22891pp160228; Tue, 2 Mar 2004 00:09:01 -0800 (PST) Received: (from sunay@localhost) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id i22890o2160220; Tue, 2 Mar 2004 00:09:00 -0800 (PST) From: Sunay Tripathi Message-Id: <200403020809.i22890o2160220@jurassic.eng.sun.com> To: tcpm@ietf.org Date: Tue, 2 Mar 2004 00:09:00 -0800 (PST) CC: tsvwg@ietf.org, end2end-interest@postel.org, Erik Nordmark , "H.K. Jerry Chu" , mankin@psg.com, faber@isi.edu X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [tcpm] Are you interested in TOEs and related issues (Resend) Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, AT the end of the TSVWG session on Monday, I was trying to see if people are interested in discussing TOE (TCP offload Engines) from the prespective of new technology and issues arising out of it. I am not sure if there are any protocol level issues yet that need to be discussed under the scope of IETF (tcpm) charter. I just want to scope out the interest in this area from implementation and integration in the host OS point of view. After the meeting, I already met 5-6 people who are interested in talking about it so we will try and get together sometime wed/thur after the plenary. If there are more people interested, Ted can get us a room or figure out a more structured discussion either this or next IETF meeting. Please drop me a note with you time preference if you are interested and I'll see what we can rig up. A brief background and possible list of things to discuss is listed below. TOE BAckground -------------- In last couple of years, the number of vendors selling TOE based hardware has increased significantly and we at SUN have personally talked to about 2 dozen such vendors. The claim is that TOE will be necessary for 10Gb NICs and for emerging technologies like iSCSI, RDMA, etc. These vendors already have first generation h/w available for Windows and Linux while some of them have moved on to 2nd generation. On Linux, these vendors support TOE by overwriting the S/W stack with their own hooks. With pretty impressive performance and reduction in CPU utilization claims, even the end users have started asking (atleast SUN) about TOE support. Some things to discuss ---------------------- 1) Are you working with TOEs in any way? 2) Have you faced any issues with TOE. Someof them are: - failover. When TOE runs out of resources or doesn't understand some options/features. - Old (and possibly buggy implementations) burned in ASIC which will be hard to upgrade as new modifications are made to TCP (even if they are 2-3 every year). - End to End correctness issues like TOE acking a packet but dying before the data is transfered to host memory. Or accepting the data to be sent out but dying before the packet hits the wire. 3) Any other issues? Cheers, Sunay -- Sunay Tripathi Senior Staff Engineer, Solaris Kernel Networking, Sun MicroSystems Inc. email: sunay@eng.sun.com Phone: 650-786-6007 (W) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 2 19:39:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13681 for ; Tue, 2 Mar 2004 19:39:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKPX-0001ho-MK for tcpm-archive@odin.ietf.org; Tue, 02 Mar 2004 19:38:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i230ctoN006550 for tcpm-archive@odin.ietf.org; Tue, 2 Mar 2004 19:38:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKPW-0001hZ-Uo for tcpm-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 19:38:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13639 for ; Tue, 2 Mar 2004 19:38:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyKPV-0005yz-00 for tcpm-web-archive@ietf.org; Tue, 02 Mar 2004 19:38:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyKOc-0005r6-00 for tcpm-web-archive@ietf.org; Tue, 02 Mar 2004 19:37:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyKNj-0005jC-00 for tcpm-web-archive@ietf.org; Tue, 02 Mar 2004 19:37:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKNh-0000qZ-3I; Tue, 02 Mar 2004 19:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBWa-0002HU-PT for tcpm@optimus.ietf.org; Tue, 02 Mar 2004 10:09:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13423 for ; Tue, 2 Mar 2004 10:09:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBWY-0003cs-00 for tcpm@ietf.org; Tue, 02 Mar 2004 10:09:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBVb-0003Ua-00 for tcpm@ietf.org; Tue, 02 Mar 2004 10:08:36 -0500 Received: from adsl-68-22-232-249.dsl.lgtpmi.ameritech.net ([68.22.232.249] helo=aland.bbn.com) by ietf-mx with esmtp (Exim 4.12) id 1AyBUe-0003Np-00; Tue, 02 Mar 2004 10:07:36 -0500 Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (Postfix) with ESMTP id 2A2221A9; Tue, 2 Mar 2004 10:07:35 -0500 (EST) To: Sunay Tripathi Cc: tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org, Erik Nordmark , "H.K. Jerry Chu" , mankin@psg.com, faber@ISI.EDU In-Reply-To: Your message of "Tue, 02 Mar 2004 00:09:00 PST." <200403020809.i22890o2160220@jurassic.eng.sun.com> Date: Tue, 02 Mar 2004 10:07:35 -0500 From: Craig Partridge Message-Id: <20040302150735.2A2221A9@aland.bbn.com> Subject: [tcpm] Re: [e2e] Are you interested in TOEs and related issues (Resend) Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Well, the interesting thing is we went down this path in the early 1980s and found that TOEs didn't work. If I try to distill all that we learned in the 1980s into one question, I come out with: In the 1980s we discovered that communicating with a TOE over a bus about a TCP connection was as expensive or more expensive than simply handling the TCP connection in the main processor. What about today's TOE designs makes them different? Craig _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Mar 4 00:01:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28200 for ; Thu, 4 Mar 2004 00:01:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aykyo-0000Y6-MZ for tcpm-archive@odin.ietf.org; Thu, 04 Mar 2004 00:01:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24516hQ002109 for tcpm-archive@odin.ietf.org; Thu, 4 Mar 2004 00:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aykyo-0000Xw-HJ for tcpm-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 00:01:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28167 for ; Thu, 4 Mar 2004 00:01:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aykym-0002Bz-00 for tcpm-web-archive@ietf.org; Thu, 04 Mar 2004 00:01:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aykxq-00021G-00 for tcpm-web-archive@ietf.org; Thu, 04 Mar 2004 00:00:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aykwr-0001oB-00 for tcpm-web-archive@ietf.org; Wed, 03 Mar 2004 23:59:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aykwn-0008OP-8x; Wed, 03 Mar 2004 23:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AykwQ-0008Nq-Q9 for tcpm@optimus.ietf.org; Wed, 03 Mar 2004 23:58:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27952 for ; Wed, 3 Mar 2004 23:58:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AykwO-0001fK-00 for tcpm@ietf.org; Wed, 03 Mar 2004 23:58:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aykve-0001Ra-00 for tcpm@ietf.org; Wed, 03 Mar 2004 23:57:51 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AykuV-0000xO-00; Wed, 03 Mar 2004 23:56:39 -0500 Received: from jurassic.eng.sun.com ([129.146.86.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i244txdO004217; Wed, 3 Mar 2004 20:55:59 -0800 (PST) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i244txLj699302; Wed, 3 Mar 2004 20:55:59 -0800 (PST) Received: (from sunay@localhost) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id i244twSG699301; Wed, 3 Mar 2004 20:55:58 -0800 (PST) From: Sunay Tripathi Message-Id: <200403040455.i244twSG699301@jurassic.eng.sun.com> To: craig@bbn.com Date: Wed, 3 Mar 2004 20:55:58 -0800 (PST) CC: tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [tcpm] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Craig, > Well, the interesting thing is we went down this path in the early 1980s > and found that TOEs didn't work. > > If I try to distill all that we learned in the 1980s into one question, I > come out with: > > In the 1980s we discovered that communicating with a TOE over a bus > about a TCP connection was as expensive or more expensive than > simply handling the TCP connection in the main processor. What about > today's TOE designs makes them different? I don't have too much history (1980s predates my career) but there were some attempts in mid 90s to do the same and compared to that, the following reasons seem to be the driving force: 1) Extra processor(s) buried in the TOE for networking processing which is hidden from the kernel and leaves the host CPU to do more application related work. Saves the cost of licences for application which take number of CPU into account (oracle is one such application cited). 2) On low end (1-2 CPU) x86 based machines, cost of adding a processor is much higher than adding a TOE (I personally haven't verified this). 3) For the up and coming 10Gb NICs, TOE will help saturate the link. Some vendors assert that TOE will be required to support 10Gb NICs. 4) Performance reasons. Just the LSO aspect of TOE (sending large chunks of data and letting the TOE split it up in mss size pieces) and ack coalescing gives a pretty good boost (our own prototypes indicates that this is true). The gains are by optimizing data movement and not by offloading protocol processing. 5) TOE is necessary for RDMA, iSCSI etc. for layering reasons. I am not involved with RDMA so someone who is an expert can probably comment on this part. 6) TOE based NIC are already making pretty good headway in embedded space. The technology is already maturing so why not use it in broader market. Note that the above claims are in no particular order of importance and made my TOE vendors in general. Of these, I personally do agree with 1 and 4 but that iteself doesn't mean that TOE will make it in general purpose networking. It would be interesting to see if you and others in the list agree or disagree with these claims. Thanks, Sunay -- Sunay Tripathi Senior Staff Engineer, Solaris Kernel Networking, Sun MicroSystems Inc. email: sunay@eng.sun.com Phone: 650-786-6007 (W) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Mar 4 02:14:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20656 for ; Thu, 4 Mar 2004 02:14:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayn3k-0005Mc-VI for tcpm-archive@odin.ietf.org; Thu, 04 Mar 2004 02:14:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i247EKgT020618 for tcpm-archive@odin.ietf.org; Thu, 4 Mar 2004 02:14:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayn3k-0005MS-KR for tcpm-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 02:14:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20623 for ; Thu, 4 Mar 2004 02:14:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayn3h-0006Bx-00 for tcpm-web-archive@ietf.org; Thu, 04 Mar 2004 02:14:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayn2l-00062D-00 for tcpm-web-archive@ietf.org; Thu, 04 Mar 2004 02:13:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayn2T-0005sH-00 for tcpm-web-archive@ietf.org; Thu, 04 Mar 2004 02:13:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayn2T-0004o4-GI; Thu, 04 Mar 2004 02:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayn1o-0004ZI-Ev for tcpm@optimus.ietf.org; Thu, 04 Mar 2004 02:12:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20438 for ; Thu, 4 Mar 2004 02:12:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayn1k-0005rL-00 for tcpm@ietf.org; Thu, 04 Mar 2004 02:12:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayn0t-0005hJ-00 for tcpm@ietf.org; Thu, 04 Mar 2004 02:11:24 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1Ayn0F-0005UO-00; Thu, 04 Mar 2004 02:10:43 -0500 Received: from jurassic.eng.sun.com ([129.146.81.144]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i247A70J013610; Wed, 3 Mar 2004 23:10:07 -0800 (PST) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i247A6B0727361; Wed, 3 Mar 2004 23:10:06 -0800 (PST) Received: (from sunay@localhost) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id i247A6do727360; Wed, 3 Mar 2004 23:10:06 -0800 (PST) From: Sunay Tripathi Message-Id: <200403040710.i247A6do727360@jurassic.eng.sun.com> In-Reply-To: <000001c401b2$094af3d0$0300a8c0@S2IOtech.com> from Leonid Grossman at "Mar 3, 2004 10:29:22 pm" To: Leonid Grossman Date: Wed, 3 Mar 2004 23:10:06 -0800 (PST) CC: "'Sunay Tripathi'" , craig@bbn.com, tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [tcpm] Re: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > 3) For the up and coming 10Gb NICs, TOE will help saturate > > the link. Some > > vendors assert that TOE will be required to support 10Gb NICs. > > > TOE will bring CPU utilization down of course, but 10GbE NIC will > saturate the link with or without a TOE - much like GbE NICs do it now. I think the TOE vendors meant that single CPU won't be able to saturate the 10Gb NIC on a more meaningful workloads than just a simple throughput tests. Even a 2 CPU machine which wants to do some work also might also get constrained. > > 4) Performance reasons. Just the LSO aspect of TOE (sending > > large chunks of > > data and letting the TOE split it up in mss size pieces) and ack > > coalescing gives a pretty good boost (our own prototypes > > indicates that > > this is true). > > Just curious - in your testing, how much CPU is freed up by the ack > coalescing? We actually always try to run the CPUs to saturation (keep increasing the load) and we can get a double digit percentage boost on a web like workload (multiple simultaneous connections). I didn't verify exactly where the gains were coming from but my feeling was that more efficient data movement and better locality was contributing to bulk of the gains. > >The gains are by optimizing data movement and not by > > offloading protocol processing. > > LSO is a 'stateless' offload (much like checksum offload) so one doesn't > need a TOE to support it; It depends. If the kernel does a write based on open window, then yes you are right. But if you have full TOE and you pass large chunks of data to TOE (does wonder when sendfile/sendfilev is in play) and let TOE figure out when to send it, the gains increase. In the later case, TOE needs teh TCP state. > most modern NICs (including our 10GbE Adapter) do LSO. Also, for normal > frames LSO has quite dramatic effect at 10GbE rates, but for Jumbo > frames performance gain diminishes to ~7%. Do you have any insight on why you would see a degradation with Jumbo frames? As long as you are stateless, the jumbograms should show no degradation. Thanks, Sunay > > > > 5) TOE is necessary for RDMA, iSCSI etc. for layering > > reasons. I am not > > involved with RDMA so someone who is an expert can > > probably comment on > > this part. > > 6) TOE based NIC are already making pretty good headway in > > embedded space. > > The technology is already maturing so why not use it in > > broader market. > > > > Note that the above claims are in no particular order of > > importance and made my TOE vendors in general. Of these, I > > personally do agree with 1 and 4 but that iteself doesn't > > mean that TOE will make it in general purpose networking. > > > > It would be interesting to see if you and others in the list > > agree or disagree with these claims. > > > > Thanks, > > Sunay > > > > -- > > > > Sunay Tripathi > > Senior Staff Engineer, > > Solaris Kernel Networking, > > Sun MicroSystems Inc. > > > > email: sunay@eng.sun.com Phone: 650-786-6007 (W) > > > > > > > > > > > Regards, > Leonid Grossman > www.s2io.com > > > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/tsvwg > > > -- Sunay Tripathi Solaris Kernel Networking, Sun MicroSystems Inc. email: sunay@eng.sun.com Phone: 650-786-6007 (W) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Mar 4 08:02:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17362 for ; Thu, 4 Mar 2004 08:02:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AysTr-00026A-Qp for tcpm-archive@odin.ietf.org; Thu, 04 Mar 2004 08:01:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24D1dW1008065 for tcpm-archive@odin.ietf.org; Thu, 4 Mar 2004 08:01:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AysTr-000260-K9 for tcpm-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 08:01:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17327 for ; Thu, 4 Mar 2004 08:01:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AysTq-0006VS-00 for tcpm-web-archive@ietf.org; Thu, 04 Mar 2004 08:01:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AysSw-0006Ix-00 for tcpm-web-archive@ietf.org; Thu, 04 Mar 2004 08:00:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AysSP-000676-00 for tcpm-web-archive@ietf.org; Thu, 04 Mar 2004 08:00:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AysSL-0001sG-SK; Thu, 04 Mar 2004 08:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AysRk-0001pl-E3 for tcpm@optimus.ietf.org; Thu, 04 Mar 2004 07:59:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17218 for ; Thu, 4 Mar 2004 07:59:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AysRj-00063k-00 for tcpm@ietf.org; Thu, 04 Mar 2004 07:59:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AysQl-0005qe-00 for tcpm@ietf.org; Thu, 04 Mar 2004 07:58:27 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AysPm-0005Uy-00; Thu, 04 Mar 2004 07:57:27 -0500 Received: from jurassic.eng.sun.com ([129.146.84.45]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i24Cut0J007037; Thu, 4 Mar 2004 04:56:56 -0800 (PST) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i24Cus8c874648; Thu, 4 Mar 2004 04:56:54 -0800 (PST) Received: (from sunay@localhost) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id i24CurhC874630; Thu, 4 Mar 2004 04:56:53 -0800 (PST) From: Sunay Tripathi Message-Id: <200403041256.i24CurhC874630@jurassic.eng.sun.com> To: leonid.grossman@s2io.com Date: Thu, 4 Mar 2004 04:56:52 -0800 (PST) CC: tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [tcpm] Re: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Leonid, > > most modern NICs (including our 10GbE Adapter) do LSO. Also, for normal > > frames LSO has quite dramatic effect at 10GbE rates, but for Jumbo > > frames performance gain diminishes to ~7%. > Do you have any insight on why you would see a degradation with Jumbo > frames? As long as you are stateless, the jumbograms should show > no degradation. I apologize. Jeremy Harris pointed out that I misread '~' for '-'. So what you say makes sense now :) Thanks, Sunay -- Sunay Tripathi Senior Staff Engineer, Solaris Kernel Networking, Sun MicroSystems Inc. email: sunay@eng.sun.com Phone: 650-786-6007 (W) ----- End of forwarded message (env-from sunay) ----- -- Sunay Tripathi Solaris Kernel Networking, Sun MicroSystems Inc. email: sunay@eng.sun.com Phone: 650-786-6007 (W) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Mar 5 01:37:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08844 for ; Fri, 5 Mar 2004 01:37:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az8xV-0000Tl-IN for tcpm-archive@odin.ietf.org; Fri, 05 Mar 2004 01:37:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i256bLYH001837 for tcpm-archive@odin.ietf.org; Fri, 5 Mar 2004 01:37:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az8xV-0000TS-8A for tcpm-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 01:37:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08838 for ; Fri, 5 Mar 2004 01:37:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az8xS-000124-00 for tcpm-web-archive@ietf.org; Fri, 05 Mar 2004 01:37:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az8wX-0000rV-00 for tcpm-web-archive@ietf.org; Fri, 05 Mar 2004 01:36:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az8wE-0000go-00 for tcpm-web-archive@ietf.org; Fri, 05 Mar 2004 01:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az8wE-0000DE-FE; Fri, 05 Mar 2004 01:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az8vY-0000BS-0X for tcpm@optimus.ietf.org; Fri, 05 Mar 2004 01:35:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08715 for ; Fri, 5 Mar 2004 01:35:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az8vU-0000f1-00 for tcpm@ietf.org; Fri, 05 Mar 2004 01:35:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az8uc-0000UF-00 for tcpm@ietf.org; Fri, 05 Mar 2004 01:34:22 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1Az8u0-0000Jc-00; Fri, 05 Mar 2004 01:33:44 -0500 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id ABA692F16; Fri, 5 Mar 2004 01:33:45 -0500 (EST) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26336-07; Fri, 5 Mar 2004 01:33:45 -0500 (EST) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id D8F702EF0; Fri, 5 Mar 2004 01:33:44 -0500 (EST) To: Sunay Tripathi Cc: tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org References: <200403040455.i244twSG699301@jurassic.eng.sun.com> From: stanislav shalunov Date: 05 Mar 2004 01:33:53 -0500 In-Reply-To: <200403040455.i244twSG699301@jurassic.eng.sun.com> Message-ID: <86y8qf6bvy.fsf@abel.internet2.edu> Lines: 51 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner Subject: [tcpm] Re: Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sunay Tripathi writes: > 1) Extra processor(s) buried in the TOE for networking processing which is > hidden from the kernel and leaves the host CPU to do more application > related work. Saves the cost of licences for application which take > number of CPU into account (oracle is one such application cited). One would hope TCP design would not be guided by Oracle licensing quirks. > 2) On low end (1-2 CPU) x86 based machines, cost of adding a processor > is much higher than adding a TOE (I personally haven't verified this). It's not obvious why this should necessarily be the case, given that it is likely that there will continue to be quite a bit more general-purpose CPUs made than TCP offload engines. > 3) For the up and coming 10Gb NICs, TOE will help saturate the link. Some > vendors assert that TOE will be required to support 10Gb NICs. Right now, one can do almost 8Gb/s with a single TCP stream over 10GE (let's say 5 or 6Gb/s with more common hardware). The limiting factor is currently host bus speed. There's nothing (except for compression on the bus side, but it should be clear we're not going there) that an offload engine can do about host bus speed. By the time host busses faster than 10Gb/s are commonly available, pretty routine x86 box should handle 10GE saturation. > 4) Performance reasons. Just the LSO aspect of TOE (sending large chunks of > data and letting the TOE split it up in mss size pieces) and ack > coalescing gives a pretty good boost (our own prototypes indicates that > this is true). The gains are by optimizing data movement and not by > offloading protocol processing. Here I would agree with the unnamed TOE vendor whom you're paraphrasing (and with Jerry Chu's comments in this thread). Ethernet frame size (1500 bytes or even 9kB) is very small; we'd be in a better world if we could specify the MTU in units of time (the number of CRC bits would have to scale up as well, of course). TCP offload engines could be a kludge that would help to work around this deficiency in Ethernet. Note that since even at 10Gb/s one CPU is enough to saturate the link with 9kB packets, the need for this work-around is not at all pressing. Given the potential harmful effects (undetected errors on the host bus, difficulty in patching stale or buggy TCP code, etc.), one would probably be better served by concentrating on the deployment of jumbo frames. The investment to support jumbo frames has largely already been made, so why not extract all we can from it first? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Mar 5 12:16:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17988 for ; Fri, 5 Mar 2004 12:16:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzIvH-00063e-9K for tcpm-archive@odin.ietf.org; Fri, 05 Mar 2004 12:15:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25HFhsU023280 for tcpm-archive@odin.ietf.org; Fri, 5 Mar 2004 12:15:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzIvH-00063P-39 for tcpm-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 12:15:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17859 for ; Fri, 5 Mar 2004 12:15:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzIvD-00079h-00 for tcpm-web-archive@ietf.org; Fri, 05 Mar 2004 12:15:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzIsq-0006Vx-00 for tcpm-web-archive@ietf.org; Fri, 05 Mar 2004 12:13:13 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AzIra-0006En-01 for tcpm-web-archive@ietf.org; Fri, 05 Mar 2004 12:11:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AzIl1-0002tN-Pz for tcpm-web-archive@ietf.org; Fri, 05 Mar 2004 12:05:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzIkx-0004lX-9u; Fri, 05 Mar 2004 12:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzIkl-0004j9-18 for tcpm@optimus.ietf.org; Fri, 05 Mar 2004 12:04:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17464 for ; Fri, 5 Mar 2004 12:04:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzIkh-00051Y-00 for tcpm@ietf.org; Fri, 05 Mar 2004 12:04:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzIjl-0004rG-00 for tcpm@ietf.org; Fri, 05 Mar 2004 12:03:50 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AzIjG-0004ft-00; Fri, 05 Mar 2004 12:03:18 -0500 Received: from bu-ewat02-01.uk.sun.com ([129.156.199.2]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i25H2k0J019227; Fri, 5 Mar 2004 09:02:47 -0800 (PST) Received: from uk.sun.com (vpn-129-156-96-31.EMEA.Sun.COM [129.156.96.31]) by bu-ewat02-01.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i25H2hWH023332; Fri, 5 Mar 2004 17:02:43 GMT Message-ID: <4048B2AD.9000903@uk.sun.com> Date: Fri, 05 Mar 2004 17:02:37 +0000 From: Jeremy Harris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.6) Gecko/20040113 X-Accept-Language: en, en-us MIME-Version: 1.0 To: stanislav shalunov CC: Sunay Tripathi , tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org Subject: Re: [tcpm] Re: Are you interested in TOEs and related issues References: <200403040455.i244twSG699301@jurassic.eng.sun.com> <86y8qf6bvy.fsf@abel.internet2.edu> In-Reply-To: <86y8qf6bvy.fsf@abel.internet2.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit stanislav shalunov wrote: > Sunay Tripathi writes: >>2) On low end (1-2 CPU) x86 based machines, cost of adding a processor >> is much higher than adding a TOE (I personally haven't verified this). > > > It's not obvious why this should necessarily be the case, given that > it is likely that there will continue to be quite a bit more > general-purpose CPUs made than TCP offload engines. It's because cache-coherency is expensive. x86 boxes have traditionally avoided playing far into this space. Looked at from that angle, TOE is towards the far end of the ncNUMA scale, and coherency is managed by software. - Jeremy _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Sun Mar 7 18:01:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10162 for ; Sun, 7 Mar 2004 18:01:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B07GQ-000835-LV for tcpm-archive@odin.ietf.org; Sun, 07 Mar 2004 18:00:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i27N0sGM030937 for tcpm-archive@odin.ietf.org; Sun, 7 Mar 2004 18:00:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B07GQ-00082p-FY for tcpm-web-archive@optimus.ietf.org; Sun, 07 Mar 2004 18:00:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10015 for ; Sun, 7 Mar 2004 18:00:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B07GN-00013N-00 for tcpm-web-archive@ietf.org; Sun, 07 Mar 2004 18:00:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B07FH-0000kJ-00 for tcpm-web-archive@ietf.org; Sun, 07 Mar 2004 17:59:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B07E4-0000Vb-0D for tcpm-web-archive@ietf.org; Sun, 07 Mar 2004 17:58:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0704-0006nG-Sy; Sun, 07 Mar 2004 17:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B06zW-0006lb-QN for tcpm@optimus.ietf.org; Sun, 07 Mar 2004 17:43:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09411 for ; Sun, 7 Mar 2004 17:43:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B06zU-0006VE-00 for tcpm@irtf.org; Sun, 07 Mar 2004 17:43:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B06yW-0006Fx-00 for tcpm@irtf.org; Sun, 07 Mar 2004 17:42:26 -0500 Received: from ms1.city.ac.uk ([138.40.12.21]) by ietf-mx with esmtp (Exim 4.12) id 1B06wu-0005mg-00 for tcpm@irtf.org; Sun, 07 Mar 2004 17:40:44 -0500 Received: from mailswitch.city.ac.uk ([138.40.12.12] helo=mailswitch) by ms1.city.ac.uk with smtp (Exim 4.20) id 1B06tA-0001XK-51 for tcpm@irtf.org; Sun, 07 Mar 2004 22:36:52 +0000 Received: from frc-703c.city.ac.uk ([138.40.89.29] helo=WirelessLab2) by mailswitch with esmtp (Exim 3.16 #5) id 1B06t7-0005uH-00 for tcpm@irtf.org; Sun, 07 Mar 2004 22:36:50 +0000 From: "Ehsan Hamadani" To: Date: Sun, 7 Mar 2004 22:35:30 -0000 Message-ID: <000701c40494$838af750$1d59288a@WirelessLab2> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C40494.838AF750" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-MailScanner-Information: Please contact Computing Services for more information X-City-MailScanner: Found to be clean X-City-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-0.4, required 5, BAYES_30 -0.93, HTML_80_90 0.50) Subject: [tcpm] TCP-F Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C40494.838AF750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, In TCP-F (TCP feedback based scheme), it has been proposed that when a specific link becomes invalid, the failure point (FP) will sends Route Failure Notification (RFN) message to sender and then the sender goes to snooze mode and waits for Route Re-establishment Notification (RRN) message. My question here is that, when multiple link failures happen, does the sender accept the RRN message only from the FP node that has sent RFN message or it will accept that from any intermediate node than have learned new route to destination? I would appreciate if someone can help me with that. Regards, Ehsan -------------------------------------------------------------------- Ehsan Hamadani, PhD Student School of Engineering & Mathematical Science CITY University London, EC1V 0HB United Kingdom Phone:+44(0)2070403886 ------=_NextPart_000_0008_01C40494.838AF750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

In TCP-F (TCP feedback based scheme), it has been = proposed that when a specific link becomes invalid, the failure point (FP) will = sends Route Failure Notification (RFN) message to sender and then the sender = goes to snooze mode and waits for Route Re-establishment Notification (RRN) = message. My question here is that, when multiple link failures happen, does the = sender accept the RRN message only from the FP node that has sent RFN message = or it will accept that from any intermediate node than have learned new route = to destination?

 

I would appreciate if someone can help me with = that.

 

Regards,

 

Ehsan     =

 

 

-------------------------------------= -------------------------------

Ehsan Hamadani, PhD<= /font> Student

School of Engineering= & Mathematical Science

CITY = University

London, EC1V = 0HB

United = Kingdom

 

Phone:+44(0)2070403886<= span style=3D'mso-no-proof:yes'>

 

 

 

 

------=_NextPart_000_0008_01C40494.838AF750-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Mar 8 11:26:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12010 for ; Mon, 8 Mar 2004 11:26:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0NZi-0003L3-KN for tcpm-archive@odin.ietf.org; Mon, 08 Mar 2004 11:25:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28GPsB7012832 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 11:25:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0NZi-0003Ks-Dg for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 11:25:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11990 for ; Mon, 8 Mar 2004 11:25:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0NZh-00007n-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 11:25:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0NYu-0007jG-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 11:25:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0NXv-0007Um-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 11:24:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0NXs-00033V-6e; Mon, 08 Mar 2004 11:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0NWy-0002qM-GQ for tcpm@optimus.ietf.org; Mon, 08 Mar 2004 11:23:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11696 for ; Mon, 8 Mar 2004 11:23:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0NWx-0007DZ-00 for tcpm@ietf.org; Mon, 08 Mar 2004 11:23:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0NVC-0006eI-00 for tcpm@ietf.org; Mon, 08 Mar 2004 11:21:16 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1B0NSt-00065f-00 for tcpm@ietf.org; Mon, 08 Mar 2004 11:18:51 -0500 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i28GImp24797; Mon, 8 Mar 2004 08:18:48 -0800 (PST) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.12.10/8.12.10) with ESMTP id i28GImDE001065; Mon, 8 Mar 2004 08:18:48 -0800 (PST) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.12.10/8.12.10/Submit) id i28GImRm001064; Mon, 8 Mar 2004 08:18:48 -0800 (PST) (envelope-from faber) Date: Mon, 8 Mar 2004 08:18:48 -0800 From: Ted Faber To: Ehsan Hamadani Cc: tcpm@ietf.org Message-ID: <20040308161848.GE252@pun.isi.edu> References: <001401c4048c$1f4c1970$1d59288a@WirelessLab2> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="10jrOL3x2xqLmOsH" Content-Disposition: inline In-Reply-To: <001401c4048c$1f4c1970$1d59288a@WirelessLab2> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber Subject: [tcpm] Re: Question on TCP-F Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --10jrOL3x2xqLmOsH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Mar 07, 2004 at 09:35:28PM -0000, Ehsan Hamadani wrote: > Dear all, > > In TCP-F (TCP feedback based scheme), it has been proposed that when a > specific link becomes invalid, the failure point (FP) will sends Route > Failure Notification (RFN) message to sender and then the sender goes to > snooze mode and waits for Route Re-establishment Notification (RRN) > message. My question here is that, does the sender accept the RRN > message only from the FP node that has sent RFN message or it will > accept that from any intermediate node than have learned new route to > destination? I'll be needing some context for that. Point me toward a TCP-F document or paper. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --10jrOL3x2xqLmOsH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFATJznaUz3f+Zf+XsRAk8SAKCVqSayfNh8Dr/7RYU0jXKaCsOoHQCfcTkN FoCdRjWnrqbHMPjUNdPyvbM= =VoLa -----END PGP SIGNATURE----- --10jrOL3x2xqLmOsH-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Mar 8 14:40:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23264 for ; Mon, 8 Mar 2004 14:40:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0QbU-0003Bl-Dr for tcpm-archive@odin.ietf.org; Mon, 08 Mar 2004 14:39:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28JduoF012253 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 14:39:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0QbU-0003BY-6O for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 14:39:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23242 for ; Mon, 8 Mar 2004 14:39:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0QbR-00062e-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 14:39:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0QaX-0005tI-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 14:38:57 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0QZj-0005jm-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 14:38:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0QZj-0006gq-W3 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 14:38:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0QZe-0002wr-85; Mon, 08 Mar 2004 14:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0QZa-0002w2-GB for tcpm@optimus.ietf.org; Mon, 08 Mar 2004 14:37:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23115 for ; Mon, 8 Mar 2004 14:37:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0QZX-0005in-00 for tcpm@ietf.org; Mon, 08 Mar 2004 14:37:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0QYg-0005ZW-00 for tcpm@ietf.org; Mon, 08 Mar 2004 14:37:02 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1B0QYC-0005Q9-00 for tcpm@ietf.org; Mon, 08 Mar 2004 14:36:32 -0500 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i28JaWp19827 for ; Mon, 8 Mar 2004 11:36:32 -0800 (PST) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.12.10/8.12.10) with ESMTP id i28JaWDE004773 for ; Mon, 8 Mar 2004 11:36:32 -0800 (PST) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.12.10/8.12.10/Submit) id i28JaWvw004772 for tcpm@ietf.org; Mon, 8 Mar 2004 11:36:32 -0800 (PST) (envelope-from faber) Date: Mon, 8 Mar 2004 11:36:32 -0800 From: Ted Faber To: tcpm@ietf.org Message-ID: <20040308193631.GJ2428@pun.isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYo4Elh1vtcYNvbq" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber Subject: [tcpm] Draft minutes and presentations from Korea Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --zYo4Elh1vtcYNvbq Content-Type: multipart/mixed; boundary="4BlIp4fARb6QCoOq" Content-Disposition: inline --4BlIp4fARb6QCoOq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The draft minutes from the tcpm meeting at the 59th IETF in Korea are attached. Please send comments or corrections to either the list or Mark and myself. The minutes are also available from http://www.isi.edu/tcpm/ along with copies of the presentations. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --4BlIp4fARb6QCoOq Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tcpm-minutes.txt" TCPM Working Group Draft Minutes as of 8 Mar 2004 The meeting was chaired by Ted Faber. These minutes were edited by Ted Faber from notes by Matt Zekauskas. ===================================================================== 1. Overview of the charter and milestones --Ted Faber Ted addressed some slides going over the charter and group goals. (See slides.) Why form a new group? * This group was created to focus efforts on TCP tweaks. Take revisions and documents that have been "floating around", and push them forward. * It will also serve as a forum to attract new TCP work where TCP expertise can be focused to evaluate the work carefully and move forward. -- Milestone discussion: -- FRTO draft (draft-ietf-tsvwg-tcp-frto-01.txt) Discussed and moved fwd, see below. Roadmap draft (draft-duke-tcp-roadmap-00.txt) adopt directly into WG Ted's impressions: draft good in coverage, but needs annotations "stuff not used much" the draft calls these "Deprecated TCP Extensions". Ted thinks the discussions of these should include more information about why the extensions were deprecated and the lessons one can take from them. Of course editors and group will have the final word. Ted mentioned that there's a discussion on e2e about a TCP consolidation document. Ted is not clear on the difference between what they're asking for and a roadmap, and Ted would rather see that energy in the roadmap. We're actively looking for editors and contributors. -- DCR & reordering. (blanton-tcp-reordering-00.txt draft-bhandarkar-tcp-dcr-00.txt) Need to get with authors and gauge interest. Ted suspects authors will need to drive. -- 1323 revamp: Dave Borman presented, see below. Goal is depending on how big a revamp happens either push to Draft Standard, or "revalidate" at Proposed Standard. -- End of Milestone discussion -- Presentation of other documents that might be of interest to TCPM: From the slide: SACK 2018 update? Merge with 2883 (DSACK)? Congestion Control Update 2581 (back to PS?) merge 3390 (initial cwnd) merge 3042 (limited transmit) merge 2582 (Reno bugfix/NewReno) merge 3465 (App. Byte Count security) 2861 to PS (cwnd validation) 2988 to DS (RTO timer comp) 3517 to PS? into 2018 update? (DSACK loss rec) [NB: after the meeting Kevin Fall pointed out to me that Ted had mischaracterized RFC 3517, which is already a Proposed Standard, and probably doesn't need to move forward any time soon.] Again, these will be come work items based on group interest, though no one leapt up to take one on. -- Closed with a "Drivers Wanted" plea. Allison Mankin encouraged people to volunteer to take things on. [Thanks] Sally Floyd: "I wouldn't go so far as to say that I was interested, but I agree that it is necessary to do." [Sally's Restatement: I am *willing* to do my share of the work, just not necessarily *excited* about having to do it.] ===================================================================== 2. FRTO presentation --Pasi Sarolahti. draft: draft-ietf-tsvwg-tcp-frto-01.txt The draft has been around for a while. Started in June 2002 as individual submission, to TSV last october. detecting spurious RTOs. (where a lost or delayed ack causes an RTO time out) Send a little new data during retransmit and looks for immediate acks of that new data. Can be combined with SACK -- List of editorial changes from last version -- They have been working for a while... want to submit for pub as Experimental. Ted called for comments: Sally Floyd: I have not been paying attention to the discussion on the mailing list. Has the discussion converged to consensus? Are there outstanding technical points of contention? [Not verbatim] Pasi: There has been no real discussion since June. Comments have mostly editorial, not technical. There have been some individual nits. nothing related to algorithm. I believe that the draft is stable. Ted says what we're going to do is make another pass for NITs, on tcpm, and then on ML go to WGLC. Ted doesn't know whether to ask for a hum or some other consensus indication in a mixed meeting. Allison Mankin: I talked to Jon in the back, who's the responsible AD nits review is just nits, no humming to do. Action is to do a nits pass and got to WGLC on the list. ============================================================================ 3. RFC 1323 update --David Borman Large windows & timestamps RFC that has been proposed for way too long. at last IETF, gave presentation... this is what's happened since. Nothing has really changed... no new draft, no discussion. But we are now part of tcpm wg. This is a good thing. Outstanding issues... -- RTO adjustments When using timestamps and calculating RTTs frequently, need to adjust weighting factor on estimates. There seems to be general consensus on this issue. -- Enabling timestamps/PAWS midstream Do most current TCP implementations properly handle unknown options mid-stream? Originally, implementations crash when unknown options appear in the middle of a tcp connection. We would have to think about reliability in that context - i.e. would allowing timestamp/PAWS renegotiation cause more crashed than improved performance? -- PAWS & DF bit Without DF bit set, PAWS would protect 1st fragment not the rest. Only the 16-bit IP ID would protect them. The pathological case is that the 1st frag arrives, another packet fills in hole. then perpetually all assembled incorrectly. 'TCP cksum should notice'. Matt Mathis points out that this is a general ugly problem with IP reassembly and points out similar problems with UDP transport. Vern Paxson mentions a related problem: every 65000 of those collisions will be missed by the TCP checksum. That's even worse! Matt Mathis points out that the real pathological condition is the one that Dave mentioned where each contains the data Vern alluded to - every packet is misassembled in such a way that the checksum misses the corruption. He goes on to say that he's meaning to write RFC "Fragmentation Considered Really Really Really Harmful" because pathological case horrible. Someone says that because of probs with MTU discovery, people ignoring DF bits -- really bad. Ted says that this is all good discussion and I'd like to see it get into the new document. -- RTTM estimate from dup ack. discussed on ML (different mailing lists). If a connection is idle for long period of time, and 1st ack is lost, when get a dupack, it could have good information for RTT, but that means changing what's in document. Concern: even if get everything right and correctly id dupack (potential for random window update coming in) how interoperate with existing implementations? (How do we know that the other side giving is good information in a dupack timestamp. Even though the idea is good, you can't do anything with it. "not a real big problem out there" -- not clear who said this Dave points out that TCP doesn't define what dupack is. all know one when see one, but... we need a precise definition. -- non-technical issues: Connections with other work: HSTCP and others depend on window scaling Eifel wants ts option Should the revision disucss SACK? Originally SACK was part of 1323. Split originally because SACK needed baking) He thinks SACK is further ahead for stds progress. We need to revisit the MUST/SHOULD language. what about last 10 yrs of experience? include clarifications... draft-jacobson-tsvwg-1323bis-00.txt will expire RSN This has been discussed on e2e mailing list, but David will attempt to steer traffic to tcpm. Ted ask Dave to please summarize to TCPM. Dave and Ted talk about generating a numbered list of items, so that we can check items off as we go. Jon Peterson says the IESG is making issue trackers available to WG chairs. Check with Rob Austein... there is one on the psg.com site. David is mainly looking for things to move along. He has tried to bring up the topic of a revised document a couple of times, but it hasn't advanced in part because we do not having a precise way of saying when an issue is closed. Sunay from sun microsystems made an appeal for interest in outboard protocol processing. [This has since surfaced on the ML and e2e.] --4BlIp4fARb6QCoOq-- --zYo4Elh1vtcYNvbq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFATMs/aUz3f+Zf+XsRAuPWAJ0ZQg31embofYtFVkPE5C+PT1bh2gCeM147 uGQydiPBiVFP1aNW5HqGkS8= =5HoQ -----END PGP SIGNATURE----- --zYo4Elh1vtcYNvbq-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Mar 8 17:29:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07410 for ; Mon, 8 Mar 2004 17:29:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFK-0000v4-Qi for tcpm-archive@odin.ietf.org; Mon, 08 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MTE6M003528 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFK-0000up-LN for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07353 for ; Mon, 8 Mar 2004 17:29:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TFI-0000ol-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:29:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TES-0000ce-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDM-0000Pe-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDC-0000Ek-P8; Mon, 08 Mar 2004 17:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyxEA-0006Zg-IO for tcpm@optimus.ietf.org; Thu, 04 Mar 2004 13:05:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04745 for ; Thu, 4 Mar 2004 13:05:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyxE8-0000bY-00 for tcpm@ietf.org; Thu, 04 Mar 2004 13:05:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyxDB-0000PE-00 for tcpm@ietf.org; Thu, 04 Mar 2004 13:04:46 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AyxCK-00004E-00 for tcpm@ietf.org; Thu, 04 Mar 2004 13:03:52 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 Mar 2004 10:15:58 +0000 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i24I3JiQ019303 for ; Thu, 4 Mar 2004 10:03:20 -0800 (PST) Received: from localhost.localdomain ([64.101.96.184]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA18242 for ; Thu, 4 Mar 2004 13:03:19 -0500 (EST) Received: (from salehi@localhost) by localhost.localdomain (8.11.2/8.11.2) id i24I3IN08321; Thu, 4 Mar 2004 10:03:18 -0800 From: Nader Salehi MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16455.28518.346168.233445@gargle.gargle.HOWL> Date: Thu, 4 Mar 2004 10:03:18 -0800 To: tcpm@ietf.org X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid X-URL: http://www.cisco.com Content-Transfer-Encoding: 7bit Subject: [tcpm] Info on TOE Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi There, Could someone please point me to any document about TOE. Thanks, Nader _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Mar 8 17:29:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07441 for ; Mon, 8 Mar 2004 17:29:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFL-0000vO-LC for tcpm-archive@odin.ietf.org; Mon, 08 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MTF8A003548 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFL-0000v9-EC for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07357 for ; Mon, 8 Mar 2004 17:29:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TFJ-0000oq-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:29:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TES-0000cn-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDM-0000Pf-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDB-0000Cs-OF; Mon, 08 Mar 2004 17:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aytcw-0000sc-UN for tcpm@optimus.ietf.org; Thu, 04 Mar 2004 09:15:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20925 for ; Thu, 4 Mar 2004 09:15:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aytcv-0006HB-00 for tcpm@ietf.org; Thu, 04 Mar 2004 09:15:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aytbr-0005yI-00 for tcpm@ietf.org; Thu, 04 Mar 2004 09:13:59 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AytaV-0005MH-00; Thu, 04 Mar 2004 09:12:35 -0500 Received: from jurassic.eng.sun.com ([129.146.86.38]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i24EC40J008803; Thu, 4 Mar 2004 06:12:04 -0800 (PST) Received: from unknown (punchin-hkchu.SFBay.Sun.COM [192.9.61.13]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with SMTP id i24EBrWh892234; Thu, 4 Mar 2004 06:12:02 -0800 (PST) Message-Id: <200403041412.i24EBrWh892234@jurassic.eng.sun.com> Date: Thu, 4 Mar 2004 23:11:36 -0800 (PST) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" To: leonid.grossman@s2io.com Cc: tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Zs+Kc3pMF7jcEttokUcqHg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 i86pc i386 Subject: [tcpm] Re: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,DATE_IN_FUTURE_12_24 autolearn=no version=2.60 > > ... >> >The gains are by optimizing data movement and not by >> > offloading protocol processing. >> >> LSO is a 'stateless' offload (much like checksum offload) so one doesn't >> need a TOE to support it; > >It depends. If the kernel does a write based on open window, then yes >you are right. But if you have full TOE and you pass large chunks of >data to TOE (does wonder when sendfile/sendfilev is in play) and let >TOE figure out when to send it, the gains increase. In the later case, >TOE needs teh TCP state. > >> most modern NICs (including our 10GbE Adapter) do LSO. Also, for normal >> frames LSO has quite dramatic effect at 10GbE rates, but for Jumbo >> frames performance gain diminishes to ~7%. One fundamental performance problem high speed Ethernet imposes on the hosts is from the tiny size of the standard Ethernet frames. It's almost like throwing ATM cells at the host 10 years ago but without any hardware adaptation. LSO and ack coalescing are the adpatation layer for Ethernet cells. They can help to alleviate this problem but unfortunately they either induce, or live on traffic bursts. (Just imagine how useful LSO will be if the ack-every-other-pkt policy provides only 2-MSS worth of usable window, and how much back-to-back bursts will be caused by coaliscing many acks.) Bursty traffic may be ok for LAN, but is considered evil for WAN. TOE doesn't suffer this problem (since it is stateful), and may be a necessary evil until jumbo frames become universal. Jerry > >Do you have any insight on why you would see a degradation with Jumbo >frames? As long as you are stateless, the jumbograms should show >no degradation. > >Thanks, >Sunay > > >> >> >> > 5) TOE is necessary for RDMA, iSCSI etc. for layering >> > reasons. I am not >> > involved with RDMA so someone who is an expert can >> > probably comment on >> > this part. >> > 6) TOE based NIC are already making pretty good headway in >> > embedded space. >> > The technology is already maturing so why not use it in >> > broader market. >> > >> > Note that the above claims are in no particular order of >> > importance and made my TOE vendors in general. Of these, I >> > personally do agree with 1 and 4 but that iteself doesn't >> > mean that TOE will make it in general purpose networking. >> > >> > It would be interesting to see if you and others in the list >> > agree or disagree with these claims. >> > >> > Thanks, >> > Sunay >> > >> > -- >> > >> > Sunay Tripathi >> > Senior Staff Engineer, >> > Solaris Kernel Networking, >> > Sun MicroSystems Inc. >> > >> > email: sunay@eng.sun.com Phone: 650-786-6007 (W) >> > >> > >> > >> > >> >> >> Regards, >> Leonid Grossman >> www.s2io.com >> >> >> > _______________________________________________ >> > tsvwg mailing list >> > tsvwg@ietf.org >> > https://www1.ietf.org/mailman/listinfo/tsvwg >> > >> > > >-- >Sunay Tripathi >Solaris Kernel Networking, >Sun MicroSystems Inc. > >email: sunay@eng.sun.com Phone: 650-786-6007 (W) > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Mar 8 17:29:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07458 for ; Mon, 8 Mar 2004 17:29:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFO-0000vq-OM for tcpm-archive@odin.ietf.org; Mon, 08 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MTIog003576 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFO-0000vb-Jp for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07362 for ; Mon, 8 Mar 2004 17:29:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TFM-0000pI-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:29:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEW-0000dK-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDQ-0000Q7-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDI-0000O7-Ki; Mon, 08 Mar 2004 17:27:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Siv-0006PK-U1 for tcpm@optimus.ietf.org; Mon, 08 Mar 2004 16:55:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05194 for ; Mon, 8 Mar 2004 16:55:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Sit-00029D-00 for tcpm@ietf.org; Mon, 08 Mar 2004 16:55:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Sfk-0001Vq-00 for tcpm@ietf.org; Mon, 08 Mar 2004 16:52:29 -0500 Received: from adsl-68-22-232-249.dsl.lgtpmi.ameritech.net ([68.22.232.249] helo=aland.bbn.com) by ietf-mx with esmtp (Exim 4.12) id 1B0Se3-000155-00; Mon, 08 Mar 2004 16:50:44 -0500 Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (Postfix) with ESMTP id 9182A1A4; Mon, 8 Mar 2004 16:50:43 -0500 (EST) To: "Stephen Suryaputra" Cc: tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org In-Reply-To: Your message of "Mon, 08 Mar 2004 12:42:21 EST." <8052E2EA753D144EB906B7A7AA399714022A05B7@mailserv.hatteras.com> Date: Mon, 08 Mar 2004 16:50:43 -0500 From: Craig Partridge Message-Id: <20040308215043.9182A1A4@aland.bbn.com> Subject: [tcpm] Re: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <8052E2EA753D144EB906B7A7AA399714022A05B7@mailserv.hatteras.com>, "S tephen Suryaputra" writes: >I think Marko is referring to the situation when there is a congestion. >Because of that the queue builds up and if the queue space is in term >of the number of packets, then a bunch of small packets can potentially >dominate the queue and left little room for large packets eventhough >there is a space in the buffer to accomodate the large ones. Well, I tried to nail this down by setting it up as a queueing system but that's awfully hard. Here's the cut: 1. Basically you have a general arrival process delivering pieces of work of variable size, at arrival rate A subject to the condition that if there's an event of size w1 at time t1, then the next event cannot arrive sooner than time t1+w1. [I.e. A(t2,w2) - A(t1,w1) >= w1]. 2. You then have a series of queues Q1-Qn attached to servers S1-Sn that serve events at a fixed rate R, where R1 <= A (i.e. we can handle the maximum rate). 3. You then have a departure queue D1, and departure server DS, which has a service rate D, where D can be defined such that D(w) <= w (that is, the output is faster or equivalent speed to the input) or D(w) >= w (output is slower). If D(w) <= w, then I think one can argue simply by inspection that the total work unit buffering in the system is [max(w)/min(w)]-n. That is you simply need enough queueing to handle a queue that develops because a big packet causes a bunch of little packets to queue behind it (because they arrive while the big packet is going out). See Comment (**) below. I can't find an easy solution for D(w) >= w, because, in general, the queue can grow without bound. ** If you believe this model, what it says is that if you go with packet size buffers, and the ratio between the smallest possible packet and largest possible packet is big, then you can find your queues growing quite large, due not to classic congestion (where there is too much demand fighting for one output link) but rather to serialization delays. Craig _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Mar 8 17:29:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07475 for ; Mon, 8 Mar 2004 17:29:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFS-0000wx-EN for tcpm-archive@odin.ietf.org; Mon, 08 Mar 2004 17:29:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MTM4s003645 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFS-0000wi-9a for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07366 for ; Mon, 8 Mar 2004 17:29:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TFP-0000ph-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:29:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEa-0000dz-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDa-0000Pg-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDC-0000D8-55; Mon, 08 Mar 2004 17:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayvwi-0005oi-64 for tcpm@optimus.ietf.org; Thu, 04 Mar 2004 11:43:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01290 for ; Thu, 4 Mar 2004 11:43:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayvwh-0007aU-00 for tcpm@ietf.org; Thu, 04 Mar 2004 11:43:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayvvq-0007QI-00 for tcpm@ietf.org; Thu, 04 Mar 2004 11:42:46 -0500 Received: from ns1.s2io.com ([216.209.86.101]) by ietf-mx with esmtp (Exim 4.12) id 1AyvvC-0007DK-00; Thu, 04 Mar 2004 11:42:06 -0500 Received: from guinness.s2io.com (gateway.s2io.com [216.209.86.98]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i24GfNjF004269; Thu, 4 Mar 2004 11:41:23 -0500 (EST) Received: from lgt40 ([10.16.16.116]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i24Gf5KK001602; Thu, 4 Mar 2004 11:41:11 -0500 (EST) From: "Leonid Grossman" To: "'Luigi Rizzo'" , "'H.K. Jerry Chu'" Cc: , , Date: Thu, 4 Mar 2004 08:38:27 -0800 Message-ID: <001901c40207$29764560$7410100a@S2IOtech.com> 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: <20040304071216.A9347@xorpc.icir.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: -101 X-Spam-Outlook-Score: () X-Spam-Features: IN_REP_TO,QUOTED_EMAIL_TEXT,USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.34 Content-Transfer-Encoding: 7bit Subject: [tcpm] RE: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Luigi Rizzo [mailto:rizzo@icir.org] > Sent: Thursday, March 04, 2004 7:12 AM > To: H.K. Jerry Chu > Cc: leonid.grossman@s2io.com; tcpm@ietf.org; tsvwg@ietf.org; > end2end-interest@postel.org > Subject: Re: [Tsvwg] Re: [e2e] Are you interested in TOEs and > related issues > > > On Thu, Mar 04, 2004 at 11:11:36PM -0800, H.K. Jerry Chu wrote: ... > > Bursty traffic may be ok for LAN, but is considered evil > for WAN. TOE > > doesn't suffer this problem (since it is stateful), and may be a > > necessary evil until jumbo frames become universal. > > actually the interesting observation that this discussion > raises is that the frame size/link MTU should be picked large > enough to make the end-to-end pps rate bounded (but not too > low) for well behaved flows. > > In 1980 the ethernet MTU allowed some 800pps -- going much > higher makes little sense anyways, because even if the end > nodes can cope with higher rates, the control loops cannot > not react fast enough (you have to factor in propagation delays too). > > On the negative side, however, is that that very large MTUs > require a lot of buffering to be preallocated on the receive > side, and possibly even at the routers (at least, those > without hw-assisted forwarding planes). > > I don't have a good answer but going much higher than > 16Kbytes MTUs seems unlikely... and at 10Gig this is still > close to 100kpps. I think we'll be stuck at 9Kbytes for a while because of the CRC protection (or rather the weakening of such) for 16Kbytes frames, at least for 'simple' errors. Leonid > > cheers > luigi > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Mar 8 17:29:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07479 for ; Mon, 8 Mar 2004 17:29:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFT-0000xX-KQ for tcpm-archive@odin.ietf.org; Mon, 08 Mar 2004 17:29:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MTNTl003681 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFT-0000xG-EV for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07372 for ; Mon, 8 Mar 2004 17:29:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TFR-0000pr-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:29:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEc-0000eF-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDa-0000Pk-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDD-0000F6-4c; Mon, 08 Mar 2004 17:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4VP-0006Dd-Hc for tcpm@optimus.ietf.org; Thu, 04 Mar 2004 20:52:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27417 for ; Thu, 4 Mar 2004 20:52:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az4VN-0002Qn-00 for tcpm@ietf.org; Thu, 04 Mar 2004 20:52:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az4UV-0002Gk-00 for tcpm@ietf.org; Thu, 04 Mar 2004 20:51:08 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1Az4U9-00026P-00; Thu, 04 Mar 2004 20:50:45 -0500 Received: from jurassic.eng.sun.com ([129.146.84.31]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i251oii5003263; Thu, 4 Mar 2004 18:50:45 -0700 (MST) Received: from unknown (vpn-129-150-18-142.SFBay.Sun.COM [129.150.18.142]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with SMTP id i251oTfX276977; Thu, 4 Mar 2004 17:50:43 -0800 (PST) Message-Id: <200403050150.i251oTfX276977@jurassic.eng.sun.com> Date: Fri, 5 Mar 2004 10:50:16 -0800 (PST) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" To: rizzo@icir.org Cc: leonid.grossman@s2io.com, tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LoDKMLfvwX7SWlwTMw4lPg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 i86pc i386 Subject: [tcpm] Re: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,DATE_IN_FUTURE_12_24 autolearn=no version=2.60 >> Bursty traffic may be ok for LAN, but is considered evil for WAN. >> TOE doesn't suffer this problem (since it is stateful), and may be >> a necessary evil until jumbo frames become universal. > >actually the interesting observation that this discussion raises >is that the frame size/link MTU should be picked large enough to make the >end-to-end pps rate bounded (but not too low) for well behaved flows. > >In 1980 the ethernet MTU allowed some 800pps -- going much higher makes >little sense anyways, because even if the end nodes can cope with >higher rates, the control loops cannot not react fast enough >(you have to factor in propagation delays too). > >On the negative side, however, is that that very large MTUs require >a lot of buffering to be preallocated on the receive side, and >possibly even at the routers (at least, those without hw-assisted >forwarding planes). It's mainly the TCP receive window, not the PMTU that dictates how much buffering will be needed. Routers that do cut-through need not buffer the whole pkt. More significant is the drop of the DRAM price and increase of the DRAM size making memory a non-issue in many cases today. Over the past decade many components involved in providing high-speed networking have scaled up an order of magnitude. This including link bandwidth, CPU speed, I/O bus, memory size..., but not the Ethernet MTU and certain TCP parameters (such as the every-other-pkt acking policy). This is really hurting the throughput performance of the hosts. IMHO the amount of burstiness by TCP over WAN should be allowed to scale up an order of magnitude too. If stretch ACKs are fully adopted into TCP algorithm (see rfc2525 for a number of issues with stretch acks), one can use LSO on the transmit side, and per-flow pkt coalescing on the receive side to provide effectively a simple, stateless AAL5 layer for the Ethernet "cells" without requiring jumbo frames or complex TOE engine. BTW, I asked a few transport folks in Minneapolis IETF about how "evil" is traffic burst in today's enviroment, but did not get any concrete answer. Perhaps this topic should be discussed in tsvwg or tcpm. Jerry Sr. Staff Engineer Solaris Networking & Security Technology Sun Microsystems, Inc. > >I don't have a good answer but going much higher than 16Kbytes MTUs >seems unlikely... and at 10Gig this is still close to 100kpps. > > cheers > luigi _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Mar 8 17:29:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07477 for ; Mon, 8 Mar 2004 17:29:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFT-0000xD-0a for tcpm-archive@odin.ietf.org; Mon, 08 Mar 2004 17:29:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MTMZQ003661 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFS-0000wy-Qg for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07369 for ; Mon, 8 Mar 2004 17:29:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TFQ-0000pm-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:29:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEb-0000e7-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDa-0000Pj-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDE-0000GJ-1Q; Mon, 08 Mar 2004 17:27:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzDet-0002Lz-93 for tcpm@optimus.ietf.org; Fri, 05 Mar 2004 06:38:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03450 for ; Fri, 5 Mar 2004 06:38:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzDep-0004gV-00 for tcpm@ietf.org; Fri, 05 Mar 2004 06:38:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzDdv-0004Wj-00 for tcpm@ietf.org; Fri, 05 Mar 2004 06:37:28 -0500 Received: from xaqua.tel.fer.hr ([161.53.19.25]) by ietf-mx with esmtp (Exim 4.12) id 1AzDdA-0004BX-00; Fri, 05 Mar 2004 06:36:40 -0500 Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id F0DCB9B648; Fri, 5 Mar 2004 12:36:10 +0100 (CET) Received: from marko-tp.zavod.tel.fer.hr (marko-tp.zavod.tel.fer.hr [161.53.19.42]) by xaqua.tel.fer.hr (Postfix) with ESMTP id DF9749B646; Fri, 5 Mar 2004 12:36:03 +0100 (CET) From: Marko Zec To: "H.K. Jerry Chu" , rizzo@icir.org Date: Fri, 5 Mar 2004 12:35:23 +0100 User-Agent: KMail/1.5.4 Cc: leonid.grossman@s2io.com, tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org References: <200403050150.i251oTfX276977@jurassic.eng.sun.com> In-Reply-To: <200403050150.i251oTfX276977@jurassic.eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200403051235.23063.zec@tel.fer.hr> X-Sanitizer: Advosys mail filter Content-Transfer-Encoding: 7bit Subject: [tcpm] Re: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday 05 March 2004 19:50, H.K. Jerry Chu wrote: > >> Bursty traffic may be ok for LAN, but is considered evil for WAN. > >> TOE doesn't suffer this problem (since it is stateful), and may be > >> a necessary evil until jumbo frames become universal. > > > >actually the interesting observation that this discussion raises > >is that the frame size/link MTU should be picked large enough to > > make the end-to-end pps rate bounded (but not too low) for well > > behaved flows. > > > >In 1980 the ethernet MTU allowed some 800pps -- going much higher > > makes little sense anyways, because even if the end nodes can cope > > with higher rates, the control loops cannot not react fast enough > > (you have to factor in propagation delays too). > > > >On the negative side, however, is that that very large MTUs require > >a lot of buffering to be preallocated on the receive side, and > >possibly even at the routers (at least, those without hw-assisted > >forwarding planes). > > It's mainly the TCP receive window, not the PMTU that dictates how > much buffering will be needed. Routers that do cut-through need not > buffer the whole pkt. More significant is the drop of the DRAM price > and increase of the DRAM size making memory a non-issue in many cases > today. If the DRAM price alone were the only factor preventing vendors from implementing unlimited packet queues, we would already have seen tons of such devices on the market over the past 10 years or so. Excessive queuing delays on routers are bad, especially for high-speed traffic managed by TCP-like congestion control schemes. The queue lengths on routers have always been and will always present a tradeoff between a smallest usable window for handling traffic bursts, and the desire of keeping the queueing delays as low as possible on the other hand. > > Over the past decade many components involved in providing high-speed > networking have scaled up an order of magnitude. This including link > bandwidth, CPU speed, I/O bus, memory size..., but not the Ethernet > MTU and certain TCP parameters (such as the every-other-pkt acking > policy). This is really hurting the throughput performance of the > hosts. IMHO the amount of burstiness by TCP over WAN should be > allowed to scale up an order of magnitude too. If stretch ACKs are > fully adopted into TCP algorithm (see rfc2525 for a number of issues > with stretch acks), one can use LSO on the transmit side, and > per-flow pkt coalescing on the receive side to provide effectively a > simple, stateless AAL5 layer for the Ethernet "cells" without > requiring jumbo frames or complex TOE engine. > > BTW, I asked a few transport folks in Minneapolis IETF about how > "evil" is traffic burst in today's enviroment, but did not get any > concrete answer. Perhaps this topic should be discussed in tsvwg or > tcpm. Because queues in todays routers have finite maximum lengths, and this model is unlikely to change in the forseeable future, excessive traffic bursts will be more likely subject to drop-tail policing than other kinds of more smoothly shaped traffic. More than that, the bursty traffic will not only have less chance of reaching its target with all fragments in place, but it will also most probably do much harm to other innocent and otherwise well-behaving flows as well. Marko > > Jerry > > Sr. Staff Engineer > Solaris Networking & Security Technology > Sun Microsystems, Inc. > > >I don't have a good answer but going much higher than 16Kbytes MTUs > >seems unlikely... and at 10Gig this is still close to 100kpps. > > > > cheers > > luigi _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Mar 8 17:29:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07527 for ; Mon, 8 Mar 2004 17:29:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFU-0000xq-M2 for tcpm-archive@odin.ietf.org; Mon, 08 Mar 2004 17:29:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MTORN003700 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFU-0000xb-2E for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07378 for ; Mon, 8 Mar 2004 17:29:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TFR-0000pw-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:29:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEc-0000eN-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDc-0000Py-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDG-0000KN-EG; Mon, 08 Mar 2004 17:27:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B06S4-0004kV-Ps for tcpm@optimus.ietf.org; Sun, 07 Mar 2004 17:08:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07588 for ; Sun, 7 Mar 2004 17:08:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B06S2-00018F-00 for tcpm@ietf.org; Sun, 07 Mar 2004 17:08:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B06R8-00011N-00 for tcpm@ietf.org; Sun, 07 Mar 2004 17:07:55 -0500 Received: from bellana.nc-rj.rnp.br ([200.17.63.130]) by ietf-mx with smtp (Exim 4.12) id 1B06Qq-0000ts-00 for tcpm@ietf.org; Sun, 07 Mar 2004 17:07:37 -0500 Received: (qmail 11814 invoked by uid 0); 7 Mar 2004 22:06:59 -0000 Received: from kira.nc-rj.rnp.br (200.17.63.90) by 0 with SMTP; 7 Mar 2004 22:06:59 -0000 Received: (qmail 45150 invoked by uid 0); 7 Mar 2004 22:06:59 -0000 Received: from localhost.nc-rj.rnp.br (HELO localhost) (127.0.0.1) by 0 with SMTP; 7 Mar 2004 22:06:59 -0000 Date: Sun, 7 Mar 2004 19:06:56 -0300 (E. South America Standard Time) From: "Alexandre L. Grojsgold" To: Marko Zec cc: "H.K. Jerry Chu" , tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org In-Reply-To: <200403061121.37953.zec@tel.fer.hr> Message-ID: References: <200403052348.i25NmQdW692336@jurassic.eng.sun.com> <200403061121.37953.zec@tel.fer.hr> X-X-Sender: algold@[127.0.0.1] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [tcpm] Re: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > > The problem is that in today's routers the buffer sizes are typically > accounted in packets, not in bytes. So looking at your example, and > supposing that the line card buffer is limited to 100 packets, a burst > of small frames will instantly consume 13% of available buffer slots, > while jumbos will only use 2%. This is of course no problem if the line > card can transmit all those frames instantly, but what if it cannot? So what? Small packets get more buffer frames, but are also more rapidly sent. The gueue grows fats, but shrinks fast too. It means that a burst of small packets will not increase the packet loss, no mather the length of the buffer (in packets) . Ok, if the router gets a large amount of packets, representing more bytes per second than the capacity of the output line, packets will be lost. But it is a function of the amount of data conveyed by the packets, not of their individual length. > > > > > > >> BTW, I asked a few transport folks in Minneapolis IETF about how > > >> "evil" is traffic burst in today's enviroment, but did not get any > > >> concrete answer. Perhaps this topic should be discussed in tsvwg > > >> or tcpm. > > > > > >Because queues in todays routers have finite maximum lengths, and > > > this model is unlikely to change in the forseeable future, > > > excessive traffic bursts will be more likely subject to drop-tail > > > policing than other kinds of more smoothly shaped traffic. More > > > than that, the bursty traffic will not only have less chance of > > > reaching its target with all fragments in place, but it will also > > > most probably do much harm to I think many people tend to thing about IP routers like old circuit switched protocols switches, like X.25. In circuit switched networks, flow control is generaly implemented in each link, each pair of switches exchanging acks and naks, trying to keep data at the right pace. With IP, the flow control is end-to-end, performed by TCP. If a router queues too many packets, it will break TCP stability. It is not an issue of memory or memory price. alg. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Mar 8 17:29:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07568 for ; Mon, 8 Mar 2004 17:29:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFV-0000yS-RN for tcpm-archive@odin.ietf.org; Mon, 08 Mar 2004 17:29:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MTPMk003737 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFV-0000yC-KX for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07386 for ; Mon, 8 Mar 2004 17:29:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TFT-0000q6-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:29:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEe-0000ed-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDd-0000Q3-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDH-0000MV-Lu; Mon, 08 Mar 2004 17:27:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0PUa-0005z5-2A for tcpm@optimus.ietf.org; Mon, 08 Mar 2004 13:28:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19336 for ; Mon, 8 Mar 2004 13:28:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0PUY-0000q2-00 for tcpm@ietf.org; Mon, 08 Mar 2004 13:28:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0PTc-0000iI-00 for tcpm@ietf.org; Mon, 08 Mar 2004 13:27:45 -0500 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 1B0PSq-0000aQ-00; Mon, 08 Mar 2004 13:26:56 -0500 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel13.hp.com (Postfix) with ESMTP id D0B471C01698; Mon, 8 Mar 2004 10:26:55 -0800 (PST) Received: from cup.hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_24419+JAGae58098)/8.9.3 SMKit7.04) with ESMTP id KAA02251; Mon, 8 Mar 2004 10:26:55 -0800 (PST) Message-ID: <404CBAEF.B49A643D@cup.hp.com> Date: Mon, 08 Mar 2004 10:26:55 -0800 From: Rick Jones 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: David Borman Cc: Craig Partridge , tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org, Sunay Tripathi Subject: Re: [Tsvwg] Re: [tcpm] Re: [e2e] Are you interested in TOEs and related issues (Resend) References: <20040302150735.2A2221A9@aland.bbn.com> <510B9F0C-6DAB-11D8-AE57-000A95D7D4C0@cray.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > TOE has become a buzz-word that needs to be qualified. Some folks > include Checksum Offload and Large Segmentation Offload when talking > about TOE. When others talk about TOE, they refer to offloading the > whole TCP/IP stack. Humbly submitted: Pinky TOE => Checksum Offload (CKO) Middle TOE => CKO + LSO (aka TSO or large send) Big TOE => Full TCP Offload 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... _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Mar 8 18:15:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07412 for ; Mon, 8 Mar 2004 17:29:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFI-0000uo-Ns for tcpm-archive@odin.ietf.org; Mon, 08 Mar 2004 17:29:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MTCUK003512 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFI-0000uZ-IE for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07350 for ; Mon, 8 Mar 2004 17:29:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TFG-0000oS-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:29:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEQ-0000cM-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDJ-0000Q4-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDH-0000N3-VM; Mon, 08 Mar 2004 17:27:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Qp8-0004Jq-0D for tcpm@optimus.ietf.org; Mon, 08 Mar 2004 14:54:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24151 for ; Mon, 8 Mar 2004 14:53:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Qp5-00014S-00 for tcpm@ietf.org; Mon, 08 Mar 2004 14:53:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0QoG-0000sy-00 for tcpm@ietf.org; Mon, 08 Mar 2004 14:53:08 -0500 Received: from p70-227.acedsl.com ([66.114.70.227] helo=pit.databus.com) by ietf-mx with esmtp (Exim 4.12) id 1B0QnG-0000hE-00; Mon, 08 Mar 2004 14:52:06 -0500 Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.11/8.12.11) with ESMTP id i28Jq6X2044899; Mon, 8 Mar 2004 14:52:06 -0500 (EST) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.11/8.12.11/Submit) id i28Jq6tN044898; Mon, 8 Mar 2004 14:52:06 -0500 (EST) (envelope-from barney) Date: Mon, 8 Mar 2004 14:52:06 -0500 From: Barney Wolff Cc: tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org Subject: Re: [Tsvwg] Re: [tcpm] Re: [e2e] Are you interested in TOEs and related issues (Resend) Message-ID: <20040308195206.GB44520@pit.databus.com> References: <20040302150735.2A2221A9@aland.bbn.com> <510B9F0C-6DAB-11D8-AE57-000A95D7D4C0@cray.com> <404CBAEF.B49A643D@cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <404CBAEF.B49A643D@cup.hp.com> User-Agent: Mutt/1.5.6i X-Scanned-By: MIMEDefang 2.39 Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Mon, Mar 08, 2004 at 10:26:55AM -0800, Rick Jones wrote: > > Pinky TOE => Checksum Offload (CKO) > Middle TOE => CKO + LSO (aka TSO or large send) > Big TOE => Full TCP Offload You forgot these: Stubbed TOE => disabling TOE so tcpdump/snoop works Broken TOE => bug in firmware, difficult to diagnose -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Mar 8 18:15:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07528 for ; Mon, 8 Mar 2004 17:29:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFU-0000y6-Uz for tcpm-archive@odin.ietf.org; Mon, 08 Mar 2004 17:29:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MTOsh003716 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFU-0000xr-Q0 for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07381 for ; Mon, 8 Mar 2004 17:29:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TFS-0000q1-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:29:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEd-0000eV-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDc-0000Pz-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDG-0000Ku-Ns; Mon, 08 Mar 2004 17:27:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0N0t-0000WX-62 for tcpm@optimus.ietf.org; Mon, 08 Mar 2004 10:49:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09242 for ; Mon, 8 Mar 2004 10:49:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0N0q-0000nH-00 for tcpm@ietf.org; Mon, 08 Mar 2004 10:49:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0N04-0000dR-00 for tcpm@ietf.org; Mon, 08 Mar 2004 10:49:05 -0500 Received: from xaqua.tel.fer.hr ([161.53.19.25]) by ietf-mx with esmtp (Exim 4.12) id 1B0MzF-0000Np-00; Mon, 08 Mar 2004 10:48:13 -0500 Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 4ED4B9B646; Mon, 8 Mar 2004 16:47:35 +0100 (CET) Received: from marko-tp.zavod.tel.fer.hr (marko-tp.zavod.tel.fer.hr [161.53.19.42]) by xaqua.tel.fer.hr (Postfix) with ESMTP id A792C9B644; Mon, 8 Mar 2004 16:47:30 +0100 (CET) From: Marko Zec To: "Alexandre L. Grojsgold" Date: Mon, 8 Mar 2004 16:46:47 +0100 User-Agent: KMail/1.5.4 Cc: "H.K. Jerry Chu" , tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org References: <200403052348.i25NmQdW692336@jurassic.eng.sun.com> <200403061121.37953.zec@tel.fer.hr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200403081646.48030.zec@tel.fer.hr> X-Sanitizer: Advosys mail filter Content-Transfer-Encoding: 7bit Subject: [tcpm] Re: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Sunday 07 March 2004 23:06, Alexandre L. Grojsgold wrote: > > The problem is that in today's routers the buffer sizes are > > typically accounted in packets, not in bytes. So looking at your > > example, and supposing that the line card buffer is limited to 100 > > packets, a burst of small frames will instantly consume 13% of > > available buffer slots, while jumbos will only use 2%. This is of > > course no problem if the line card can transmit all those frames > > instantly, but what if it cannot? > > So what? > > Small packets get more buffer frames, but are also more rapidly sent. > The gueue grows fats, but shrinks fast too. It means that a burst of > small packets will not increase the packet loss, no mather the length > of the buffer (in packets). This theory is unfortunately wrong, because it ignores the fact that when congestions do occur, traffic flows consisting of small packets (regardless whether they are bursty or smooth) will use more buffer slots then the flows carrying the larger ones, leaving less remaining buffer slots available for queuing further packets / bursts. > Ok, if the router gets a large amount of packets, representing more > bytes per second than the capacity of the output line, packets will > be lost. But it is a function of the amount of data conveyed by the > packets, not of their individual length. Can you define the function you are talking about more precisely? What does it represent (I assume packet loss ratio)? Which argument(s) does it take? If this function is as simple as it might sound from your statement, why don't you share it with us? > > > > >> BTW, I asked a few transport folks in Minneapolis IETF about > > > >> how "evil" is traffic burst in today's enviroment, but did not > > > >> get any concrete answer. Perhaps this topic should be > > > >> discussed in tsvwg or tcpm. > > > > > > > >Because queues in todays routers have finite maximum lengths, > > > > and this model is unlikely to change in the forseeable future, > > > > excessive traffic bursts will be more likely subject to > > > > drop-tail policing than other kinds of more smoothly shaped > > > > traffic. More than that, the bursty traffic will not only have > > > > less chance of reaching its target with all fragments in place, > > > > but it will also most probably do much harm to > > I think many people tend to thing about IP routers like old circuit > switched protocols switches, like X.25. > > In circuit switched networks, flow control is generaly implemented in > each link, each pair of switches exchanging acks and naks, trying to > keep data at the right pace. > > With IP, the flow control is end-to-end, performed by TCP. If a > router queues too many packets, it will break TCP stability. It is > not an issue of memory or memory price. Agreed. And that's precisely the reason why bursty traffic is bad - since routers are generally tuned to queue only as few packets as feasible for normal TCP operation, excessive traffic bursts will have more chance of being tail-dropped at router queues. Marko _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 9 13:28:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13735 for ; Tue, 9 Mar 2004 13:28:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0lxJ-0007cD-85 for tcpm-archive@odin.ietf.org; Tue, 09 Mar 2004 13:27:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29IRr73029272 for tcpm-archive@odin.ietf.org; Tue, 9 Mar 2004 13:27:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0lxJ-0007c3-3L for tcpm-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 13:27:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13711 for ; Tue, 9 Mar 2004 13:27:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0lxH-0007M8-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 13:27:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0lwS-0007BQ-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 13:27:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0lva-0006zw-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 13:26:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0lvU-0007VG-Oa; Tue, 09 Mar 2004 13:26:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0lud-0007Ka-A7 for tcpm@optimus.ietf.org; Tue, 09 Mar 2004 13:25:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13484 for ; Tue, 9 Mar 2004 13:25:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0lub-0006mJ-00 for tcpm@ietf.org; Tue, 09 Mar 2004 13:25:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0ltb-0006a3-00 for tcpm@ietf.org; Tue, 09 Mar 2004 13:24:04 -0500 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 1B0lst-0006Oh-00 for tcpm@ietf.org; Tue, 09 Mar 2004 13:23:19 -0500 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id F3B48329F9; Tue, 9 Mar 2004 13:23:13 -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 1FA01328E4; Tue, 9 Mar 2004 13:23:13 -0500 (EST) Date: Tue, 9 Mar 2004 13:23:13 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: acaro@stimpy.eecis.udel.edu To: tcpm@ietf.org Cc: Ted Faber Subject: Re: [tcpm] Draft minutes and presentations from Korea In-Reply-To: <20040308193631.GJ2428@pun.isi.edu> Message-ID: References: <20040308193631.GJ2428@pun.isi.edu> 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: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > Draft Minutes as of 8 Mar 2004 > Ted mentioned that there's a discussion on e2e about a TCP consolidation > document. Ted is not clear on the difference between what they're > asking for and a roadmap, and Ted would rather see that energy in the > roadmap. > Congestion Control > Update 2581 (back to PS?) > merge 3390 (initial cwnd) > merge 3042 (limited transmit) > merge 2582 (Reno bugfix/NewReno) > merge 3465 (App. Byte Count security) These merges are basically what we had in mind with the consolidation document. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.armandocaro.net | University of Delaware | 0-- --0 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 9 16:47:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00736 for ; Tue, 9 Mar 2004 16:47:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0p3x-0006Lr-8c for tcpm-archive@odin.ietf.org; Tue, 09 Mar 2004 16:46:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29LkvAK024409 for tcpm-archive@odin.ietf.org; Tue, 9 Mar 2004 16:46:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0p3x-0006Lc-1y for tcpm-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 16:46:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00682 for ; Tue, 9 Mar 2004 16:46:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0p3v-0007l1-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 16:46:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0p37-0007bX-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 16:46:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0p2B-0007SF-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 16:45:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0p26-0006ES-3S; Tue, 09 Mar 2004 16:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0p21-0006Dr-RH for tcpm@optimus.ietf.org; Tue, 09 Mar 2004 16:44:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00604 for ; Tue, 9 Mar 2004 16:44:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0p1z-0007Qu-00 for tcpm@ietf.org; Tue, 09 Mar 2004 16:44:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0p18-0007Hk-00 for tcpm@ietf.org; Tue, 09 Mar 2004 16:44:03 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1B0p0K-00078E-00 for tcpm@ietf.org; Tue, 09 Mar 2004 16:43:12 -0500 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i29Lh9p28540; Tue, 9 Mar 2004 13:43:09 -0800 (PST) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.12.10/8.12.10) with ESMTP id i29Lh8DE016514; Tue, 9 Mar 2004 13:43:09 -0800 (PST) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.12.10/8.12.10/Submit) id i29Lh858016513; Tue, 9 Mar 2004 13:43:08 -0800 (PST) (envelope-from faber) Date: Tue, 9 Mar 2004 13:43:08 -0800 From: Ted Faber To: "Armando L. Caro Jr." Cc: tcpm@ietf.org Subject: Re: [tcpm] Draft minutes and presentations from Korea Message-ID: <20040309214308.GC15988@pun.isi.edu> References: <20040308193631.GJ2428@pun.isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KDt/GgjP6HVcx58l" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --KDt/GgjP6HVcx58l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 09, 2004 at 01:23:13PM -0500, Armando L. Caro Jr. wrote: > > > Draft Minutes as of 8 Mar 2004 > > > > > Ted mentioned that there's a discussion on e2e about a TCP consolidation > > document. Ted is not clear on the difference between what they're > > asking for and a roadmap, and Ted would rather see that energy in the > > roadmap. > > > > > Congestion Control > > Update 2581 (back to PS?) > > merge 3390 (initial cwnd) > > merge 3042 (limited transmit) > > merge 2582 (Reno bugfix/NewReno) > > merge 3465 (App. Byte Count security) > > These merges are basically what we had in mind with the consolidation > document. I'm *hoping* that means that there's a core group of people interested in working on an update of RFC2581 (2581bis) document. If that's so, it seems like TCPM would be the place to start working on it. What can I do to encourage such an effort? -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --KDt/GgjP6HVcx58l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFATjpsaUz3f+Zf+XsRAqdtAKCUSquVmlh17vcdKxQ5yD4hm1CmYACfakwa 7uXf4p31ptmCIkr/Rfk5ry8= =JTm3 -----END PGP SIGNATURE----- --KDt/GgjP6HVcx58l-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 9 16:49:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00913 for ; Tue, 9 Mar 2004 16:49:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0p5r-0006gT-H5 for tcpm-archive@odin.ietf.org; Tue, 09 Mar 2004 16:48:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29LmtQL025687 for tcpm-archive@odin.ietf.org; Tue, 9 Mar 2004 16:48:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0p5r-0006gD-AC for tcpm-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 16:48:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00871 for ; Tue, 9 Mar 2004 16:48:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0p5p-0000Ih-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 16:48:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0p4u-00008L-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 16:47:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0p43-0007mC-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 16:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0p40-0006MG-FG; Tue, 09 Mar 2004 16:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0p38-0006JA-OG for tcpm@optimus.ietf.org; Tue, 09 Mar 2004 16:46:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00655 for ; Tue, 9 Mar 2004 16:46:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0p36-0007bP-00 for tcpm@ietf.org; Tue, 09 Mar 2004 16:46:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0p27-0007S1-00 for tcpm@ietf.org; Tue, 09 Mar 2004 16:45:04 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1B0p1c-0007Hg-00; Tue, 09 Mar 2004 16:44:33 -0500 Received: from jurassic.eng.sun.com ([129.146.82.37]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i29LhYWA022068; Tue, 9 Mar 2004 13:43:34 -0800 (PST) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i29LhVfL348813; Tue, 9 Mar 2004 13:43:32 -0800 (PST) Received: (from sunay@localhost) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id i29LhVVQ348812; Tue, 9 Mar 2004 13:43:31 -0800 (PST) From: Sunay Tripathi Message-Id: <200403092143.i29LhVVQ348812@jurassic.eng.sun.com> Subject: Re: [tcpm] Re: [e2e] Are you interested in TOEs and related issues (Resend) In-Reply-To: <510B9F0C-6DAB-11D8-AE57-000A95D7D4C0@cray.com> from David Borman at "Mar 4, 2004 04:12:37 pm" To: David Borman Date: Tue, 9 Mar 2004 13:43:31 -0800 (PST) CC: Craig Partridge , tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org, Sunay Tripathi X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Sorry I was out travelling and in the meanwhile this thread has morphed into router design :) Anyway, I hope someone can start a new thread with the router design subject while we continue on TOE discussion - Thanks] David, > I wouldn't say in general that we found out that TOEs didn't work. I > think a more qualified comment of what we found out was that in an > environment where the network is the bottle neck, TOEs did not provide > any cost effective benefits; and as CPUs got faster, the TOEs just > provided costs without benefits. :-) > > TOE has become a buzz-word that needs to be qualified. Some folks > include Checksum Offload and Large Segmentation Offload when talking > about TOE. When others talk about TOE, they refer to offloading the > whole TCP/IP stack. I think we are talking about offloading the whole stack or to the point where the NIC needs to keep the state. The stateless offload (cksum offload and LSO has already been happening for a while). > With 10GigE, we are in the realm where the network is not the bottle > neck. Even with GigE, the CPU has to do significant work to keep the > card fed, leaving little time for doing any application work. I think > there are very few if any CPUs available today that can keep a 10GigE > pipe fed, much less handle an inbound 10GigE stream. Our experience as well. The fastest intel or sparc CPU can saturate the 1GigE but there is not much room left for doing meaningful work by the application. > Features such as Checksum Offload and LSO are features that have low > impact on the OS and its TCP/IP stack. Other features such as having a > timer to delay and aggregate transmit interrupts also help to reduce > the amount of work that the CPU has to do to process the data. > > For me, the question is what can be done in a 10GigE NIC to allow the > host CPU to handle both sending and receiving full speed on that > interface? TOE is just one part of that discussion and the danger is > that if too much focus is put on TOE, the other aspects of how to > improve how the CPU and the NIC communicate will not be properly > investigated. You defintely have to fanout to distribute load across multiple CPUs if you don't have TOE and CPU speed doesn't scale dramatically in couple of years. We are developing a dynamic polling/interrupt mechanism to use general purpose CPU to saturate 10GigE. Using TOE based cards is another possible approach (you still need to deal with moving a giga byte of data across your back plane though). Cheers, Sunay > > -David Borman > > On Mar 3, 2004, at 12:07 AM, Craig Partridge wrote: > > > > > Well, the interesting thing is we went down this path in the early > > 1980s > > and found that TOEs didn't work. > > > > If I try to distill all that we learned in the 1980s into one > > question, I > > come out with: > > > > In the 1980s we discovered that communicating with a TOE over a bus > > about a TCP connection was as expensive or more expensive than > > simply handling the TCP connection in the main processor. What > > about > > today's TOE designs makes them different? > > > > Craig > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www1.ietf.org/mailman/listinfo/tcpm > -- Sunay Tripathi Senior Staff Engineer, Solaris Kernel Networking, Sun MicroSystems Inc. email: sunay@eng.sun.com Phone: 650-786-6007 (W) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 9 17:08:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02063 for ; Tue, 9 Mar 2004 17:08:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0pOb-00086R-KL for tcpm-archive@odin.ietf.org; Tue, 09 Mar 2004 17:08:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29M8GFT031123 for tcpm-archive@odin.ietf.org; Tue, 9 Mar 2004 17:08:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0pOZ-00085j-1T for tcpm-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 17:08:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02045 for ; Tue, 9 Mar 2004 17:08:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0pOW-0003Yt-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 17:08:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0pNM-0003Ph-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 17:07:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0pMP-0003Gl-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 17:06:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0pMP-0007kT-2Q; Tue, 09 Mar 2004 17:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0pMI-0007jn-Ov for tcpm@optimus.ietf.org; Tue, 09 Mar 2004 17:05:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01920 for ; Tue, 9 Mar 2004 17:05:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0pMG-0003Fk-00 for tcpm@ietf.org; Tue, 09 Mar 2004 17:05:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0pLJ-00036D-00 for tcpm@ietf.org; Tue, 09 Mar 2004 17:04:53 -0500 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1B0pKN-0002ni-00 for tcpm@ietf.org; Tue, 09 Mar 2004 17:03:55 -0500 Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id A284B77A6D5; Tue, 9 Mar 2004 17:03:23 -0500 (EST) To: Ted Faber Cc: tcpm@ietf.org From: Mark Allman Reply-To: mallman@icir.org Subject: Re: [tcpm] Draft minutes and presentations from Korea In-Reply-To: <20040309214308.GC15988@pun.isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Wild Horses MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 09 Mar 2004 17:03:23 -0500 Message-Id: <20040309220323.A284B77A6D5@guns.icir.org> Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-=-= > I'm *hoping* that means that there's a core group of people interested > in working on an update of RFC2581 (2581bis) document. If that's so, > it seems like TCPM would be the place to start working on it. > > What can I do to encourage such an effort? This in on my plate, actually. (And, has been.) There is an old, but I think good, plan of attack. I'll try to throw it out and let everyone kick it soon. (Maybe it'd be nice if the co-chairs actually chatted every once in a while. :-) allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFATj8rWyrrWs4yIs4RApC8AJ9i/atwcEW4Zylk2WNLRRVaC55s4gCeJcev bIMRrFkSnfCgp8ShgX32830= =fYdu -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 9 17:26:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02835 for ; Tue, 9 Mar 2004 17:26:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0pff-0000sC-3Q for tcpm-archive@odin.ietf.org; Tue, 09 Mar 2004 17:25:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29MPt75003350 for tcpm-archive@odin.ietf.org; Tue, 9 Mar 2004 17:25:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0pfe-0000rx-Vm for tcpm-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 17:25:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02822 for ; Tue, 9 Mar 2004 17:25:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0pfc-0006bo-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 17:25:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0pei-0006Sb-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 17:24:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0pdo-0006JI-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 17:24:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0pdo-0000ds-Oe; Tue, 09 Mar 2004 17:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0pdn-0000da-GJ for tcpm@optimus.ietf.org; Tue, 09 Mar 2004 17:23:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02725 for ; Tue, 9 Mar 2004 17:23:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0pdl-0006Ij-00 for tcpm@ietf.org; Tue, 09 Mar 2004 17:23:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0pco-00069E-00 for tcpm@ietf.org; Tue, 09 Mar 2004 17:22:58 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1B0pbs-00060P-00 for tcpm@ietf.org; Tue, 09 Mar 2004 17:22:01 -0500 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i29MM0p07771; Tue, 9 Mar 2004 14:22:00 -0800 (PST) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.12.10/8.12.10) with ESMTP id i29MM0DE017537; Tue, 9 Mar 2004 14:22:00 -0800 (PST) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.12.10/8.12.10/Submit) id i29MM0a3017536; Tue, 9 Mar 2004 14:22:00 -0800 (PST) (envelope-from faber) Date: Tue, 9 Mar 2004 14:22:00 -0800 From: Ted Faber To: Mark Allman Cc: tcpm@ietf.org Subject: Re: [tcpm] Draft minutes and presentations from Korea Message-ID: <20040309222200.GI15988@pun.isi.edu> References: <20040309214308.GC15988@pun.isi.edu> <20040309220323.A284B77A6D5@guns.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JIpyCmsTxyPLrmrM" Content-Disposition: inline In-Reply-To: <20040309220323.A284B77A6D5@guns.icir.org> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --JIpyCmsTxyPLrmrM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 09, 2004 at 05:03:23PM -0500, Mark Allman wrote: > > > I'm *hoping* that means that there's a core group of people interested > > in working on an update of RFC2581 (2581bis) document. If that's so, > > it seems like TCPM would be the place to start working on it. > > > > What can I do to encourage such an effort? > > This in on my plate, actually. (And, has been.) There is an old, but I > think good, plan of attack. I'll try to throw it out and let everyone > kick it soon. > > (Maybe it'd be nice if the co-chairs actually chatted every once in a > while. :-) Sounds like I can encourage such an effort by occasionally accidentally starting a parallel one. :-) I'm happy to stay out of the way while you compose the 2581 update and let these guys join in the evaluation of it when it apprears. Sorry for sending mixed messages. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --JIpyCmsTxyPLrmrM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFATkOIaUz3f+Zf+XsRAgrrAJ0TLL/tmmFAS7Uq6mII8OAqIZamGwCfc8pl MhRtKuviX83193NyLvXddMA= =1yf8 -----END PGP SIGNATURE----- --JIpyCmsTxyPLrmrM-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 9 20:04:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10423 for ; Tue, 9 Mar 2004 20:04:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0s8n-0008HI-9Q for tcpm-archive@odin.ietf.org; Tue, 09 Mar 2004 20:04:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A149gv031816 for tcpm-archive@odin.ietf.org; Tue, 9 Mar 2004 20:04:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0s8m-0008H1-P3 for tcpm-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 20:04:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10385 for ; Tue, 9 Mar 2004 20:04:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0s8k-0002hs-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:04:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0s7g-0002WP-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:03:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0s6j-0002L4-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0s6j-0007vP-63; Tue, 09 Mar 2004 20:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0s5o-0007t4-5w for tcpm@optimus.ietf.org; Tue, 09 Mar 2004 20:01:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10279 for ; Tue, 9 Mar 2004 20:01:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0s5m-0002AT-00 for tcpm@ietf.org; Tue, 09 Mar 2004 20:01:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0s4q-00021B-00 for tcpm@ietf.org; Tue, 09 Mar 2004 20:00:05 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1B0s44-0001iv-00; Tue, 09 Mar 2004 19:59:16 -0500 Received: from jurassic.eng.sun.com ([129.146.84.45]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2A0wkWA015629; Tue, 9 Mar 2004 16:58:46 -0800 (PST) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i2A0wjq7427787; Tue, 9 Mar 2004 16:58:45 -0800 (PST) Received: (from sunay@localhost) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id i2A0wjgi427786; Tue, 9 Mar 2004 16:58:45 -0800 (PST) From: Sunay Tripathi Message-Id: <200403100058.i2A0wjgi427786@jurassic.eng.sun.com> In-Reply-To: <86y8qf6bvy.fsf@abel.internet2.edu> from stanislav shalunov at "Mar 5, 2004 01:33:53 am" To: stanislav shalunov Date: Tue, 9 Mar 2004 16:58:45 -0800 (PST) CC: Sunay Tripathi , tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [tcpm] Re: [e2e] Re: Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Sunay Tripathi writes: > > > 1) Extra processor(s) buried in the TOE for networking processing which is > > hidden from the kernel and leaves the host CPU to do more application > > related work. Saves the cost of licences for application which take > > number of CPU into account (oracle is one such application cited). > > One would hope TCP design would not be guided by Oracle licensing quirks. I don't think we are designing TCP here. We are just discussing an implementation of TCP and obviously costs do play a factor in any implementation. > > 2) On low end (1-2 CPU) x86 based machines, cost of adding a processor > > is much higher than adding a TOE (I personally haven't verified this). > > It's not obvious why this should necessarily be the case, given that > it is likely that there will continue to be quite a bit more > general-purpose CPUs made than TCP offload engines. > > > 3) For the up and coming 10Gb NICs, TOE will help saturate the link. Some > > vendors assert that TOE will be required to support 10Gb NICs. > > Right now, one can do almost 8Gb/s with a single TCP stream over 10GE > (let's say 5 or 6Gb/s with more common hardware). The limiting factor > is currently host bus speed. There's nothing (except for compression > on the bus side, but it should be clear we're not going there) that an > offload engine can do about host bus speed. By the time host busses > faster than 10Gb/s are commonly available, pretty routine x86 box > should handle 10GE saturation. We have host busses today which can handle a giga bytes plus on the back plane. Infiniband based machines are already hitting and there are other technologies (that I can't talk about yet) which will make the host bus issues irrelevant. > > 4) Performance reasons. Just the LSO aspect of TOE (sending large chunks of > > data and letting the TOE split it up in mss size pieces) and ack > > coalescing gives a pretty good boost (our own prototypes indicates that > > this is true). The gains are by optimizing data movement and not by > > offloading protocol processing. > > Here I would agree with the unnamed TOE vendor whom you're > paraphrasing (and with Jerry Chu's comments in this thread). Ethernet > frame size (1500 bytes or even 9kB) is very small; we'd be in a better > world if we could specify the MTU in units of time (the number of CRC > bits would have to scale up as well, of course). TCP offload engines > could be a kludge that would help to work around this deficiency in > Ethernet. > > Note that since even at 10Gb/s one CPU is enough to saturate the link > with 9kB packets, the need for this work-around is not at all > pressing. Given the potential harmful effects (undetected errors on > the host bus, difficulty in patching stale or buggy TCP code, etc.), > one would probably be better served by concentrating on the deployment > of jumbo frames. The investment to support jumbo frames has largely > already been made, so why not extract all we can from it first? Sure, jumbo frames do deserve attention. Its being discussed right now in IETF but I am not sure 9k frames would be enough to saturate the 10Gb NIC till the processor speeds also scale significantly. Note that its not just the ability to saturate the link but you also need to have some CPU free to do real work as well. Cheers, Sunay > > -- > Stanislav Shalunov http://www.internet2.edu/~shalunov/ > -- Sunay Tripathi Solaris Kernel Networking, Sun MicroSystems Inc. email: sunay@eng.sun.com Phone: 650-786-6007 (W) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 9 20:08:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10663 for ; Tue, 9 Mar 2004 20:08:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sCd-0000ke-Mo for tcpm-archive@odin.ietf.org; Tue, 09 Mar 2004 20:08:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A187ir002880 for tcpm-archive@odin.ietf.org; Tue, 9 Mar 2004 20:08:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sCc-0000kF-DI for tcpm-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 20:08:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10596 for ; Tue, 9 Mar 2004 20:08:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0sCa-0003WF-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:08:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0sBf-0003JK-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:07:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0sAg-00036v-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:06:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sAd-0000I2-9T; Tue, 09 Mar 2004 20:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0VCC-0003H1-FM for tcpm@optimus.ietf.org; Mon, 08 Mar 2004 19:34:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13638 for ; Mon, 8 Mar 2004 19:34:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0VCA-00056Q-00 for tcpm@ietf.org; Mon, 08 Mar 2004 19:34:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0VBE-0004uM-00 for tcpm@ietf.org; Mon, 08 Mar 2004 19:33:09 -0500 Received: from zg06-238.dialin.iskon.hr ([213.191.148.239] helo=mail.tel.fer.hr) by ietf-mx with esmtp (Exim 4.12) id 1B0VAZ-0004hy-00; Mon, 08 Mar 2004 19:32:27 -0500 Received: from marko-tp.katoda.net (marko@dhcp11.katoda.net [192.168.200.111]) by mail.tel.fer.hr (8.12.6/8.12.6) with ESMTP id i290VxuP004939; Tue, 9 Mar 2004 01:32:00 +0100 (CET) (envelope-from zec@tel.fer.hr) From: Marko Zec To: Craig Partridge Date: Tue, 9 Mar 2004 01:31:10 +0100 User-Agent: KMail/1.5.4 Cc: tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org References: <20040309000732.EE4391A4@aland.bbn.com> In-Reply-To: <20040309000732.EE4391A4@aland.bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200403090131.10346.zec@tel.fer.hr> Content-Transfer-Encoding: 7bit Subject: [tcpm] Re: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tuesday 09 March 2004 01:07, Craig Partridge wrote: > In message <200403090046.15061.zec@tel.fer.hr>, Marko Zec writes: > >All I was trying to point out in my prior posts is that precisely in > >such a situation bursty traffic will present a big failure. > > Right, but bursts only matter if they cause a queue to build up in a > router. Putting a burst on a wire doesn't mean a queue in the router > -- it depends on the speed of the routers inputs and outputs. > > Putting this another way, TCP causes a queue in the bottleneck router > (the spot where A > D). OK, can we then agree that making such a spot a subject to an additional traffic burst can be considered a bad thing? Marko _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 9 20:08:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10669 for ; Tue, 9 Mar 2004 20:08:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sCe-0000lF-Tj for tcpm-archive@odin.ietf.org; Tue, 09 Mar 2004 20:08:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A188pd002919 for tcpm-archive@odin.ietf.org; Tue, 9 Mar 2004 20:08:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sCe-0000ku-EY for tcpm-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 20:08:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10602 for ; Tue, 9 Mar 2004 20:08:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0sCc-0003WU-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:08:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0sBi-0003Js-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:07:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0sAi-00036u-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:06:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sAc-0000G8-JI; Tue, 09 Mar 2004 20:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0UVS-0004kP-Ak for tcpm@optimus.ietf.org; Mon, 08 Mar 2004 18:49:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12082 for ; Mon, 8 Mar 2004 18:49:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0UVP-0006L0-00 for tcpm@ietf.org; Mon, 08 Mar 2004 18:49:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0UUT-0006C8-00 for tcpm@ietf.org; Mon, 08 Mar 2004 18:48:58 -0500 Received: from zg03-233.dialin.iskon.hr ([213.191.135.234] helo=mail.tel.fer.hr) by ietf-mx with esmtp (Exim 4.12) id 1B0UTa-000635-00; Mon, 08 Mar 2004 18:48:02 -0500 Received: from marko-tp.katoda.net (marko@dhcp11.katoda.net [192.168.200.111]) by mail.tel.fer.hr (8.12.6/8.12.6) with ESMTP id i28NlLuP004926; Tue, 9 Mar 2004 00:47:22 +0100 (CET) (envelope-from zec@tel.fer.hr) From: Marko Zec To: Craig Partridge , "Stephen Suryaputra" Date: Tue, 9 Mar 2004 00:46:30 +0100 User-Agent: KMail/1.5.4 Cc: tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org References: <20040308215043.9182A1A4@aland.bbn.com> In-Reply-To: <20040308215043.9182A1A4@aland.bbn.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200403090046.15061.zec@tel.fer.hr> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [tcpm] Re: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Monday 08 March 2004 22:50, Craig Partridge wrote: > In message > <8052E2EA753D144EB906B7A7AA399714022A05B7@mailserv.hatteras.com>, "S > > tephen Suryaputra" writes: > >I think Marko is referring to the situation when there is a > > congestion. Because of that the queue builds up and if the queue > > space is in term of the number of packets, then a bunch of small > > packets can potentially dominate the queue and left little room for > > large packets eventhough there is a space in the buffer to > > accomodate the large ones. > > Well, I tried to nail this down by setting it up as a queueing system > but that's awfully hard. Here's the cut: > > 1. Basically you have a general arrival process delivering pieces of > work of variable size, at arrival rate A subject to the condition > that if there's an event of size w1 at time t1, then the next event > cannot arrive sooner than time t1+w1. [I.e. A(t2,w2) - A(t1,w1) >= > w1]. > > 2. You then have a series of queues Q1-Qn attached to servers S1-Sn > that serve events at a fixed rate R, where R1 <= A (i.e. we can > handle the maximum rate). > > 3. You then have a departure queue D1, and departure server DS, > which has a service rate D, where D can be defined such that D(w) <= > w (that is, the output is faster or equivalent speed to the input) or > D(w) >= w (output is slower). > > > If D(w) <= w, then I think one can argue simply by inspection that > the total work unit buffering in the system is [max(w)/min(w)]-n. > That is you simply need enough queueing to handle a queue that > develops because a big packet causes a bunch of little packets to > queue behind it (because they arrive while the big packet is going > out). See Comment (**) below. > > I can't find an easy solution for D(w) >= w, because, in general, the > queue can grow without bound. Isn't the TCP's ultimate performance goal precisely the maintenance of the equilibrium D(w) = w in the bottleneck queue? If you are a lucky owner of just the TCP implementation that has no problem of achieving that goal for the particular network configuration, the queue length on the bottleneck link will fluctuate - sometimes it will be almost empty, sometimes almost full, and every now and then it will even have to drop a packet or two, but hopefully not more than that. All I was trying to point out in my prior posts is that precisely in such a situation bursty traffic will present a big failure. If the burst arrives when the buffer is almost full, then the majority of the packets from the burst will be discarded. Furthermore, if packets of smaller size are used, requiring more packets to carry the same amount of useful payload, the greater will be the percentage of such packets to be dropped, assuming the buffer size on the router is defined by the number of packets it can hold, regardless of packet size. Marko > > ** If you believe this model, what it says is that if you go with > packet size buffers, and the ratio between the smallest possible > packet and largest possible packet is big, then you can find your > queues growing quite large, due not to classic congestion (where > there is too much demand fighting for one output link) but rather to > serialization delays. > > Craig _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 9 20:35:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12078 for ; Tue, 9 Mar 2004 20:35:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0scg-00029d-Lh for tcpm-archive@odin.ietf.org; Tue, 09 Mar 2004 20:35:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A1Z2X2008280 for tcpm-archive@odin.ietf.org; Tue, 9 Mar 2004 20:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0scf-00029P-Su for tcpm-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 20:35:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12039 for ; Tue, 9 Mar 2004 20:34:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0scd-0000S3-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:34:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0sbf-0000IG-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:34:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0saj-000092-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:33:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0saj-00023n-48; Tue, 09 Mar 2004 20:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sZn-00023N-Vm for tcpm@optimus.ietf.org; Tue, 09 Mar 2004 20:32:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11973 for ; Tue, 9 Mar 2004 20:32:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0sZl-0007nH-00 for tcpm@ietf.org; Tue, 09 Mar 2004 20:32:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0sYt-0007es-00 for tcpm@ietf.org; Tue, 09 Mar 2004 20:31:07 -0500 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1B0sYO-0007V9-00 for tcpm@ietf.org; Tue, 09 Mar 2004 20:30:36 -0500 Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 055A677A6D5; Tue, 9 Mar 2004 20:30:05 -0500 (EST) To: Ted Faber From: Mark Allman Reply-To: mallman@icir.org Cc: tcpm@ietf.org Subject: Re: [tcpm] Draft minutes and presentations from Korea In-Reply-To: <20040309222200.GI15988@pun.isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Wild Horses MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 09 Mar 2004 20:30:05 -0500 Message-Id: <20040310013005.055A677A6D5@guns.icir.org> Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-=-= > Sounds like I can encourage such an effort by occasionally > accidentally starting a parallel one. :-) Right. I'd like to say I mentioned this potential effort to you early on. But, I am sure it slipped my mind. Sorry! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFATm+cWyrrWs4yIs4RAgelAJ9iRu3zpI0cacgT2y/PUa8gSdhuMACgmmqH ULeNSb9OyeOoIs40RXEvQHQ= =XaRw -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 9 20:55:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10680 for ; Tue, 9 Mar 2004 20:08:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sCf-0000lX-H9 for tcpm-archive@odin.ietf.org; Tue, 09 Mar 2004 20:08:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A1894B002937 for tcpm-archive@odin.ietf.org; Tue, 9 Mar 2004 20:08:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sCf-0000lI-6f for tcpm-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 20:08:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10608 for ; Tue, 9 Mar 2004 20:08:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0sCd-0003Wa-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:08:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0sBk-0003K6-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:07:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0sAj-000378-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:06:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sAc-0000GU-TH; Tue, 09 Mar 2004 20:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Unu-0002MX-T8 for tcpm@optimus.ietf.org; Mon, 08 Mar 2004 19:09:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12540 for ; Mon, 8 Mar 2004 19:08:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Unr-0001G9-00 for tcpm@ietf.org; Mon, 08 Mar 2004 19:08:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Umw-00017Y-00 for tcpm@ietf.org; Mon, 08 Mar 2004 19:08:02 -0500 Received: from adsl-68-22-232-249.dsl.lgtpmi.ameritech.net ([68.22.232.249] helo=aland.bbn.com) by ietf-mx with esmtp (Exim 4.12) id 1B0UmS-0000yr-00; Mon, 08 Mar 2004 19:07:33 -0500 Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (Postfix) with ESMTP id EE4391A4; Mon, 8 Mar 2004 19:07:32 -0500 (EST) To: Marko Zec Cc: tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org In-Reply-To: Your message of "Tue, 09 Mar 2004 00:46:30 +0100." <200403090046.15061.zec@tel.fer.hr> Date: Mon, 08 Mar 2004 19:07:32 -0500 From: Craig Partridge Message-Id: <20040309000732.EE4391A4@aland.bbn.com> Subject: [tcpm] Re: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <200403090046.15061.zec@tel.fer.hr>, Marko Zec writes: >Isn't the TCP's ultimate performance goal precisely the maintenance of >the equilibrium D(w) = w in the bottleneck queue? No, TCP's goal is to equal the lesser of A or D (whatever they are). >All I was trying to point out in my prior posts is that precisely in >such a situation bursty traffic will present a big failure. Right, but bursts only matter if they cause a queue to build up in a router. Putting a burst on a wire doesn't mean a queue in the router -- it depends on the speed of the routers inputs and outputs. Putting this another way, TCP causes a queue in the bottleneck router (the spot where A > D). Craig _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 9 20:55:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10664 for ; Tue, 9 Mar 2004 20:08:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sCd-0000kT-Ey for tcpm-archive@odin.ietf.org; Tue, 09 Mar 2004 20:08:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A186Go002865 for tcpm-archive@odin.ietf.org; Tue, 9 Mar 2004 20:08:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sCb-0000k8-NM for tcpm-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 20:08:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10593 for ; Tue, 9 Mar 2004 20:08:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0sCZ-0003WA-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:08:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0sBe-0003JC-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:07:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0sAg-00036r-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:06:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sAe-0000KK-0n; Tue, 09 Mar 2004 20:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0qhf-0002YR-GQ for tcpm@optimus.ietf.org; Tue, 09 Mar 2004 18:32:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07048 for ; Tue, 9 Mar 2004 18:31:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0qhc-0002vJ-00 for tcpm@ietf.org; Tue, 09 Mar 2004 18:32:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0qgk-0002mR-00 for tcpm@ietf.org; Tue, 09 Mar 2004 18:31:06 -0500 Received: from smtp03.mrf.mail.rcn.net ([207.172.4.62]) by ietf-mx with esmtp (Exim 4.12) id 1B0qgF-0002d5-00; Tue, 09 Mar 2004 18:30:35 -0500 Received: from 65-78-5-127.c3-0.ned-ubr1.sbo-ned.ma.cable.rcn.com ([65.78.5.127] helo=minke.reed.com) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.35 #4) id 1B0qgA-00004T-00; Tue, 09 Mar 2004 18:30:30 -0500 Message-Id: <6.0.1.1.2.20040309181340.05209120@127.0.0.1> X-Sender: mail.reed.com:dpreed@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 09 Mar 2004 18:29:39 -0500 To: Sunay Tripathi , David Borman From: "David P. Reed" Subject: Re: [tcpm] Re: [e2e] Are you interested in TOEs and related issues (Resend) Cc: Craig Partridge , tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org, Sunay Tripathi In-Reply-To: <200403092143.i29LhVVQ348812@jurassic.eng.sun.com> References: <510B9F0C-6DAB-11D8-AE57-000A95D7D4C0@cray.com> <200403092143.i29LhVVQ348812@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 As the network gets faster, the user perceived performance issue moves into the application layer, except for the special case of remoting bulk disk drive accesses. There is a small "opportunity window" of app requirements where the TCP layer is the crucial issue for performance. It's easy to get focused on unrealistic benchmark cases that ignore the complexity of app logic, and the power of general purpose computing architectures that can dynamically partition workload rather than statically partitioning function into boxes. I wouldn't waste my time on TOEs. There are more useful things to work on, like making end-to-end secure and resilient communications practical. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 9 20:55:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10665 for ; Tue, 9 Mar 2004 20:08:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sCe-0000kt-7I for tcpm-archive@odin.ietf.org; Tue, 09 Mar 2004 20:08:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A188C6002897 for tcpm-archive@odin.ietf.org; Tue, 9 Mar 2004 20:08:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sCd-0000kd-Mk for tcpm-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 20:08:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10599 for ; Tue, 9 Mar 2004 20:08:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0sCb-0003WP-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:08:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0sBh-0003Jf-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:07:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0sAh-00036z-00 for tcpm-web-archive@ietf.org; Tue, 09 Mar 2004 20:06:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sAd-0000IO-HA; Tue, 09 Mar 2004 20:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0cj8-0001Eq-83 for tcpm@optimus.ietf.org; Tue, 09 Mar 2004 03:36:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14751 for ; Tue, 9 Mar 2004 03:36:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0cj5-0004nW-00 for tcpm@ietf.org; Tue, 09 Mar 2004 03:36:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0ci9-0004cs-00 for tcpm@ietf.org; Tue, 09 Mar 2004 03:35:38 -0500 Received: from [80.74.106.236] (helo=star.radlan.net) by ietf-mx with esmtp (Exim 4.12) id 1B0chg-0004QF-00; Tue, 09 Mar 2004 03:35:08 -0500 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" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Mar 2004 10:35:08 +0200 Message-ID: Thread-Topic: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Thread-Index: AcQFl11eRUGE15VASlSDgPJ6rGdpqQADcMug From: "Tal Anker" To: "Craig Partridge" , "Marko Zec" Cc: , , Content-Transfer-Encoding: quoted-printable Subject: [tcpm] RE: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I think that what Marco meant was that when a congestion occurs, i.e., = the incoming traffic rate is higher then the service rate (the interface = speed) the potential for congestion also depends on the packet sizes. = This is so since the queue is not comprised from "bytes" only, but = rather of buffer descriptors... The queue length in many cases is the = number of descriptors, and the queue length in bytes is indeed depending = on the packet sizes enqueued.=20 Thus, for Ethernet interfaces if an interface with speed L (b/s) is = transmitting a 1500 bytes frame, and several other interfaces (say N = interfaces) are sending traffic to that the same interface, then at the = time L/(1500*8) seconds, there can be either N packets - descriptors = that needs to be queued, or N*(1500/64) in the worst case... the worst = case is quite hard on some HW implementations as the number of = descriptors in many cases is the number of max size packet buffers = (packets are usually buffered in a fixed size buffers equal to the max = frame size). - Tal -----Original Message----- From: Craig Partridge [mailto:craig@bbn.com] Sent: Monday, March 08, 2004 6:15 PM To: Marko Zec Cc: tcpm@ietf.org; tsvwg@ietf.org; end2end-interest@postel.org Subject: Re: [Tsvwg] Re: [e2e] Are you interested in TOEs and related = issues=20 In message <200403081646.48030.zec@tel.fer.hr>, Marko Zec writes: >On Sunday 07 March 2004 23:06, Alexandre L. Grojsgold wrote: >> Small packets get more buffer frames, but are also more rapidly sent. >> The gueue grows fats, but shrinks fast too. It means that a burst of >> small packets will not increase the packet loss, no mather the length >> of the buffer (in packets). > > >This theory is unfortunately wrong, because it ignores the fact that=20 >when congestions do occur, traffic flows consisting of small packets=20 >(regardless whether they are bursty or smooth) will use more buffer=20 >slots then the flows carrying the larger ones, leaving less remaining=20 >buffer slots available for queuing further packets / bursts. I must be missing something here. I think Alexandre's generally right. If the buffers load and empty according to the amount of data in them, then packet size isn't an issue. The only situations in which this isn't true, that I can think off the top of my head, are: * If the router has places where it moves all the bytes in the = packet buffer, regardless of how much data the buffer actually contains. Since this would cause extraordinary internal bandwidth = challenges, I doubt anyone does it for any but the lowest speed routers. * If the router has a deep pipeline and the time at each stage in = the pipeline is set to equal the average packet time rather than the minimum packet time. But most folks carefully design router = pipelines for minimum packet times precisely because of this risk. So clue me in -- what detail of router design am I missing? Craig _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Mar 10 21:29:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21268 for ; Wed, 10 Mar 2004 21:29:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1FwY-00013B-F6 for tcpm-archive@odin.ietf.org; Wed, 10 Mar 2004 21:29:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B2T6VK004033 for tcpm-archive@odin.ietf.org; Wed, 10 Mar 2004 21:29:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1FwY-00012y-85 for tcpm-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 21:29:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21241 for ; Wed, 10 Mar 2004 21:29:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1FwV-0006LO-00 for tcpm-web-archive@ietf.org; Wed, 10 Mar 2004 21:29:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1FvW-0006By-00 for tcpm-web-archive@ietf.org; Wed, 10 Mar 2004 21:28:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1FuY-00062m-00 for tcpm-web-archive@ietf.org; Wed, 10 Mar 2004 21:27:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1FuX-0000r4-4d; Wed, 10 Mar 2004 21:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Fti-0000q6-Tj for tcpm@optimus.ietf.org; Wed, 10 Mar 2004 21:26:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21173 for ; Wed, 10 Mar 2004 21:26:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Ftg-0005ua-00 for tcpm@ietf.org; Wed, 10 Mar 2004 21:26:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Fsh-0005mB-00 for tcpm@ietf.org; Wed, 10 Mar 2004 21:25:08 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1B1Frp-0005VC-00; Wed, 10 Mar 2004 21:24:13 -0500 Received: from jurassic.eng.sun.com ([129.146.83.36]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2B2NUWA012445; Wed, 10 Mar 2004 18:23:35 -0800 (PST) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i2B2NUGK103647; Wed, 10 Mar 2004 18:23:30 -0800 (PST) Received: (from sunay@localhost) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id i2B2NUt4103646; Wed, 10 Mar 2004 18:23:30 -0800 (PST) From: Sunay Tripathi Message-Id: <200403110223.i2B2NUt4103646@jurassic.eng.sun.com> Subject: Re: [tcpm] Re: [e2e] Are you interested in TOEs and related issues (Resend) In-Reply-To: <6.0.1.1.2.20040310095034.03103108@127.0.0.1> from "David P. Reed" at "Mar 10, 2004 09:55:18 am" To: "David P. Reed" Date: Wed, 10 Mar 2004 18:23:30 -0800 (PST) CC: Sunay Tripathi , David Borman , Craig Partridge , tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David, Thanks for clarifying. > At 06:29 PM 3/9/2004, David P. Reed wrote: > >I wouldn't waste my time on TOEs. There are more useful things to work > >on, like making end-to-end secure and resilient communications practical. > > To clarify this, if it seems like a non-sequitur or change in topic, > remember that offloading TCP into a separate box locks in any security > flaws into the architectural structure you had to create to make it > happen. In practice, this means that no one will have the energy or money > to fix the security and resiliency issues in such solutions - which means > more kludges in wrap-around devices and interceptors that create the false > illusion of security. Yes, that was one of the first thoughts that came to my mind when I started looking at this space. Its not just security issues but bugs and new features. TCP despite being mature still sees couple of RFC or tweaks a year that needs to be rolled out to existing systems. Apparantly the TOE vendors had thought about that. The firmware running the protocol code actually lives on the host and is delivered via exisiting delivery mechanism (packages in Solaris which can be upgraded). When machine boots and interface is configured, the protocol firmware is sucked in. So delivering fix or new revs in pretty similar to exisiting mechanisms. Also, the source code is still 'C' based so people like me can still work with it (just need to use some magic in the end to create the firmware instead of complier). Some vendors we talked to have promised that they can pretty much suck in the same code that runs on the host into the card (as long as we can clean some complier specific directives etc). Although I must admit that this aspect (common source files) of TOE has not been investigated by us at all so far. Cheers, Sunay > > Communications networking is a systems problem, and ignoring the systems > issues by focusing on a narrow problem space is not a good investment of > effort. > > -- Sunay Tripathi Solaris Kernel Networking, Sun MicroSystems Inc. email: sunay@eng.sun.com Phone: 650-786-6007 (W) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Mar 11 16:11:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26516 for ; Thu, 11 Mar 2004 16:11:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XSL-0002eQ-8s for tcpm-archive@odin.ietf.org; Thu, 11 Mar 2004 16:11:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BLB4id010175 for tcpm-archive@odin.ietf.org; Thu, 11 Mar 2004 16:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XSH-0002dg-DO for tcpm-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 16:11:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26485 for ; Thu, 11 Mar 2004 16:10:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1XSF-0004Ww-00 for tcpm-web-archive@ietf.org; Thu, 11 Mar 2004 16:10:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1XRS-0004O2-00 for tcpm-web-archive@ietf.org; Thu, 11 Mar 2004 16:10:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1XQf-0004DU-00 for tcpm-web-archive@ietf.org; Thu, 11 Mar 2004 16:09:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XDz-0008C9-4L; Thu, 11 Mar 2004 15:56:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1VGh-00060C-7m for tcpm@optimus.ietf.org; Thu, 11 Mar 2004 13:50:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16169 for ; Thu, 11 Mar 2004 13:50:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1VGe-0006wH-00 for tcpm@ietf.org; Thu, 11 Mar 2004 13:50:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1VFk-0006oQ-00 for tcpm@ietf.org; Thu, 11 Mar 2004 13:49:57 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx with esmtp (Exim 4.12) id 1B1VF1-0006gD-00; Thu, 11 Mar 2004 13:49:11 -0500 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel12.hp.com (Postfix) with ESMTP id C721D1C01E63; Thu, 11 Mar 2004 10:49:10 -0800 (PST) Received: from cup.hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_24419+JAGae58098)/8.9.3 SMKit7.04) with ESMTP id KAA16686; Thu, 11 Mar 2004 10:49:10 -0800 (PST) Message-ID: <4050B4A6.D346736C@cup.hp.com> Date: Thu, 11 Mar 2004 10:49:10 -0800 From: Rick Jones 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: tcpm@ietf.org Cc: tsvwg@ietf.org, end2end-interest@postel.org Subject: Re: [Tsvwg] Re: [tcpm] Re: [e2e] Are you interested in TOEs and related issues(Resend) References: <200403110223.i2B2NUt4103646@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Yes, that was one of the first thoughts that came to my mind when I > started looking at this space. Its not just security issues but bugs and > new features. TCP despite being mature still sees couple of RFC or tweaks > a year that needs to be rolled out to existing systems. Apparantly the > TOE vendors had thought about that. The firmware running the protocol code > actually lives on the host and is delivered via exisiting delivery > mechanism (packages in Solaris which can be upgraded). When machine boots > and interface is configured, the protocol firmware is sucked in. So > delivering fix or new revs in pretty similar to exisiting mechanisms. > Also, the source code is still 'C' based so people like me can still > work with it (just need to use some magic in the end to create the > firmware instead of complier). Some vendors we talked to have promised > that they can pretty much suck in the same code that runs on the host > into the card (as long as we can clean some complier specific directives > etc). Although I must admit that this aspect (common source files) of TOE > has not been investigated by us at all so far. That seems like a path out when the TOE is based on an embedded CPU, but doesn't seem like it would work for those TOEs that are ASICs. And a mostly rhetorical question - strictly in the context of TCP comms and not RDMA and the like - if one can code tightly enough for an embedded CPU a TCP/IP stack including comms with the host across the I/O bus with enough performance to be reasonable for a given link, can't one presumeably make the host's TCP/IP stack similarly efficient? If nothing else that seems to be alluded to by the last sentence in the quoted paragraph. 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... _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Mar 11 16:17:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27116 for ; Thu, 11 Mar 2004 16:17:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XYR-0002zd-OM for tcpm-archive@odin.ietf.org; Thu, 11 Mar 2004 16:17:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BLHMuH011499 for tcpm-archive@odin.ietf.org; Thu, 11 Mar 2004 16:17:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XYO-0002zN-Mf for tcpm-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 16:17:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27044 for ; Thu, 11 Mar 2004 16:17:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1XYM-0005uX-00 for tcpm-web-archive@ietf.org; Thu, 11 Mar 2004 16:17:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1XWj-0005RV-00 for tcpm-web-archive@ietf.org; Thu, 11 Mar 2004 16:15:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1XV4-00055S-00 for tcpm-web-archive@ietf.org; Thu, 11 Mar 2004 16:13:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XDy-0008BF-8f; Thu, 11 Mar 2004 15:56:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0xhU-0003et-NR for tcpm@optimus.ietf.org; Wed, 10 Mar 2004 02:00:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24059 for ; Wed, 10 Mar 2004 02:00:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0xhR-0006NU-00 for tcpm@ietf.org; Wed, 10 Mar 2004 02:00:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0xgX-0006Dx-00 for tcpm@ietf.org; Wed, 10 Mar 2004 01:59:22 -0500 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 1B0xfl-00064l-00; Wed, 10 Mar 2004 01:58:33 -0500 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel13.hp.com (Postfix) with ESMTP id B79E41C01CCA; Tue, 9 Mar 2004 22:58:33 -0800 (PST) Received: from MK731916.cup.hp.com ([15.244.200.242]) by esmail.cup.hp.com (8.11.1/8.8.6) with ESMTP id i2A6mf028759; Tue, 9 Mar 2004 22:48:41 -0800 (PST) Message-Id: <6.0.3.0.2.20040309224109.01d6de28@15.13.130.73> X-Sender: krause@15.13.130.73 X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 09 Mar 2004 22:53:34 -0800 To: stanislav shalunov , Sunay Tripathi From: Michael Krause Cc: tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org In-Reply-To: <86y8qf6bvy.fsf@abel.internet2.edu> References: <200403040455.i244twSG699301@jurassic.eng.sun.com> <86y8qf6bvy.fsf@abel.internet2.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [tcpm] Re: [Tsvwg] Re: Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 10:33 PM 3/4/2004, stanislav shalunov wrote: >Sunay Tripathi writes: > > > 1) Extra processor(s) buried in the TOE for networking processing which is > > hidden from the kernel and leaves the host CPU to do more application > > related work. Saves the cost of licences for application which take > > number of CPU into account (oracle is one such application cited). > >One would hope TCP design would not be guided by Oracle licensing quirks. > > > 2) On low end (1-2 CPU) x86 based machines, cost of adding a processor > > is much higher than adding a TOE (I personally haven't verified this). > >It's not obvious why this should necessarily be the case, given that >it is likely that there will continue to be quite a bit more >general-purpose CPUs made than TCP offload engines. > > > 3) For the up and coming 10Gb NICs, TOE will help saturate the link. Some > > vendors assert that TOE will be required to support 10Gb NICs. > >Right now, one can do almost 8Gb/s with a single TCP stream over 10GE >(let's say 5 or 6Gb/s with more common hardware). The limiting factor >is currently host bus speed. There's nothing (except for compression >on the bus side, but it should be clear we're not going there) that an >offload engine can do about host bus speed. By the time host busses >faster than 10Gb/s are commonly available, pretty routine x86 box >should handle 10GE saturation. > > > 4) Performance reasons. Just the LSO aspect of TOE (sending large chunks of > > data and letting the TOE split it up in mss size pieces) and ack > > coalescing gives a pretty good boost (our own prototypes indicates that > > this is true). The gains are by optimizing data movement and not by > > offloading protocol processing. > >Here I would agree with the unnamed TOE vendor whom you're >paraphrasing (and with Jerry Chu's comments in this thread). Ethernet >frame size (1500 bytes or even 9kB) is very small; we'd be in a better >world if we could specify the MTU in units of time (the number of CRC >bits would have to scale up as well, of course). TCP offload engines >could be a kludge that would help to work around this deficiency in >Ethernet. > >Note that since even at 10Gb/s one CPU is enough to saturate the link >with 9kB packets, the need for this work-around is not at all >pressing. Given the potential harmful effects (undetected errors on >the host bus, difficulty in patching stale or buggy TCP code, etc.), >one would probably be better served by concentrating on the deployment >of jumbo frames. The investment to support jumbo frames has largely >already been made, so why not extract all we can from it first? Jumbo frames are not a panacea: - Workloads use a variety of message sizes with many messages being significantly smaller than a jumbo frame - applications are not going to change that rapidly to expand the amount of information they exchange that would benefit from jumbo frames. This is true for IPC, file and storage applications. Some performance benefits have been seen using jumbo frames for services such as a FTP server, but most people don't have a PMTU that will support jumbo frames so the benefit is perhaps confined to a data center. - Jumbo frames cause head-of-line blocking within a fabric so unless one supports multi-pathing / traffic segregation as well as multiple ports on each endnode, low-latency / hi-pri traffic QoS will be negatively impacted. - TCP large send also causes QoS problems as many implementations only work at the message level rather than the frame level so differentiated services / bandwidth management are much harder to implement as these become competing objectives for the point of serialization, i.e. the link. While it is true that at higher link rates, the impacts on QoS may be minimized but the impacts are not eliminated and one would need to do more at the fabric level as well as the NIC implementation level to provide a reasonable solution. As for TOE or RDMA, jumbo isn't really a major benefit. Work is posted for transmission / receipt as single operations and the hardware does the rest of the work independent of the application / CPU. The benefits are demonstrated using existing technology such as InfiniBand (numerous performance analysis papers are publicly available on Linux based implementations) and on some early TCP-based protocol off-load prototypes which confirm similar savings as found with InfiniBand. I think it is fair to say that for selected applications, protocol stack off-load of at least the main data path will result in reduced CPU consumption, reduced memory bus and I/O bus consumption, and improved application performance. Whether this is worthwhile or not is really a judgement call and is somewhat a function of whether one is changing only one end of the wire ala a TOE or both ends ala using a RDMA wire protocol on top of a protocol off-load device. Embedded or host-based (e.g. a server) will see similar resource savings on one hand and will pay a price for those savings on the other hand, i.e. dealing with state and resource management in what is generally implemented as a non-coherent device. Mike _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Mar 11 16:26:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28096 for ; Thu, 11 Mar 2004 16:26:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Xgt-0003Fl-9X for tcpm-archive@odin.ietf.org; Thu, 11 Mar 2004 16:26:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BLQ6i6012497 for tcpm-archive@odin.ietf.org; Thu, 11 Mar 2004 16:26:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Xgn-0003F8-Au for tcpm-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 16:26:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28071 for ; Thu, 11 Mar 2004 16:25:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Xgl-0007ZL-00 for tcpm-web-archive@ietf.org; Thu, 11 Mar 2004 16:25:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Xfs-0007Rv-00 for tcpm-web-archive@ietf.org; Thu, 11 Mar 2004 16:25:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Xf1-0007Jk-00 for tcpm-web-archive@ietf.org; Thu, 11 Mar 2004 16:24:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XDy-0008Bi-Lh; Thu, 11 Mar 2004 15:56:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B15CI-0004W6-Hr for tcpm@optimus.ietf.org; Wed, 10 Mar 2004 10:00:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11898 for ; Wed, 10 Mar 2004 10:00:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B15CG-0005pH-00 for tcpm@ietf.org; Wed, 10 Mar 2004 10:00:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B15BI-0005dQ-00 for tcpm@ietf.org; Wed, 10 Mar 2004 09:59:36 -0500 Received: from aleve.media.mit.edu ([18.85.2.171]) by ietf-mx with esmtp (Exim 4.12) id 1B15AO-0005Re-00; Wed, 10 Mar 2004 09:58:40 -0500 Received: from minke.reed.com (wireless-81.media.mit.edu [18.85.18.81]) by aleve.media.mit.edu (8.9.3p3/8.9.3/+ALEVE) with ESMTP id JAA20541; Wed, 10 Mar 2004 09:58:32 -0500 (EST) Message-Id: <6.0.1.1.2.20040310095034.03103108@127.0.0.1> X-Sender: mail.reed.com:dpreed@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 10 Mar 2004 09:55:18 -0500 To: Sunay Tripathi , David Borman From: "David P. Reed" Subject: Re: [tcpm] Re: [e2e] Are you interested in TOEs and related issues (Resend) Cc: Craig Partridge , tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org, Sunay Tripathi In-Reply-To: <6.0.1.1.2.20040309181340.05209120@127.0.0.1> References: <510B9F0C-6DAB-11D8-AE57-000A95D7D4C0@cray.com> <200403092143.i29LhVVQ348812@jurassic.eng.sun.com> <6.0.1.1.2.20040309181340.05209120@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 06:29 PM 3/9/2004, David P. Reed wrote: >I wouldn't waste my time on TOEs. There are more useful things to work >on, like making end-to-end secure and resilient communications practical. To clarify this, if it seems like a non-sequitur or change in topic, remember that offloading TCP into a separate box locks in any security flaws into the architectural structure you had to create to make it happen. In practice, this means that no one will have the energy or money to fix the security and resiliency issues in such solutions - which means more kludges in wrap-around devices and interceptors that create the false illusion of security. Communications networking is a systems problem, and ignoring the systems issues by focusing on a narrow problem space is not a good investment of effort. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Mar 12 09:46:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24440 for ; Fri, 12 Mar 2004 09:46:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nus-0003l7-LS for tcpm-archive@odin.ietf.org; Fri, 12 Mar 2004 09:45:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CEjc6V014443 for tcpm-archive@odin.ietf.org; Fri, 12 Mar 2004 09:45:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nus-0003ks-G0 for tcpm-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 09:45:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24427 for ; Fri, 12 Mar 2004 09:45:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1nuq-0006mo-00 for tcpm-web-archive@ietf.org; Fri, 12 Mar 2004 09:45:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1nu1-0006fF-00 for tcpm-web-archive@ietf.org; Fri, 12 Mar 2004 09:44:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1ntH-0006XE-00 for tcpm-web-archive@ietf.org; Fri, 12 Mar 2004 09:43:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nWE-0001dD-8H; Fri, 12 Mar 2004 09:20:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nVk-0001aa-Tl for tcpm@optimus.ietf.org; Fri, 12 Mar 2004 09:19:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22987 for ; Fri, 12 Mar 2004 09:19:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1nVj-0002xu-00 for tcpm@ietf.org; Fri, 12 Mar 2004 09:19:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1nVD-0002pi-00 for tcpm@ietf.org; Fri, 12 Mar 2004 09:19:08 -0500 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1B1nUE-0002Wy-00 for tcpm@ietf.org; Fri, 12 Mar 2004 09:18:06 -0500 Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id B64DD77AA17 for ; Fri, 12 Mar 2004 09:17:34 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Reply-To: mallman@icir.org Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Mama Kin MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 12 Mar 2004 09:17:34 -0500 Message-Id: <20040312141734.B64DD77AA17@guns.icir.org> Subject: [tcpm] frto Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-=-= Hello! As discussed at the meeting last week we'd like to encourage folks to read and comment on the F-RTO draft: draft-ietf-tsvwg-tcp-frto-01.txt. Based on the feedback we've received so far it seems like all the large issues have been working out of this draft and it is near ready to be forwarded. We'd like folks to read the document and send any remaining issues to the list. Thanks! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAUcZ+WyrrWs4yIs4RAunvAJ9I6p+Fo2uEg1zqf49BrX3CtWJ4xgCePh+f wmEtTAUgEjVes2dKw8NBy2M= =3IZW -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Mar 15 23:36:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22745 for ; Mon, 15 Mar 2004 23:36:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B36Iq-0000B5-N3 for tcpm-archive@odin.ietf.org; Mon, 15 Mar 2004 23:35:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2G4Ziv7000682 for tcpm-archive@odin.ietf.org; Mon, 15 Mar 2004 23:35:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B36Iq-0000At-HW for tcpm-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 23:35:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22738 for ; Mon, 15 Mar 2004 23:35:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B36Io-0003iq-00 for tcpm-web-archive@ietf.org; Mon, 15 Mar 2004 23:35:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B36Hu-0003cy-00 for tcpm-web-archive@ietf.org; Mon, 15 Mar 2004 23:34:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B36HC-0003XD-00 for tcpm-web-archive@ietf.org; Mon, 15 Mar 2004 23:34:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B36HC-00005I-8l; Mon, 15 Mar 2004 23:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B36Gx-0008Vz-Sd for tcpm@optimus.ietf.org; Mon, 15 Mar 2004 23:33:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22581 for ; Mon, 15 Mar 2004 23:33:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B36Gv-0003WC-00 for tcpm@ietf.org; Mon, 15 Mar 2004 23:33:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B36Fz-0003QA-00 for tcpm@ietf.org; Mon, 15 Mar 2004 23:32:48 -0500 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1B36FJ-0003K4-00 for tcpm@ietf.org; Mon, 15 Mar 2004 23:32:05 -0500 Received: from lawyers.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by guns.icir.org (Postfix) with ESMTP id A30CB77AA55; Mon, 15 Mar 2004 23:31:33 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 0C23C111E24; Mon, 15 Mar 2004 23:31:24 -0500 (EST) To: Pekka Savola From: Mark Allman Reply-To: mallman@icir.org Cc: tcpm@ietf.org, v6ops@ops.ietf.org, sebastien.roy@sun.com Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Jailhouse Rock MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 15 Mar 2004 23:31:23 -0500 Message-Id: <20040316043124.0C23C111E24@lawyers.icir.org> Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-=-= (catching up) > The critical observation to make here is as IPv6 addresses are tried > first (I'm simplifying; it's more complex than that), one must cycle > through all the addresses, before trying with IPv4. However, IPv4 > connections might still work! With TCP timeouts, this takes a lot of > time --- and should be made quicker. Speaking personally, I think what you have written is fine and would not block the document on it. > There is going to be a WG last call on the document soon, aimed for > Informational -- just for documenting the issues. The actual fixes > (or not) would have to be done elsewhere (e.g., in TCPM WG ;-). Speaking as tcpm co-chair, yeah - we'd certainly be game to help out here. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAVoMbWyrrWs4yIs4RAmZ5AKCF3gmY1wWW3sbeFwcnBH35hIOrlACeKi6y H7MCcmIkLI9ENQtdHdDw8C4= =dBDy -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 16 20:26:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10603 for ; Tue, 16 Mar 2004 20:26:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Pp9-0002Gs-PG for tcpm-archive@odin.ietf.org; Tue, 16 Mar 2004 20:26:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H1QNwA008715 for tcpm-archive@odin.ietf.org; Tue, 16 Mar 2004 20:26:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Pp9-0002GP-Gr for tcpm-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 20:26:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10471 for ; Tue, 16 Mar 2004 20:26:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Pp7-0000iE-00 for tcpm-web-archive@ietf.org; Tue, 16 Mar 2004 20:26:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Pmi-0000CE-00 for tcpm-web-archive@ietf.org; Tue, 16 Mar 2004 20:23:54 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3PkY-0007h8-00 for tcpm-web-archive@ietf.org; Tue, 16 Mar 2004 20:21:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3PYN-0005qn-Ne for tcpm-web-archive@ietf.org; Tue, 16 Mar 2004 20:09:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PYL-0001gp-8z; Tue, 16 Mar 2004 20:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PXQ-0001Ws-VU for tcpm@optimus.ietf.org; Tue, 16 Mar 2004 20:08:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09935 for ; Tue, 16 Mar 2004 20:08:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3PXP-0006dJ-00 for tcpm@ietf.org; Tue, 16 Mar 2004 20:08:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3PWS-0006RU-00 for tcpm@ietf.org; Tue, 16 Mar 2004 20:07:04 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151] helo=i2kc04-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1B3PUz-00063P-00 for tcpm@ietf.org; Tue, 16 Mar 2004 20:05:34 -0500 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Wed, 17 Mar 2004 01:01:08 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 05:37:49 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079415468644; Tue, 16 Mar 2004 05:37:48 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 05:37:47 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B37DK-000AGA-Ef for v6ops-data@psg.com; Tue, 16 Mar 2004 05:34:06 +0000 Received: from [68.76.113.50] (helo=guns.icir.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B36Eq-0001rh-DW for v6ops@ops.ietf.org; Tue, 16 Mar 2004 04:31:36 +0000 Received: from lawyers.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by guns.icir.org (Postfix) with ESMTP id A30CB77AA55; Mon, 15 Mar 2004 23:31:33 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 0C23C111E24; Mon, 15 Mar 2004 23:31:24 -0500 (EST) To: Pekka Savola From: Mark Allman Reply-To: mallman@icir.org Cc: tcpm@ietf.org, v6ops@ops.ietf.org, sebastien.roy@sun.com Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Jailhouse Rock MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 15 Mar 2004 23:31:23 -0500 Message-Id: <20040316043124.0C23C111E24@lawyers.icir.org> Precedence: bulk X-OriginalArrivalTime: 16 Mar 2004 05:37:48.0035 (UTC) FILETIME=[D09DF530:01C40B18] Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-=-= (catching up) > The critical observation to make here is as IPv6 addresses are tried > first (I'm simplifying; it's more complex than that), one must cycle > through all the addresses, before trying with IPv4. However, IPv4 > connections might still work! With TCP timeouts, this takes a lot of > time --- and should be made quicker. Speaking personally, I think what you have written is fine and would not block the document on it. > There is going to be a WG last call on the document soon, aimed for > Informational -- just for documenting the issues. The actual fixes > (or not) would have to be done elsewhere (e.g., in TCPM WG ;-). Speaking as tcpm co-chair, yeah - we'd certainly be game to help out here. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAVoMbWyrrWs4yIs4RAmZ5AKCF3gmY1wWW3sbeFwcnBH35hIOrlACeKi6y H7MCcmIkLI9ENQtdHdDw8C4= =dBDy -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 16 20:26:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10631 for ; Tue, 16 Mar 2004 20:26:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PpC-0002HE-7f for tcpm-archive@odin.ietf.org; Tue, 16 Mar 2004 20:26:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H1QQLt008746 for tcpm-archive@odin.ietf.org; Tue, 16 Mar 2004 20:26:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PpC-0002Gz-1P for tcpm-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 20:26:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10481 for ; Tue, 16 Mar 2004 20:26:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3PpA-0000j7-00 for tcpm-web-archive@ietf.org; Tue, 16 Mar 2004 20:26:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Pmk-0000Ch-00 for tcpm-web-archive@ietf.org; Tue, 16 Mar 2004 20:23:56 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3PkZ-0007h8-00 for tcpm-web-archive@ietf.org; Tue, 16 Mar 2004 20:21:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3PYN-0005ql-Ha for tcpm-web-archive@ietf.org; Tue, 16 Mar 2004 20:09:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PYK-0001gZ-Pr; Tue, 16 Mar 2004 20:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PXO-0001Vx-U9 for tcpm@optimus.ietf.org; Tue, 16 Mar 2004 20:08:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09929 for ; Tue, 16 Mar 2004 20:08:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3PXM-0006d2-00 for tcpm@ietf.org; Tue, 16 Mar 2004 20:08:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3PWO-0006Pj-00 for tcpm@ietf.org; Tue, 16 Mar 2004 20:07:01 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151] helo=i2kc04-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1B3PUw-00063P-00 for tcpm@ietf.org; Tue, 16 Mar 2004 20:05:31 -0500 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Wed, 17 Mar 2004 01:00:44 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 05:37:49 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079415468644; Tue, 16 Mar 2004 05:37:48 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 05:37:47 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B37DK-000AGA-Ef for v6ops-data@psg.com; Tue, 16 Mar 2004 05:34:06 +0000 Received: from [68.76.113.50] (helo=guns.icir.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B36Eq-0001rh-DW for v6ops@ops.ietf.org; Tue, 16 Mar 2004 04:31:36 +0000 Received: from lawyers.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by guns.icir.org (Postfix) with ESMTP id A30CB77AA55; Mon, 15 Mar 2004 23:31:33 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 0C23C111E24; Mon, 15 Mar 2004 23:31:24 -0500 (EST) To: Pekka Savola From: Mark Allman Reply-To: mallman@icir.org Cc: tcpm@ietf.org, v6ops@ops.ietf.org, sebastien.roy@sun.com Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Jailhouse Rock MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 15 Mar 2004 23:31:23 -0500 Message-Id: <20040316043124.0C23C111E24@lawyers.icir.org> Precedence: bulk X-OriginalArrivalTime: 16 Mar 2004 05:37:48.0035 (UTC) FILETIME=[D09DF530:01C40B18] Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-=-= (catching up) > The critical observation to make here is as IPv6 addresses are tried > first (I'm simplifying; it's more complex than that), one must cycle > through all the addresses, before trying with IPv4. However, IPv4 > connections might still work! With TCP timeouts, this takes a lot of > time --- and should be made quicker. Speaking personally, I think what you have written is fine and would not block the document on it. > There is going to be a WG last call on the document soon, aimed for > Informational -- just for documenting the issues. The actual fixes > (or not) would have to be done elsewhere (e.g., in TCPM WG ;-). Speaking as tcpm co-chair, yeah - we'd certainly be game to help out here. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAVoMbWyrrWs4yIs4RAmZ5AKCF3gmY1wWW3sbeFwcnBH35hIOrlACeKi6y H7MCcmIkLI9ENQtdHdDw8C4= =dBDy -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 16 20:26:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10651 for ; Tue, 16 Mar 2004 20:26:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PpC-0002HW-Um for tcpm-archive@odin.ietf.org; Tue, 16 Mar 2004 20:26:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H1QQRV008764 for tcpm-archive@odin.ietf.org; Tue, 16 Mar 2004 20:26:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PpC-0002HH-Oq for tcpm-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 20:26:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10485 for ; Tue, 16 Mar 2004 20:26:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3PpA-0000jE-00 for tcpm-web-archive@ietf.org; Tue, 16 Mar 2004 20:26:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Pmm-0000Ct-00 for tcpm-web-archive@ietf.org; Tue, 16 Mar 2004 20:23:57 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3PkZ-0007hu-00 for tcpm-web-archive@ietf.org; Tue, 16 Mar 2004 20:21:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3PYN-0005qm-Ul for tcpm-web-archive@ietf.org; Tue, 16 Mar 2004 20:09:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PYL-0001gh-0o; Tue, 16 Mar 2004 20:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PXQ-0001WX-Ae for tcpm@optimus.ietf.org; Tue, 16 Mar 2004 20:08:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09932 for ; Tue, 16 Mar 2004 20:08:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3PXO-0006dC-00 for tcpm@ietf.org; Tue, 16 Mar 2004 20:08:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3PWR-0006Qr-00 for tcpm@ietf.org; Tue, 16 Mar 2004 20:07:03 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151] helo=i2kc04-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1B3PUy-00063P-00 for tcpm@ietf.org; Tue, 16 Mar 2004 20:05:32 -0500 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Wed, 17 Mar 2004 01:00:44 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 05:37:49 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079415468644; Tue, 16 Mar 2004 05:37:48 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 05:37:47 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B37DK-000AGA-Ef for v6ops-data@psg.com; Tue, 16 Mar 2004 05:34:06 +0000 Received: from [68.76.113.50] (helo=guns.icir.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B36Eq-0001rh-DW for v6ops@ops.ietf.org; Tue, 16 Mar 2004 04:31:36 +0000 Received: from lawyers.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by guns.icir.org (Postfix) with ESMTP id A30CB77AA55; Mon, 15 Mar 2004 23:31:33 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 0C23C111E24; Mon, 15 Mar 2004 23:31:24 -0500 (EST) To: Pekka Savola From: Mark Allman Reply-To: mallman@icir.org Cc: tcpm@ietf.org, v6ops@ops.ietf.org, sebastien.roy@sun.com Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Jailhouse Rock MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 15 Mar 2004 23:31:23 -0500 Message-Id: <20040316043124.0C23C111E24@lawyers.icir.org> Precedence: bulk X-OriginalArrivalTime: 16 Mar 2004 05:37:48.0035 (UTC) FILETIME=[D09DF530:01C40B18] Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-=-= (catching up) > The critical observation to make here is as IPv6 addresses are tried > first (I'm simplifying; it's more complex than that), one must cycle > through all the addresses, before trying with IPv4. However, IPv4 > connections might still work! With TCP timeouts, this takes a lot of > time --- and should be made quicker. Speaking personally, I think what you have written is fine and would not block the document on it. > There is going to be a WG last call on the document soon, aimed for > Informational -- just for documenting the issues. The actual fixes > (or not) would have to be done elsewhere (e.g., in TCPM WG ;-). Speaking as tcpm co-chair, yeah - we'd certainly be game to help out here. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAVoMbWyrrWs4yIs4RAmZ5AKCF3gmY1wWW3sbeFwcnBH35hIOrlACeKi6y H7MCcmIkLI9ENQtdHdDw8C4= =dBDy -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 16 21:12:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10602 for ; Tue, 16 Mar 2004 20:26:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Pp9-0002Gr-Oy for tcpm-archive@odin.ietf.org; Tue, 16 Mar 2004 20:26:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H1QNXn008714 for tcpm-archive@odin.ietf.org; Tue, 16 Mar 2004 20:26:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Pp9-0002GO-CF for tcpm-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 20:26:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10469 for ; Tue, 16 Mar 2004 20:26:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Pp7-0000iM-00 for tcpm-web-archive@ietf.org; Tue, 16 Mar 2004 20:26:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Pmi-0000CM-00 for tcpm-web-archive@ietf.org; Tue, 16 Mar 2004 20:23:53 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3PkY-0007hu-00 for tcpm-web-archive@ietf.org; Tue, 16 Mar 2004 20:21:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3PYN-0005qo-Up for tcpm-web-archive@ietf.org; Tue, 16 Mar 2004 20:09:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PYL-0001ha-In; Tue, 16 Mar 2004 20:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PXS-0001X5-8B for tcpm@optimus.ietf.org; Tue, 16 Mar 2004 20:08:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09938 for ; Tue, 16 Mar 2004 20:08:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3PXQ-0006dT-00 for tcpm@ietf.org; Tue, 16 Mar 2004 20:08:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3PWU-0006ST-00 for tcpm@ietf.org; Tue, 16 Mar 2004 20:07:07 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151] helo=i2kc04-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1B3PV1-00063P-00 for tcpm@ietf.org; Tue, 16 Mar 2004 20:05:35 -0500 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Wed, 17 Mar 2004 01:01:09 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 05:37:49 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079415468644; Tue, 16 Mar 2004 05:37:48 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 05:37:47 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B37DK-000AGA-Ef for v6ops-data@psg.com; Tue, 16 Mar 2004 05:34:06 +0000 Received: from [68.76.113.50] (helo=guns.icir.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B36Eq-0001rh-DW for v6ops@ops.ietf.org; Tue, 16 Mar 2004 04:31:36 +0000 Received: from lawyers.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by guns.icir.org (Postfix) with ESMTP id A30CB77AA55; Mon, 15 Mar 2004 23:31:33 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 0C23C111E24; Mon, 15 Mar 2004 23:31:24 -0500 (EST) To: Pekka Savola From: Mark Allman Reply-To: mallman@icir.org Cc: tcpm@ietf.org, v6ops@ops.ietf.org, sebastien.roy@sun.com Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Jailhouse Rock MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 15 Mar 2004 23:31:23 -0500 Message-Id: <20040316043124.0C23C111E24@lawyers.icir.org> Precedence: bulk X-OriginalArrivalTime: 16 Mar 2004 05:37:48.0035 (UTC) FILETIME=[D09DF530:01C40B18] Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-=-= (catching up) > The critical observation to make here is as IPv6 addresses are tried > first (I'm simplifying; it's more complex than that), one must cycle > through all the addresses, before trying with IPv4. However, IPv4 > connections might still work! With TCP timeouts, this takes a lot of > time --- and should be made quicker. Speaking personally, I think what you have written is fine and would not block the document on it. > There is going to be a WG last call on the document soon, aimed for > Informational -- just for documenting the issues. The actual fixes > (or not) would have to be done elsewhere (e.g., in TCPM WG ;-). Speaking as tcpm co-chair, yeah - we'd certainly be game to help out here. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAVoMbWyrrWs4yIs4RAmZ5AKCF3gmY1wWW3sbeFwcnBH35hIOrlACeKi6y H7MCcmIkLI9ENQtdHdDw8C4= =dBDy -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Mar 19 11:23:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10170 for ; Fri, 19 Mar 2004 11:23:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Mm7-0001cR-09 for tcpm-archive@odin.ietf.org; Fri, 19 Mar 2004 11:23:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JGNA0W006223 for tcpm-archive@odin.ietf.org; Fri, 19 Mar 2004 11:23:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Mm6-0001cI-Ps for tcpm-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 11:23:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10133 for ; Fri, 19 Mar 2004 11:23:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Mm6-0006rT-00 for tcpm-web-archive@ietf.org; Fri, 19 Mar 2004 11:23:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Ml6-0006je-00 for tcpm-web-archive@ietf.org; Fri, 19 Mar 2004 11:22:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4Mk8-0006bp-00 for tcpm-web-archive@ietf.org; Fri, 19 Mar 2004 11:21:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Mk3-0001WO-Eh; Fri, 19 Mar 2004 11:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4MjS-0001Ui-F2 for tcpm@optimus.ietf.org; Fri, 19 Mar 2004 11:20:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10005 for ; Fri, 19 Mar 2004 11:20:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4MjR-0006WY-00 for tcpm@ietf.org; Fri, 19 Mar 2004 11:20:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4MiV-0006QC-00 for tcpm@ietf.org; Fri, 19 Mar 2004 11:19:28 -0500 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by ietf-mx with esmtp (Exim 4.12) id 1B4Mhs-0006Dr-00 for tcpm@ietf.org; Fri, 19 Mar 2004 11:18:48 -0500 Received: from fernando.gont.com.ar ([200.68.222.242]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id NAA13316; Fri, 19 Mar 2004 13:46:38 -0400 Message-Id: <4.3.2.7.2.20040319123019.00bfc520@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 19 Mar 2004 13:27:29 -0300 To: Pekka Savola , tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting Cc: v6ops@ops.ietf.org, In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 04:52 05/03/2004 +0200, Pekka Savola wrote: >TCP timeouts when connecting to a destination, but when the >destination is unreachable (e.g., because you don't have global IPv6 >routes, your first-hop router is not operational, the packets are sent >on-link by default, etc.), TCP does not abort the connectivity (and >try the next address quicker -- instead of waiting for the TCP >timeout). Not sure if I got it right. Do you mean TCP does not abort the conectivity, and thus the *application* cannot try the next address quicker? >2.3.1.1 TCP Connection Termination > One solution is for TCP to abort connections in SYN-SENT or > SYN-RECEIVED state when it receives an ICMPv6 Destination Unreachable > message. But what if this scenario arises for all the addresses, because of a transient problem? The application won't cycle again, and will return an error. And the *transient* problem could disappear perhaps 5 seconds later... IMHO, if you had a "higher-level" connect(), this behavior would make sense, as you could handle the whole issue, in a transparent way to the application. Does it really make sense to handle the whole connection establishment issue inside the app, instead of inside the API itself? I think that if we're debating this, we're implicitly assuming that applications want to connect to say www.example.com, and not one specific IP address to which it maps to. So why not implement such a "higher-level" connect(), and handle all the relevant issues inside the API? > When [HOSTREQS] was written, most applications would mostly only try > one address when establishing communication with a destination. Not > aborting a connection was a sane thing to do if re-trying a single > address was a better alternative over quitting the application > altogether. With IPv6, and especially on dual stack systems, > destinations are often assigned multiple addresses (at least one IPv4 > and one IPv6 address), and applications iterate through destination > addresses when attempting connections. Doesn't the problem really have to do with having applications performing such a low-level action? Just my two cents, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Mar 22 06:14:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16356 for ; Mon, 22 Mar 2004 06:14:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5NNN-0007lP-BI for tcpm-archive@odin.ietf.org; Mon, 22 Mar 2004 06:13:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MBDcOV029807 for tcpm-archive@odin.ietf.org; Mon, 22 Mar 2004 06:13:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5NNA-0007kW-TF for tcpm-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 06:13:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16349 for ; Mon, 22 Mar 2004 06:13:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5NN1-0000U8-00 for tcpm-web-archive@ietf.org; Mon, 22 Mar 2004 06:13:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5NMC-0000O1-00 for tcpm-web-archive@ietf.org; Mon, 22 Mar 2004 06:12:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5NLo-0000HI-00 for tcpm-web-archive@ietf.org; Mon, 22 Mar 2004 06:12:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5NLp-0007eL-Oh; Mon, 22 Mar 2004 06:12:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5NL8-0007dA-G2 for tcpm@optimus.ietf.org; Mon, 22 Mar 2004 06:11:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16254 for ; Mon, 22 Mar 2004 06:11:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5NL4-0000E2-00 for tcpm@ietf.org; Mon, 22 Mar 2004 06:11:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5NK4-00007j-00 for tcpm@ietf.org; Mon, 22 Mar 2004 06:10:24 -0500 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by ietf-mx with esmtp (Exim 4.12) id 1B5NJS-0007l2-00 for tcpm@ietf.org; Mon, 22 Mar 2004 06:09:47 -0500 Received: from fernando.gont.com.ar ([200.68.222.175]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id IAA24427; Mon, 22 Mar 2004 08:38:21 -0400 Message-Id: <4.3.2.7.2.20040322073643.00b1b4a0@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 Mar 2004 08:18:12 -0300 To: Pekka Savola From: Fernando Gont Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting Cc: tcpm@ietf.org, , In-Reply-To: References: <4.3.2.7.2.20040319123019.00bfc520@mail.daleclick.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 16:39 20/03/2004 +0200, Pekka Savola wrote: > > Does it really make sense to handle the whole connection establishment > > issue inside the app, instead of inside the API itself? >Those are the core APIs we have today. We could have better ones, but >IMHO I think we need to fix problems in the current ones as long as we >don't have a widely-deployed alternative. IMHO, there are two points to note: * If you fix the current ones so that their behavior is "acceptable" to the application programmer, then it'll be harder to introduce a new API. People is reluctant to change, so they must have a reason for learning a new API. If you try to fix the current one, they will find fewer reasons for the change. * You said "we don't have a widely-deployed alternative". Unless you meant "we don't have a well-tested alternative", I'd say that it's a chicken-and-egg problem. That means, for an API to be widely deployed, people would have to use it. And for people to use it, they should be able to find a good reason to do it. Yes, I'm aware that my proposal my sound as a long-term solution. But, IMHO, it will certainly be harder to introduce a new API if you actually want to do it "in long term". I guess "timing" is an issue, here. > > I think that if we're debating this, we're implicitly assuming that > > applications want to connect to say www.example.com, and not one specific > > IP address to which it maps to. > > > > So why not implement such a "higher-level" connect(), and handle all the > > relevant issues inside the API? > >Defining such APIs is probably beyond the scope of the work we can do, >and the things we can fix except in the 5+ year timeframe.. but if I >get you right, you're proposing that instead of: > > 1) getaddrinfo() or gethostbyname() and connect for one address, >[where, arguably, TCP retry timeout could be warranted -- I don't >think so myself, but you could argue for it] > > 2) getaddrinfo() / gethostbyname() loop to connect to one address >[where TCP retry timeout could not be warranted] > >You'd be proposing to create a new function to accomplish 2) in such a >manner that it would also react to ICMP messages, etc? Exactly. Then, within that function, each individual connect() could react to ICMP messages a as you proposed, but if all addresses fail because of ICMP errors, it could let TCP retry in the hope the transiet problem will dissappear. [....] > > Doesn't the problem really have to do with having applications performing > > such a low-level action? > >At some point, someone has to decide which behaviour is desirable. >Isn't this only hiding the same policy decision inside an abstraction >layer Yes, but even when the difference may sound subtle, IMHO it's not. Having that abstraction layer is what let's you choose a policy, without having the risk of causing any harm to existing apps. That way, if you ever need to change the low-level-connect() behavoir for whatever reason, you could still do it. As far as the high-level connect() behaves the same, there would be no problem. Think about it. Why should an application programmer care about TCP retries, ICMP erros, an the like? In the same way, why should he care about setting "strange" options such as SO_REUSEADDR on his listening socket? Should *he* really handle byte-ordering issues by means of htons() and the like? >-- and the same could be achieved by e.g. a setsockopt() flag? Strictly speaking, you *could* do that. But then you'd have all programmers implementing themselves a function you could provide them. You'd have all them implementing the getaddrinfo()/gethostbyname() loop, setting a strange socket option, etc. Why not provide them with a well-tested function, and let them spend their time implementing their application itself? >(I don't deny that better APIs would not hurt, but we still seem to >require low-level C-like primitives, and unless there are additional >ones implemented there, we still have to fix the problems somehow..) Well, the low-level ones could be provided as part of the new API. Or along with the providing a new API, the current one could be modified as you suggest. It wouldn't hurt too much if the *low-level* API aborted a connection establishment because an ICMP error is received. Being a *low-level* API, you'd be suppossed to know the details behind the function. Best Regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 23 18:06:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09476 for ; Tue, 23 Mar 2004 18:06:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uxq-0004Dw-4Z for tcpm-archive@odin.ietf.org; Tue, 23 Mar 2004 18:05:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NN5gXv016233 for tcpm-archive@odin.ietf.org; Tue, 23 Mar 2004 18:05:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uxp-0004DN-Dz for tcpm-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 18:05:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09409 for ; Tue, 23 Mar 2004 18:05:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uxm-0006oj-00 for tcpm-web-archive@ietf.org; Tue, 23 Mar 2004 18:05:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5uwt-0006kY-00 for tcpm-web-archive@ietf.org; Tue, 23 Mar 2004 18:04:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5uwE-0006gO-00 for tcpm-web-archive@ietf.org; Tue, 23 Mar 2004 18:04:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uwD-0003ev-AW; Tue, 23 Mar 2004 18:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4hen-0003ZV-VG for tcpm@optimus.ietf.org; Sat, 20 Mar 2004 09:41:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11602 for ; Sat, 20 Mar 2004 09:40:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4hem-0006Hq-00 for tcpm@ietf.org; Sat, 20 Mar 2004 09:41:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4hdq-0006C8-00 for tcpm@ietf.org; Sat, 20 Mar 2004 09:40:02 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4hdT-00065l-00 for tcpm@ietf.org; Sat, 20 Mar 2004 09:39:39 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2KEd0d08088; Sat, 20 Mar 2004 16:39:01 +0200 Date: Sat, 20 Mar 2004 16:39:00 +0200 (EET) From: Pekka Savola To: Fernando Gont cc: tcpm@ietf.org, , Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting In-Reply-To: <4.3.2.7.2.20040319123019.00bfc520@mail.daleclick.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 19 Mar 2004, Fernando Gont wrote: > At 04:52 05/03/2004 +0200, Pekka Savola wrote: > >TCP timeouts when connecting to a destination, but when the > >destination is unreachable (e.g., because you don't have global IPv6 > >routes, your first-hop router is not operational, the packets are sent > >on-link by default, etc.), TCP does not abort the connectivity (and > >try the next address quicker -- instead of waiting for the TCP > >timeout). > > Not sure if I got it right. Do you mean TCP does not abort the conectivity, > and thus the *application* cannot try the next address quicker? Yep, that's what I meant (and by application, I mean both the app and the APIs/libraries it's using). > >2.3.1.1 TCP Connection Termination > > One solution is for TCP to abort connections in SYN-SENT or > > SYN-RECEIVED state when it receives an ICMPv6 Destination Unreachable > > message. > > But what if this scenario arises for all the addresses, because of a > transient problem? > The application won't cycle again, and will return an error. And the > *transient* problem could disappear perhaps 5 seconds later... Note that this applies to new connections only. Yes, this is a trade-off. The assumption is that with big transient problems, all the addresses {at least of the same address family} are unreachable, or none of them are. So, you either have to choose between having TCP connect() try retrying for dozens of seconds (hoping the transient to go away) or failing completely. The tradeoff recommended was that it's better to fail completely; this works better for transient and non-transient failures, except for the case where the transient failure was so short that the TCP retry mechanism could be the feasible failure recovery mechanism for that. I don't think it is.. Obviously, there could be a flag to indicate to the stack whether you want this behaviour or not. > Does it really make sense to handle the whole connection establishment > issue inside the app, instead of inside the API itself? Those are the core APIs we have today. We could have better ones, but IMHO I think we need to fix problems in the current ones as long as we don't have a widely-deployed alternative. > I think that if we're debating this, we're implicitly assuming that > applications want to connect to say www.example.com, and not one specific > IP address to which it maps to. > > So why not implement such a "higher-level" connect(), and handle all the > relevant issues inside the API? Defining such APIs is probably beyond the scope of the work we can do, and the things we can fix except in the 5+ year timeframe.. but if I get you right, you're proposing that instead of: 1) getaddrinfo() or gethostbyname() and connect for one address, [where, arguably, TCP retry timeout could be warranted -- I don't think so myself, but you could argue for it] 2) getaddrinfo() / gethostbyname() loop to connect to one address [where TCP retry timeout could not be warranted] You'd be proposing to create a new function to accomplish 2) in such a manner that it would also react to ICMP messages, etc? > > When [HOSTREQS] was written, most applications would mostly only try > > one address when establishing communication with a destination. Not > > aborting a connection was a sane thing to do if re-trying a single > > address was a better alternative over quitting the application > > altogether. With IPv6, and especially on dual stack systems, > > destinations are often assigned multiple addresses (at least one IPv4 > > and one IPv6 address), and applications iterate through destination > > addresses when attempting connections. > > Doesn't the problem really have to do with having applications performing > such a low-level action? At some point, someone has to decide which behaviour is desirable. Isn't this only hiding the same policy decision inside an abstraction layer -- and the same could be achieved by e.g. a setsockopt() flag? (I don't deny that better APIs would not hurt, but we still seem to require low-level C-like primitives, and unless there are additional ones implemented there, we still have to fix the problems somehow..) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 23 20:12:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16231 for ; Tue, 23 Mar 2004 20:12:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wvr-0003in-Vj for tcpm-archive@odin.ietf.org; Tue, 23 Mar 2004 20:11:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O1BlhB014301 for tcpm-archive@odin.ietf.org; Tue, 23 Mar 2004 20:11:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wvr-0003ia-Qj for tcpm-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 20:11:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16125 for ; Tue, 23 Mar 2004 20:11:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5wvp-0001wv-00 for tcpm-web-archive@ietf.org; Tue, 23 Mar 2004 20:11:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5wuq-0001lS-00 for tcpm-web-archive@ietf.org; Tue, 23 Mar 2004 20:10:44 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5wtt-0001dC-01 for tcpm-web-archive@ietf.org; Tue, 23 Mar 2004 20:09:45 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5wqK-0002Hl-6K for tcpm-web-archive@ietf.org; Tue, 23 Mar 2004 20:06:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wqG-0002zZ-A8; Tue, 23 Mar 2004 20:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wps-0002z4-7c for tcpm@optimus.ietf.org; Tue, 23 Mar 2004 20:05:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15919 for ; Tue, 23 Mar 2004 20:05:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5wpq-0001Qi-00 for tcpm@ietf.org; Tue, 23 Mar 2004 20:05:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5wor-0001Ni-00 for tcpm@ietf.org; Tue, 23 Mar 2004 20:04:34 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1B5wnw-0001KE-00 for tcpm@ietf.org; Tue, 23 Mar 2004 20:03:36 -0500 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2O12Nq16933 for ; Tue, 23 Mar 2004 17:02:23 -0800 (PST) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.12.10/8.12.10) with ESMTP id i2O12WBZ072304 for ; Tue, 23 Mar 2004 17:02:32 -0800 (PST) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.12.10/8.12.10/Submit) id i2O12WGT072303 for tcpm@ietf.org; Tue, 23 Mar 2004 17:02:32 -0800 (PST) (envelope-from faber) Date: Tue, 23 Mar 2004 17:02:32 -0800 From: Ted Faber To: tcpm@ietf.org Message-ID: <20040324010232.GY68552@pun.isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w+MAdceOglSEzbpc" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4.28.6-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu Subject: [tcpm] Last chance for corrections to minutes Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --w+MAdceOglSEzbpc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'll be submitting the minutes to the IETF for inclusion in the proceedings on 24 Mar 2004. I have seen no major corrections on them, but if you've been keeping corrections to yourself, please let me know. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --w+MAdceOglSEzbpc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAYN4naUz3f+Zf+XsRApO1AKCP7hOtutLFCUCAD6KtoKoB9W4a/QCg0Blo yr2p26RaCQAGalwsxHPOXO4= =PTRa -----END PGP SIGNATURE----- --w+MAdceOglSEzbpc-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Mar 26 17:47:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22334 for ; Fri, 26 Mar 2004 17:47:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B706k-0001so-No for tcpm-archive@odin.ietf.org; Fri, 26 Mar 2004 17:47:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QMlMBp007234 for tcpm-archive@odin.ietf.org; Fri, 26 Mar 2004 17:47:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B706k-0001sb-Fz for tcpm-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 17:47:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22326 for ; Fri, 26 Mar 2004 17:47:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B706h-0001gf-00 for tcpm-web-archive@ietf.org; Fri, 26 Mar 2004 17:47:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B705m-0001dn-00 for tcpm-web-archive@ietf.org; Fri, 26 Mar 2004 17:46:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B705S-0001ad-00 for tcpm-web-archive@ietf.org; Fri, 26 Mar 2004 17:46:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B705R-0001hF-TO; Fri, 26 Mar 2004 17:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6zMK-0007Lm-N2 for tcpm@optimus.ietf.org; Fri, 26 Mar 2004 16:59:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19767 for ; Fri, 26 Mar 2004 16:59:21 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6zMI-0005Q1-00 for tcpm@ietf.org; Fri, 26 Mar 2004 16:59:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6zLX-0005Ko-00 for tcpm@ietf.org; Fri, 26 Mar 2004 16:58:35 -0500 Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx with esmtp (Exim 4.12) id 1B6zKn-0005Cp-00; Fri, 26 Mar 2004 16:57:49 -0500 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id ABC5E27F5C; Fri, 26 Mar 2004 14:57:49 -0700 (MST) Received: from wcosbh22.cos.agilent.com (wcosbh22.cos.agilent.com [130.29.152.178]) by relcos1.cos.agilent.com (Postfix) with ESMTP id 8D69F495; Fri, 26 Mar 2004 14:57:49 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh22.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 26 Mar 2004 14:57:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Mar 2004 14:57:48 -0700 Message-ID: Thread-Topic: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Thread-Index: AcQDJhijxKqtbhxpRP24tLt8vUWOKwQVsJJQ To: , Cc: , , X-OriginalArrivalTime: 26 Mar 2004 21:57:49.0545 (UTC) FILETIME=[612DD590:01C4137D] Content-Transfer-Encoding: quoted-printable Subject: [tcpm] RE: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hmm, that's kind of funny. My thoughts are just the opposite: jumbo = frames may be a necessary evil until TOEs become universal. Pat -----Original Message----- From: tsvwg-admin@ietf.org [mailto:tsvwg-admin@ietf.org]On Behalf Of Bursty traffic may be ok for LAN, but is considered evil for WAN. TOE doesn't suffer this problem (since it is stateful), and may be a necessary evil until jumbo frames become universal. Jerry _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Mar 29 11:49:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11996 for ; Mon, 29 Mar 2004 11:49:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7zwB-0005ra-07 for tcpm-archive@odin.ietf.org; Mon, 29 Mar 2004 11:48:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TGmY1k022537 for tcpm-archive@odin.ietf.org; Mon, 29 Mar 2004 11:48:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7zwA-0005rQ-9b for tcpm-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 11:48:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11917 for ; Mon, 29 Mar 2004 11:48:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7zw9-0007Jo-00 for tcpm-web-archive@ietf.org; Mon, 29 Mar 2004 11:48:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7zvH-0007Cw-00 for tcpm-web-archive@ietf.org; Mon, 29 Mar 2004 11:47:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7zuo-00075J-00 for tcpm-web-archive@ietf.org; Mon, 29 Mar 2004 11:47:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7zue-0005kR-Ri; Mon, 29 Mar 2004 11:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B70mX-0002ei-SJ for tcpm@optimus.ietf.org; Fri, 26 Mar 2004 18:30:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25522 for ; Fri, 26 Mar 2004 18:30:29 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B70mU-0004wB-00 for tcpm@ietf.org; Fri, 26 Mar 2004 18:30:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B70lN-0004pF-00 for tcpm@ietf.org; Fri, 26 Mar 2004 18:29:21 -0500 Received: from msgbas1tx.cos.agilent.com ([192.25.240.37] helo=msgbas2x.cos.agilent.com) by ietf-mx with esmtp (Exim 4.12) id 1B70l0-0004mM-00; Fri, 26 Mar 2004 18:28:58 -0500 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id C1DC98E74; Fri, 26 Mar 2004 16:28:53 -0700 (MST) Received: from wcosbh22.cos.agilent.com (wcosbh22.cos.agilent.com [130.29.152.178]) by relcos2.cos.agilent.com (Postfix) with ESMTP id A540D3F8; Fri, 26 Mar 2004 16:28:53 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh22.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 26 Mar 2004 16:28:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] Re: [tcpm] Re: [e2e] Are you interested in TOEs and related issues(Resend) Date: Fri, 26 Mar 2004 16:28:52 -0700 Message-ID: Thread-Topic: [Tsvwg] Re: [tcpm] Re: [e2e] Are you interested in TOEs and related issues(Resend) Thread-Index: AcQH2aHMGKtOTBDMQM23bVTXvzf48ALroy4A To: , Cc: , X-OriginalArrivalTime: 26 Mar 2004 23:28:53.0631 (UTC) FILETIME=[1A0730F0:01C4138A] Content-Transfer-Encoding: quoted-printable Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I'll take the liberty of responding to your rhetorical question. I don't = think the question can be answered outside the context of protocols like = RDMA and iSCSI. A good part of the performance problem for 10 Gig links = is the data copies required. Protocols like iSCSI and RDMA can allow the = NIC to place the data into applications buffers. This is similar to the = function of some Fibre Channel interfaces that allow it higher = performance. This is a large part of the benefit gained from = implementing a TOE. Protocols like RDMA and iSCSI require TCP (or an = alternative transport layer) to be implemented other them which means = you need a TOE.=20 If you aren't doing placement on the NIC, it isn't clear that there is = enough benefit from implementing a TOE. Because we want to do placement, = we need a TOE. Pat -----Original Message----- From: tsvwg-admin@ietf.org [mailto:tsvwg-admin@ietf.org]On Behalf Of Rick Jones Sent: Thursday, March 11, 2004 10:49 AM To: tcpm@ietf.org Cc: tsvwg@ietf.org; end2end-interest@postel.org Subject: Re: [Tsvwg] Re: [tcpm] Re: [e2e] Are you interested in TOEs and related issues(Resend) > Yes, that was one of the first thoughts that came to my mind when I > started looking at this space. Its not just security issues but bugs = and > new features. TCP despite being mature still sees couple of RFC or = tweaks > a year that needs to be rolled out to existing systems. Apparantly the > TOE vendors had thought about that. The firmware running the protocol = code > actually lives on the host and is delivered via exisiting delivery > mechanism (packages in Solaris which can be upgraded). When machine = boots > and interface is configured, the protocol firmware is sucked in. So > delivering fix or new revs in pretty similar to exisiting mechanisms. > Also, the source code is still 'C' based so people like me can still > work with it (just need to use some magic in the end to create the > firmware instead of complier). Some vendors we talked to have promised > that they can pretty much suck in the same code that runs on the host > into the card (as long as we can clean some complier specific = directives > etc). Although I must admit that this aspect (common source files) of = TOE > has not been investigated by us at all so far. That seems like a path out when the TOE is based on an embedded CPU, but = doesn't seem like it would work for those TOEs that are ASICs. And a mostly rhetorical question - strictly in the context of TCP comms = and not RDMA and the like - if one can code tightly enough for an embedded CPU a = TCP/IP stack including comms with the host across the I/O bus with enough = performance to be reasonable for a given link, can't one presumeably make the host's = TCP/IP stack similarly efficient? If nothing else that seems to be alluded to = by the last sentence in the quoted paragraph. rick jones --=20 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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 30 12:28:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01431 for ; Tue, 30 Mar 2004 12:28:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8N2J-0004FB-Uu for tcpm-archive@odin.ietf.org; Tue, 30 Mar 2004 12:28:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UHSRE7016313 for tcpm-archive@odin.ietf.org; Tue, 30 Mar 2004 12:28:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8N2J-0004F2-Nz for tcpm-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 12:28:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01420 for ; Tue, 30 Mar 2004 12:28:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8N2I-0000Zx-00 for tcpm-web-archive@ietf.org; Tue, 30 Mar 2004 12:28:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8N1Q-0000RY-00 for tcpm-web-archive@ietf.org; Tue, 30 Mar 2004 12:27:33 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B8N11-0000JL-00 for tcpm-web-archive@ietf.org; Tue, 30 Mar 2004 12:27:08 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B8N12-0002of-8j for tcpm-web-archive@ietf.org; Tue, 30 Mar 2004 12:27:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8N0v-00044o-1v; Tue, 30 Mar 2004 12:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8N0L-00042N-T7 for tcpm@optimus.ietf.org; Tue, 30 Mar 2004 12:26:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01351 for ; Tue, 30 Mar 2004 12:26:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8N0J-0000GH-00 for tcpm@ietf.org; Tue, 30 Mar 2004 12:26:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8MzP-00004B-00 for tcpm@ietf.org; Tue, 30 Mar 2004 12:25:28 -0500 Received: from ms1.city.ac.uk ([138.40.12.21]) by ietf-mx with esmtp (Exim 4.12) id 1B8MyZ-0007fj-00 for tcpm@ietf.org; Tue, 30 Mar 2004 12:24:35 -0500 Received: from mailswitch.city.ac.uk ([138.40.12.12] helo=mailswitch) by ms1.city.ac.uk with smtp (Exim 4.20) id 1B8MyB-0001qN-0R for tcpm@ietf.org; Tue, 30 Mar 2004 18:24:11 +0100 Received: from frc-703c.city.ac.uk ([138.40.89.29] helo=WirelessLab2) by mailswitch with esmtp (Exim 3.16 #5) id 1B8My8-00048w-00 for tcpm@ietf.org; Tue, 30 Mar 2004 18:24:08 +0100 From: "Ehsan Hamadani" To: Date: Tue, 30 Mar 2004 18:22:25 +0100 Message-ID: <000501c4167b$95030c90$1d59288a@WirelessLab2> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C41683.F6C77490" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-MailScanner-Information: Please contact Computing Services for more information X-City-MailScanner: Found to be clean X-City-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=0.6, required 5, HTML_70_80 0.51, HTML_MESSAGE 0.10) Subject: [tcpm] FW: Last Byte Send calculation Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_70_80,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C41683.F6C77490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, I have the following simple question; however I could not find the answer in RFC's congestion control document. In the congestion control algorithm, when TCP invokes fast retransmit and sends the lost segment, which value does the TCP use for "last segment send" in calculating "effective window"? For instance, the segment that has been sent before fast retransmits was 20. Now because of receipt of 3 duplicate ACKs for segment 10, sender retransmit segment 10 and set CWND to 1. In this case, when another duplicate ACK for segment 10 arrives, and TCP wants to calculate EffectiveWindow = CWND - (LastByteSent - LastByteReceived) what is the value for LastByteSent?? Is it 10 or 20?? Thanks for your consideration. Regards, Ehsan ------=_NextPart_000_0006_01C41683.F6C77490 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I have the following simple question; however I could = not find the answer in RFC’s congestion control = document.

 

In the congestion control algorithm, when TCP invokes = fast retransmit and sends the lost segment, which value does the TCP use for “last segment send” in calculating “effective = window”?

For instance, the segment that has been sent before = fast retransmits was 20. Now because of receipt of 3 duplicate ACKs for = segment 10, sender retransmit segment 10 and set CWND to = 1.

In this case, when another duplicate = ACK for segment 10 arrives, and TCP wants to calculate EffectiveWindow =3D = CWND – (LastByteSent – LastByteReceived) what is the value for = LastByteSent??

Is it 10 or 20??

 

Thanks for your = consideration.

 

Regards,

 

Ehsan

 

------=_NextPart_000_0006_01C41683.F6C77490-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 30 12:46:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02405 for ; Tue, 30 Mar 2004 12:46:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8NJm-0005yJ-BG for tcpm-archive@odin.ietf.org; Tue, 30 Mar 2004 12:46:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UHkU62022951 for tcpm-archive@odin.ietf.org; Tue, 30 Mar 2004 12:46:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8NJm-0005y6-7F for tcpm-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 12:46:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02394 for ; Tue, 30 Mar 2004 12:46:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8NJk-0003il-00 for tcpm-web-archive@ietf.org; Tue, 30 Mar 2004 12:46:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8NIq-0003al-00 for tcpm-web-archive@ietf.org; Tue, 30 Mar 2004 12:45:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8NIL-0003Sj-00 for tcpm-web-archive@ietf.org; Tue, 30 Mar 2004 12:45:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8NIK-0005qq-Rl; Tue, 30 Mar 2004 12:45:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8NHl-0005pV-8s for tcpm@optimus.ietf.org; Tue, 30 Mar 2004 12:44:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02317 for ; Tue, 30 Mar 2004 12:44:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8NHj-0003QZ-00 for tcpm@ietf.org; Tue, 30 Mar 2004 12:44:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8NGl-0003Gt-00 for tcpm@ietf.org; Tue, 30 Mar 2004 12:43:23 -0500 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 1B8NFl-000328-00 for tcpm@ietf.org; Tue, 30 Mar 2004 12:42:21 -0500 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 8671E32AF2; Tue, 30 Mar 2004 12:42:21 -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 CF5C632AEB; Tue, 30 Mar 2004 12:42:20 -0500 (EST) Date: Tue, 30 Mar 2004 12:42:20 -0500 (EST) From: Janardhan Iyengar X-X-Sender: iyengar@stimpy.eecis.udel.edu To: Ehsan Hamadani Cc: tcpm@ietf.org Subject: Re: [tcpm] FW: Last Byte Send calculation In-Reply-To: <000501c4167b$95030c90$1d59288a@WirelessLab2> Message-ID: References: <000501c4167b$95030c90$1d59288a@WirelessLab2> 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: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Ehsan, > In the congestion control algorithm, when TCP invokes fast retransmit > and sends the lost segment, which value does the TCP use for "last > segment send" in calculating "effective window"? > For instance, the segment that has been sent before fast retransmits was > 20. Now because of receipt of 3 duplicate ACKs for segment 10, sender > retransmit segment 10 and set CWND to 1. If you are using RFC 2581, the cwnd will be set to flightsize/2 after a fast retransmit, not to 1. > In this case, when another duplicate ACK for segment 10 arrives, and TCP > wants to calculate EffectiveWindow = CWND - (LastByteSent - > LastByteReceived) what is the value for LastByteSent?? > Is it 10 or 20?? LastByteSent should really be HighestByteSent, and LastByteReceived should be HighestByteReceived (assuming no SACKs). That makes the answer 20. regards, jana --------------------------------------------------------------- Visit www.narmada.org, www.indiatogether.org --------------------------------------------------------------- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 30 17:56:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21754 for ; Tue, 30 Mar 2004 17:56:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjd-0006ZK-9u for tcpm-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MT2J7003336 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TF8-0000ri-1B for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07312 for ; Mon, 8 Mar 2004 17:28:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TF5-0000n5-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEF-0000ae-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDC-0000PZ-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDB-0000Ck-HQ; Mon, 08 Mar 2004 17:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayn4e-0005ew-HD for tcpm@optimus.ietf.org; Thu, 04 Mar 2004 02:15:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20711 for ; Thu, 4 Mar 2004 02:15:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayn4b-0006MJ-00 for tcpm@ietf.org; Thu, 04 Mar 2004 02:15:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayn3l-0006CU-00 for tcpm@ietf.org; Thu, 04 Mar 2004 02:14:21 -0500 Received: from mail1.cray.com ([136.162.0.111]) by ietf-mx with esmtp (Exim 4.12) id 1Ayn30-0005sD-00; Thu, 04 Mar 2004 02:13:34 -0500 Received: from relayb.mw.cray.com (relayb.us.cray.com [192.168.252.110]) by mail1.cray.com (8.12.10/8.12.10/gw-1.4) with ESMTP id i247CgFj018587; Thu, 4 Mar 2004 01:12:42 -0600 (CST) Received: from saffron.us.cray.com (saffron.mw.cray.com [172.31.27.14]) by relayb.mw.cray.com (8.12.10/8.12.10/hub-1.3) with ESMTP id i247CeQH023374; Thu, 4 Mar 2004 01:12:40 -0600 (CST) Received: from [127.0.0.1] (troll [192.168.250.5]) by saffron.us.cray.com (8.12.10/8.12.8/badger-1.4) with ESMTP id i247Ccqh253298; Thu, 4 Mar 2004 01:12:38 -0600 (CST) In-Reply-To: <20040302150735.2A2221A9@aland.bbn.com> References: <20040302150735.2A2221A9@aland.bbn.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <510B9F0C-6DAB-11D8-AE57-000A95D7D4C0@cray.com> Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org, Sunay Tripathi From: David Borman Subject: Re: [tcpm] Re: [e2e] Are you interested in TOEs and related issues (Resend) Date: Thu, 4 Mar 2004 16:12:37 +0900 To: Craig Partridge X-Mailer: Apple Mail (2.612) X-Cray-VirusStatus: clean Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Craig, I wouldn't say in general that we found out that TOEs didn't work. I think a more qualified comment of what we found out was that in an environment where the network is the bottle neck, TOEs did not provide any cost effective benefits; and as CPUs got faster, the TOEs just provided costs without benefits. :-) TOE has become a buzz-word that needs to be qualified. Some folks include Checksum Offload and Large Segmentation Offload when talking about TOE. When others talk about TOE, they refer to offloading the whole TCP/IP stack. With 10GigE, we are in the realm where the network is not the bottle neck. Even with GigE, the CPU has to do significant work to keep the card fed, leaving little time for doing any application work. I think there are very few if any CPUs available today that can keep a 10GigE pipe fed, much less handle an inbound 10GigE stream. Features such as Checksum Offload and LSO are features that have low impact on the OS and its TCP/IP stack. Other features such as having a timer to delay and aggregate transmit interrupts also help to reduce the amount of work that the CPU has to do to process the data. For me, the question is what can be done in a 10GigE NIC to allow the host CPU to handle both sending and receiving full speed on that interface? TOE is just one part of that discussion and the danger is that if too much focus is put on TOE, the other aspects of how to improve how the CPU and the NIC communicate will not be properly investigated. -David Borman On Mar 3, 2004, at 12:07 AM, Craig Partridge wrote: > > Well, the interesting thing is we went down this path in the early > 1980s > and found that TOEs didn't work. > > If I try to distill all that we learned in the 1980s into one > question, I > come out with: > > In the 1980s we discovered that communicating with a TOE over a bus > about a TCP connection was as expensive or more expensive than > simply handling the TCP connection in the main processor. What > about > today's TOE designs makes them different? > > Craig > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 30 17:59:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22553 for ; Tue, 30 Mar 2004 17:59:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjb-0006a4-LW for tcpm-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MT0Be003300 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TF6-0000r9-QG for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07309 for ; Mon, 8 Mar 2004 17:28:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TF4-0000ms-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEE-0000aU-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDC-0000PY-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDB-0000CZ-91; Mon, 08 Mar 2004 17:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AymQy-00052Q-IX for tcpm@optimus.ietf.org; Thu, 04 Mar 2004 01:34:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05477 for ; Thu, 4 Mar 2004 01:34:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AymQv-0005yk-00 for tcpm@ietf.org; Thu, 04 Mar 2004 01:34:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AymQB-0005pY-00 for tcpm@ietf.org; Thu, 04 Mar 2004 01:33:28 -0500 Received: from ns1.s2io.com ([216.209.86.101]) by ietf-mx with esmtp (Exim 4.12) id 1AymPa-0005aQ-00; Thu, 04 Mar 2004 01:32:50 -0500 Received: from guinness.s2io.com (gateway.s2io.com [216.209.86.98]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i246W0jF001911; Thu, 4 Mar 2004 01:32:00 -0500 (EST) Received: from lgt40 ([192.168.0.3]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i246VwKK016938; Thu, 4 Mar 2004 01:31:58 -0500 (EST) From: "Leonid Grossman" To: "'Sunay Tripathi'" , Cc: , , Date: Wed, 3 Mar 2004 22:29:22 -0800 Message-ID: <000001c401b2$094af3d0$0300a8c0@S2IOtech.com> 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: <200403040455.i244twSG699301@jurassic.eng.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: -101 X-Spam-Outlook-Score: () X-Spam-Features: IN_REP_TO,QUOTED_EMAIL_TEXT,USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.34 Content-Transfer-Encoding: 7bit Subject: [tcpm] RE: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > -----Original Message----- > From: tsvwg-admin@ietf.org [mailto:tsvwg-admin@ietf.org] On > Behalf Of Sunay Tripathi > Sent: Wednesday, March 03, 2004 8:56 PM > To: craig@bbn.com > Cc: tcpm@ietf.org; tsvwg@ietf.org; end2end-interest@postel.org > Subject: [Tsvwg] Re: [e2e] Are you interested in TOEs and > related issues > > > Craig, > > > Well, the interesting thing is we went down this path in the early > > 1980s and found that TOEs didn't work. > > > > If I try to distill all that we learned in the 1980s into one > > question, I come out with: > > > > In the 1980s we discovered that communicating with a > TOE over a bus > > about a TCP connection was as expensive or more expensive than > > simply handling the TCP connection in the main > processor. What about > > today's TOE designs makes them different? > > I don't have too much history (1980s predates my career) but > there were some attempts in mid 90s to do the same and > compared to that, the following reasons seem to be the driving force: > > 1) Extra processor(s) buried in the TOE for networking > processing which is > hidden from the kernel and leaves the host CPU to do more > application > related work. Saves the cost of licences for application which take > number of CPU into account (oracle is one such application cited). > 2) On low end (1-2 CPU) x86 based machines, cost of adding a processor > is much higher than adding a TOE (I personally haven't > verified this). > 3) For the up and coming 10Gb NICs, TOE will help saturate > the link. Some > vendors assert that TOE will be required to support 10Gb NICs. TOE will bring CPU utilization down of course, but 10GbE NIC will saturate the link with or without a TOE - much like GbE NICs do it now. > 4) Performance reasons. Just the LSO aspect of TOE (sending > large chunks of > data and letting the TOE split it up in mss size pieces) and ack > coalescing gives a pretty good boost (our own prototypes > indicates that > this is true). Just curious - in your testing, how much CPU is freed up by the ack coalescing? >The gains are by optimizing data movement and not by > offloading protocol processing. LSO is a 'stateless' offload (much like checksum offload) so one doesn't need a TOE to support it; most modern NICs (including our 10GbE Adapter) do LSO. Also, for normal frames LSO has quite dramatic effect at 10GbE rates, but for Jumbo frames performance gain diminishes to ~7%. > 5) TOE is necessary for RDMA, iSCSI etc. for layering > reasons. I am not > involved with RDMA so someone who is an expert can > probably comment on > this part. > 6) TOE based NIC are already making pretty good headway in > embedded space. > The technology is already maturing so why not use it in > broader market. > > Note that the above claims are in no particular order of > importance and made my TOE vendors in general. Of these, I > personally do agree with 1 and 4 but that iteself doesn't > mean that TOE will make it in general purpose networking. > > It would be interesting to see if you and others in the list > agree or disagree with these claims. > > Thanks, > Sunay > > -- > > Sunay Tripathi > Senior Staff Engineer, > Solaris Kernel Networking, > Sun MicroSystems Inc. > > email: sunay@eng.sun.com Phone: 650-786-6007 (W) > > > > Regards, Leonid Grossman www.s2io.com > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 30 18:03:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23747 for ; Tue, 30 Mar 2004 18:03:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rja-0006ZK-59 for tcpm-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BJarCH006917 for tcpm-archive@odin.ietf.org; Thu, 11 Mar 2004 14:36:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Vz9-0001nP-8K for tcpm-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 14:36:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18267 for ; Thu, 11 Mar 2004 14:36:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Vz6-0005NB-00 for tcpm-web-archive@ietf.org; Thu, 11 Mar 2004 14:36:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1VyD-0005EP-00 for tcpm-web-archive@ietf.org; Thu, 11 Mar 2004 14:35:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1VxP-00056S-00 for tcpm-web-archive@ietf.org; Thu, 11 Mar 2004 14:35:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1VxP-0001cJ-4t; Thu, 11 Mar 2004 14:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Vwo-0001Sa-Ob for tcpm@optimus.ietf.org; Thu, 11 Mar 2004 14:34:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18021 for ; Thu, 11 Mar 2004 14:34:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Vwl-0004xC-00 for tcpm@ietf.org; Thu, 11 Mar 2004 14:34:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Vvi-0004mF-00 for tcpm@ietf.org; Thu, 11 Mar 2004 14:33:19 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B1Vup-0004bV-00; Thu, 11 Mar 2004 14:32:23 -0500 Received: from jurassic.eng.sun.com ([129.146.83.36]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2BJW0ex005245; Thu, 11 Mar 2004 12:32:00 -0700 (MST) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i2BJW079475953; Thu, 11 Mar 2004 11:32:00 -0800 (PST) Received: (from sunay@localhost) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id i2BJVxhD475951; Thu, 11 Mar 2004 11:31:59 -0800 (PST) From: Sunay Tripathi Message-Id: <200403111931.i2BJVxhD475951@jurassic.eng.sun.com> Subject: Re: [Tsvwg] Re: [tcpm] Re: [e2e] Are you interested in TOEs and related issues(Resend) In-Reply-To: <4050B4A6.D346736C@cup.hp.com> from Rick Jones at "Mar 11, 2004 10:49:10 am" To: Rick Jones Date: Thu, 11 Mar 2004 11:31:59 -0800 (PST) CC: tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rick, > > Yes, that was one of the first thoughts that came to my mind when I > > started looking at this space. Its not just security issues but bugs and > > new features. TCP despite being mature still sees couple of RFC or tweaks > > a year that needs to be rolled out to existing systems. Apparantly the > > TOE vendors had thought about that. The firmware running the protocol code > > actually lives on the host and is delivered via exisiting delivery > > mechanism (packages in Solaris which can be upgraded). When machine boots > > and interface is configured, the protocol firmware is sucked in. So > > delivering fix or new revs in pretty similar to exisiting mechanisms. > > Also, the source code is still 'C' based so people like me can still > > work with it (just need to use some magic in the end to create the > > firmware instead of complier). Some vendors we talked to have promised > > that they can pretty much suck in the same code that runs on the host > > into the card (as long as we can clean some complier specific directives > > etc). Although I must admit that this aspect (common source files) of TOE > > has not been investigated by us at all so far. > > That seems like a path out when the TOE is based on an embedded CPU, but doesn't > seem like it would work for those TOEs that are ASICs. The TOEs I am talking about have 1 or more embedded ARM processor (seems to be the more common model these days). > And a mostly rhetorical question - strictly in the context of TCP comms and not > RDMA and the like - if one can code tightly enough for an embedded CPU a TCP/IP > stack including comms with the host across the I/O bus with enough performance > to be reasonable for a given link, can't one presumeably make the host's TCP/IP > stack similarly efficient? If nothing else that seems to be alluded to by the > last sentence in the quoted paragraph. I think Craig did ask this question before and the benefit is not so much from the protocol processing saving but from the data movement. Below is a portion of my earlier reply to Craig's email. " 1) Extra processor(s) buried in the TOE for networking processing which is hidden from the kernel and leaves the host CPU to do more application related work. Saves the cost of licences for application which take number of CPU into account (oracle is one such application cited). 2) On low end (1-2 CPU) x86 based machines, cost of adding a processor is much higher than adding a TOE (I personally haven't verified this). 3) For the up and coming 10Gb NICs, TOE will help saturate the link. Some vendors assert that TOE will be required to support 10Gb NICs. 4) Performance reasons. Just the LSO aspect of TOE (sending large chunks of data and letting the TOE split it up in mss size pieces) and ack coalescing gives a pretty good boost (our own prototypes indicates that this is true). The gains are by optimizing data movement and not by offloading protocol processing. 5) TOE is necessary for RDMA, iSCSI etc. for layering reasons. I am not involved with RDMA so someone who is an expert can probably comment on this part. 6) TOE based NIC are already making pretty good headway in embedded space. The technology is already maturing so why not use it in broader market. " Cheers, Sunay > > 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... > -- Sunay Tripathi Senior Staff Engineer, Solaris Kernel Networking, Sun MicroSystems Inc. email: sunay@eng.sun.com Phone: 650-786-6007 (W) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 30 18:04:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24146 for ; Tue, 30 Mar 2004 18:04:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjY-0006YH-UK for tcpm-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MT9Q2003466 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFF-0000to-Gh for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07341 for ; Mon, 8 Mar 2004 17:29:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TFD-0000o4-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:29:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEO-0000bw-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDG-0000Q5-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDI-0000Na-8p; Mon, 08 Mar 2004 17:27:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RDH-0006nu-4k for tcpm@optimus.ietf.org; Mon, 08 Mar 2004 15:18:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26395 for ; Mon, 8 Mar 2004 15:18:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0RDF-0005Md-00 for tcpm@ietf.org; Mon, 08 Mar 2004 15:18:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0RCH-0005B0-00 for tcpm@ietf.org; Mon, 08 Mar 2004 15:17:57 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx with esmtp (Exim 4.12) id 1B0RBL-00050N-00; Mon, 08 Mar 2004 15:17:00 -0500 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel12.hp.com (Postfix) with ESMTP id 591E11C007FD; Mon, 8 Mar 2004 12:16:56 -0800 (PST) Received: from cup.hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_24419+JAGae58098)/8.9.3 SMKit7.04) with ESMTP id MAA04226; Mon, 8 Mar 2004 12:16:56 -0800 (PST) Message-ID: <404CD4B8.E4A5A429@cup.hp.com> Date: Mon, 08 Mar 2004 12:16:56 -0800 From: Rick Jones 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: Barney Wolff Cc: tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org Subject: Re: [Tsvwg] Re: [tcpm] Re: [e2e] Are you interested in TOEs and related issues (Resend) References: <20040302150735.2A2221A9@aland.bbn.com> <510B9F0C-6DAB-11D8-AE57-000A95D7D4C0@cray.com> <404CBAEF.B49A643D@cup.hp.com> <20040308195206.GB44520@pit.databus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Barney Wolff wrote: > > On Mon, Mar 08, 2004 at 10:26:55AM -0800, Rick Jones wrote: > > > > Pinky TOE => Checksum Offload (CKO) > > Middle TOE => CKO + LSO (aka TSO or large send) > > Big TOE => Full TCP Offload > > You forgot these: > > Stubbed TOE => disabling TOE so tcpdump/snoop works > Broken TOE => bug in firmware, difficult to diagnose Yes, well... if we are going for full humour (actually, I wasn't just trying to be funny but still... :) TOE jam => the kruft of a TOE solution Hammer TOE => one where the offload is to an embedded CPU TOE nail => when offloaded security/hardening is included Athlete's Foot => when a TOE becomes security compromised Tip TOE => when it operates in a stealth mode Foot => what you have when more than one TOE are bonded together. TOE shoes => the shims interfacing a TOE with the rest of the system/stack. I suppose that had development of the Digital 2114X chips continued, one might have spoken of a Tip TOE through the Tulips. ad nauseum :) 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... _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 30 18:05:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24424 for ; Tue, 30 Mar 2004 18:05:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjW-0006ZK-8w for tcpm-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MT4GD003386 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFA-0000sX-Jz for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07323 for ; Mon, 8 Mar 2004 17:29:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TF8-0000nS-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:29:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEI-0000b5-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDC-0000Pd-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDC-0000DH-Bf; Mon, 08 Mar 2004 17:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayx1s-0004lj-2h for tcpm@optimus.ietf.org; Thu, 04 Mar 2004 12:53:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04190 for ; Thu, 4 Mar 2004 12:52:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayx1q-0005up-00 for tcpm@ietf.org; Thu, 04 Mar 2004 12:53:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayx16-0005i0-00 for tcpm@ietf.org; Thu, 04 Mar 2004 12:52:17 -0500 Received: from duke.cs.duke.edu ([152.3.140.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayx0P-0005U6-00; Thu, 04 Mar 2004 12:51:33 -0500 Received: from cs.duke.edu (m201-8.dsl.tsoft.com [198.144.201.8]) (authenticated bits=0) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i24HpEF6000163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Mar 2004 12:51:15 -0500 (EST) Message-ID: <40476C7D.8070000@cs.duke.edu> Date: Thu, 04 Mar 2004 09:50:53 -0800 From: Jeff Chase User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sunay Tripathi CC: craig@bbn.com, tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org References: <200403040455.i244twSG699301@jurassic.eng.sun.com> In-Reply-To: <200403040455.i244twSG699301@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [tcpm] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The argument for offload often takes the premise that host CPU is a bottleneck at high network speeds, which is often true. If we can take that as given, then it is easy to capture the effects of transport offload on throughput using a back-of-napkin analysis. One issue is the ratio of host speed to NIC speed for protocol processing. The benefit from offload is bounded by the inverse of that ratio. In the 1980s, the offload NICs took longer than the host to process the protocol, and the wire was fast enough to saturate either of them. In that case, and only in that case, offload may actually reduce throughput rather than increase it. Today, technology improvements and the role of offload in copy reduction (e.g., RDMA) help to offset this concern. Jeff Mogul had a nice paper in the last HotOS called 'TCP offload is a dumb idea whose time has come' dealing with this point. One can also draw some interesting conclusions about the maximum benefit of offload as a function of the ratio of host speed to wire speed, and of the compute/communicate ratio of the application. Crudely, the maximum speedup from offload is bounded by the inverse of both ratios. Much of the argument about whether offload makes sense boils down to disagreement about how trends are affecting these various ratios, or confusion about how these ratios affect potential speedup. My student Piyush Shivam and I wrote up a 6-page paper with a simple analysis for the NICELI workshop at SIGCOMM last year, called "On the Elusive Benefits of Protocol Offload". It is just Amdahl's Law and some high-school math. If you are interested, you can find it at: http://issg.cs.duke.edu/publications/niceli03.pdf Regards, Jeff http://www.cs.duke.edu/~chase Craig wrote: >>Well, the interesting thing is we went down this path in the early 1980s >>and found that TOEs didn't work. >> >>If I try to distill all that we learned in the 1980s into one question, I >>come out with: >> >> In the 1980s we discovered that communicating with a TOE over a bus >> about a TCP connection was as expensive or more expensive than >> simply handling the TCP connection in the main processor. What about >> today's TOE designs makes them different? > >... _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 30 18:06:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24717 for ; Tue, 30 Mar 2004 18:06:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjX-0006YH-7v for tcpm-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MT4vG003371 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TF9-0000sI-UG for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07320 for ; Mon, 8 Mar 2004 17:28:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TF7-0000nN-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:29:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEH-0000ax-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDC-0000Pc-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDD-0000Fw-MM; Mon, 08 Mar 2004 17:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzAAA-0006tw-EF for tcpm@optimus.ietf.org; Fri, 05 Mar 2004 02:54:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24786 for ; Fri, 5 Mar 2004 02:54:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzAA6-0006jJ-00 for tcpm@ietf.org; Fri, 05 Mar 2004 02:54:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzA97-0006Y3-00 for tcpm@ietf.org; Fri, 05 Mar 2004 02:53:26 -0500 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx with esmtp (Exim 4.12) id 1AzA8P-0006Mq-00; Fri, 05 Mar 2004 02:52:41 -0500 Received: from SNV-XCHMAIL.xch.corp.yahoo.com (snv-xch1.xch.corp.yahoo.com [216.145.51.233]) by mrout2.yahoo.com (8.12.10/8.12.10/y.out) with ESMTP id i257qXwx085723; Thu, 4 Mar 2004 23:52:33 -0800 (PST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 4 Mar 2004 23:53:34 -0800 Message-ID: <7DE0952A73317A42935DEE4890D89765630F62@SNV-XCHMAIL.xch.corp.yahoo.com> Thread-Topic: [e2e] Re: Are you interested in TOEs and related issues Thread-Index: AcQCfpJdLmA/FiGjSu+58TYNiQGgbwAB004A From: "Michael Christian" To: "stanislav shalunov" , "Sunay Tripathi" Cc: , , Content-Transfer-Encoding: quoted-printable Subject: [tcpm] RE: [e2e] Re: Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=CASHCASHCASH autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >One would hope TCP design would not be guided by Oracle licensing quirks. >> 2) On low end (1-2 CPU) x86 based machines, cost of adding a processor >> is much higher than adding a TOE (I personally haven't verified this). >It's not obvious why this should necessarily be the case, given that >it is likely that there will continue to be quite a bit more >general-purpose CPUs made than TCP offload engines. Well, current pricing, with a *huge* negotiated discount, when going from a 2-proc to 4-proc box is on the order of $20+ grand. Yes, you do need to include the hardware, the OS (you need Linux AS vs ES which is substantially more $$$), and potentially the Oracle licenses (which I haven't included in the number). Or, I could buy a $400 TOE.=20 Yeah, CPU's are cheap in the 1-2 range, but when you are TOEing the line between a 2-proc and a 4-proc, the difference is huge. -F _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 30 18:10:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25748 for ; Tue, 30 Mar 2004 18:10:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjW-0006WI-FM for tcpm-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MT07q003285 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TF6-0000qs-20 for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07306 for ; Mon, 8 Mar 2004 17:28:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TF3-0000mn-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEE-0000aL-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDC-0000PX-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDB-0000D0-UW; Mon, 08 Mar 2004 17:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyuXq-0002cH-DI for tcpm@optimus.ietf.org; Thu, 04 Mar 2004 10:13:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24990 for ; Thu, 4 Mar 2004 10:13:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyuXo-0003fo-00 for tcpm@ietf.org; Thu, 04 Mar 2004 10:13:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyuXH-0003To-00 for tcpm@ietf.org; Thu, 04 Mar 2004 10:13:20 -0500 Received: from xorpc.icir.org ([192.150.187.68]) by ietf-mx with esmtp (Exim 4.12) id 1AyuWJ-0003Ic-00; Thu, 04 Mar 2004 10:12:19 -0500 Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i24FCG9Q010021; Thu, 4 Mar 2004 07:12:16 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i24FCGwG010020; Thu, 4 Mar 2004 07:12:16 -0800 (PST) (envelope-from rizzo) Date: Thu, 4 Mar 2004 07:12:16 -0800 From: Luigi Rizzo To: "H.K. Jerry Chu" Cc: leonid.grossman@s2io.com, tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org Message-ID: <20040304071216.A9347@xorpc.icir.org> References: <200403041412.i24EBrWh892234@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200403041412.i24EBrWh892234@jurassic.eng.sun.com>; from Jerry.Chu@eng.sun.com on Thu, Mar 04, 2004 at 11:11:36PM -0800 Subject: [tcpm] Re: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Thu, Mar 04, 2004 at 11:11:36PM -0800, H.K. Jerry Chu wrote: ... > Bursty traffic may be ok for LAN, but is considered evil for WAN. > TOE doesn't suffer this problem (since it is stateful), and may be > a necessary evil until jumbo frames become universal. actually the interesting observation that this discussion raises is that the frame size/link MTU should be picked large enough to make the end-to-end pps rate bounded (but not too low) for well behaved flows. In 1980 the ethernet MTU allowed some 800pps -- going much higher makes little sense anyways, because even if the end nodes can cope with higher rates, the control loops cannot not react fast enough (you have to factor in propagation delays too). On the negative side, however, is that that very large MTUs require a lot of buffering to be preallocated on the receive side, and possibly even at the routers (at least, those without hw-assisted forwarding planes). I don't have a good answer but going much higher than 16Kbytes MTUs seems unlikely... and at 10Gig this is still close to 100kpps. cheers luigi _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 30 18:11:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26031 for ; Tue, 30 Mar 2004 18:11:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjV-0006a4-4z for tcpm-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MT6FP003407 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFC-0000ss-1b for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07329 for ; Mon, 8 Mar 2004 17:29:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TF9-0000nc-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:29:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEK-0000bM-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDD-0000Po-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDF-0000IZ-8Q; Mon, 08 Mar 2004 17:27:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzP5m-0008Ht-0f for tcpm@optimus.ietf.org; Fri, 05 Mar 2004 18:50:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06498 for ; Fri, 5 Mar 2004 18:50:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzP5i-00024K-00 for tcpm@ietf.org; Fri, 05 Mar 2004 18:50:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzP4l-0001t6-00 for tcpm@ietf.org; Fri, 05 Mar 2004 18:49:55 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 1AzP3o-0001eA-00; Fri, 05 Mar 2004 18:48:56 -0500 Received: from jurassic.eng.sun.com ([129.146.85.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i25NmFgP000774; Fri, 5 Mar 2004 16:48:15 -0700 (MST) Received: from unknown (vpn-129-147-152-95.Central.Sun.COM [129.147.152.95]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with SMTP id i25NmQdW692336; Fri, 5 Mar 2004 15:48:41 -0800 (PST) Message-Id: <200403052348.i25NmQdW692336@jurassic.eng.sun.com> Date: Sat, 6 Mar 2004 08:48:14 -0800 (PST) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" To: rizzo@icir.org, zec@tel.fer.hr Cc: leonid.grossman@s2io.com, tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: EPDuMULXVuAooWuZlAikNw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 i86pc i386 Subject: [tcpm] Re: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,DATE_IN_FUTURE_12_24 autolearn=no version=2.60 ... >> It's mainly the TCP receive window, not the PMTU that dictates how >> much buffering will be needed. Routers that do cut-through need not >> buffer the whole pkt. More significant is the drop of the DRAM price >> and increase of the DRAM size making memory a non-issue in many cases >> today. > > >If the DRAM price alone were the only factor preventing vendors from >implementing unlimited packet queues, we would already have seen tons >of such devices on the market over the past 10 years or so. Excessive >queuing delays on routers are bad, especially for high-speed traffic >managed by TCP-like congestion control schemes. The queue lengths on >routers have always been and will always present a tradeoff between a >smallest usable window for handling traffic bursts, and the desire of >keeping the queueing delays as low as possible on the other hand. Assuming pkt switching speed has scaled up too, I don't see why today's much faster routers with a larger max queue length will cause the average queuing delay to be any longer than routers 10 years ago. A perhaps oversimplified comparison can be made between a conforming traffic using 9K jumbo frames vs a non-conforming, traffic burst of 13 back-to-back regular Ethernet frames. They both require the same amount of memory bandwidth in the forwarding path (2*9K ~= 13*1500). If all the forwarding optimization in today's routers has made the switching speed of 13 consecutive Ethernet "cells" from the same flow similar to 2 back-to-back jumbo frames, why would the former be any more evil than the latter? > > >> >> Over the past decade many components involved in providing high-speed >> networking have scaled up an order of magnitude. This including link >> bandwidth, CPU speed, I/O bus, memory size..., but not the Ethernet >> MTU and certain TCP parameters (such as the every-other-pkt acking >> policy). This is really hurting the throughput performance of the >> hosts. IMHO the amount of burstiness by TCP over WAN should be >> allowed to scale up an order of magnitude too. If stretch ACKs are >> fully adopted into TCP algorithm (see rfc2525 for a number of issues >> with stretch acks), one can use LSO on the transmit side, and >> per-flow pkt coalescing on the receive side to provide effectively a >> simple, stateless AAL5 layer for the Ethernet "cells" without >> requiring jumbo frames or complex TOE engine. >> >> BTW, I asked a few transport folks in Minneapolis IETF about how >> "evil" is traffic burst in today's enviroment, but did not get any >> concrete answer. Perhaps this topic should be discussed in tsvwg or >> tcpm. > > >Because queues in todays routers have finite maximum lengths, and this >model is unlikely to change in the forseeable future, excessive traffic >bursts will be more likely subject to drop-tail policing than other >kinds of more smoothly shaped traffic. More than that, the bursty >traffic will not only have less chance of reaching its target with all >fragments in place, but it will also most probably do much harm to Note that these are not IP fragments. Dropping one of them from a burst is no different from dropping one from any other random flow. Also don't forget the end2end path covers two endpoints on the host side so we must consider host side requirement too. This looks like a tug of war between the host side favoring large burst vs the network side favoring small burst. Perhaps TOE can be a good bridge between the two. Rgds, Jerry Also >other innocent and otherwise well-behaving flows as well. > >Marko > > >> >> Jerry >> >> Sr. Staff Engineer >> Solaris Networking & Security Technology >> Sun Microsystems, Inc. >> >> >I don't have a good answer but going much higher than 16Kbytes MTUs >> >seems unlikely... and at 10Gig this is still close to 100kpps. >> > >> > cheers >> > luigi > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 30 18:16:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27472 for ; Tue, 30 Mar 2004 18:16:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjS-0006a4-Q3 for tcpm-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MTAiT003482 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFG-0000u5-FA for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07344 for ; Mon, 8 Mar 2004 17:29:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TFD-0000oA-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:29:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEO-0000c4-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDH-0000Ps-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDF-0000JJ-Oa; Mon, 08 Mar 2004 17:27:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzYz2-0000ko-Pm for tcpm@optimus.ietf.org; Sat, 06 Mar 2004 05:24:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11644 for ; Sat, 6 Mar 2004 05:24:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzYyz-0006V3-00 for tcpm@ietf.org; Sat, 06 Mar 2004 05:24:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzYxz-0006Ix-00 for tcpm@ietf.org; Sat, 06 Mar 2004 05:23:35 -0500 Received: from zg07-057.dialin.iskon.hr ([213.191.150.58] helo=mail.tel.fer.hr) by ietf-mx with esmtp (Exim 4.12) id 1AzYx4-00068M-00; Sat, 06 Mar 2004 05:22:39 -0500 Received: from marko-tp.katoda.net (marko@dhcp11.katoda.net [192.168.200.111]) by mail.tel.fer.hr (8.12.6/8.12.6) with ESMTP id i26AMLuP004657; Sat, 6 Mar 2004 11:22:27 +0100 (CET) (envelope-from zec@tel.fer.hr) From: Marko Zec To: "H.K. Jerry Chu" Date: Sat, 6 Mar 2004 11:21:37 +0100 User-Agent: KMail/1.5.4 Cc: tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org References: <200403052348.i25NmQdW692336@jurassic.eng.sun.com> In-Reply-To: <200403052348.i25NmQdW692336@jurassic.eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200403061121.37953.zec@tel.fer.hr> Content-Transfer-Encoding: 7bit Subject: [tcpm] Re: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Saturday 06 March 2004 17:48, H.K. Jerry Chu wrote: > ... > > > >> It's mainly the TCP receive window, not the PMTU that dictates how > >> much buffering will be needed. Routers that do cut-through need > >> not buffer the whole pkt. More significant is the drop of the DRAM > >> price and increase of the DRAM size making memory a non-issue in > >> many cases today. > > > >If the DRAM price alone were the only factor preventing vendors from > >implementing unlimited packet queues, we would already have seen > > tons of such devices on the market over the past 10 years or so. > > Excessive queuing delays on routers are bad, especially for > > high-speed traffic managed by TCP-like congestion control schemes. > > The queue lengths on routers have always been and will always > > present a tradeoff between a smallest usable window for handling > > traffic bursts, and the desire of keeping the queueing delays as > > low as possible on the other hand. > > Assuming pkt switching speed has scaled up too, I don't see why > today's much faster routers with a larger max queue length will cause > the average queuing delay to be any longer than routers 10 years ago. Congestions and associated queuing delays typically arise due to finite line speeds at outgoing network interfaces, which are sometimes offered more traffic than they can transmit, so the remaining packets have to be either queued or discarded. This phenomenon is well known and is largely independent of the switching fabric performance. So, when such congestions do occur, the max. queuing delay will be approximately equal to the max. buffer length (in bits) divided by the line card speed. Note that with today's faster line speeds we cannot afford to have the similar level of queuing delays as on routers 10 years ago - those delays have now to be reduced (preferably) proportionally to the increase in line rates. And that can't be enforced with unlimited buffer lengths. > > A perhaps oversimplified comparison can be made between a conforming > traffic using 9K jumbo frames vs a non-conforming, traffic burst of > 13 back-to-back regular Ethernet frames. They both require the same > amount of memory bandwidth in the forwarding path (2*9K ~= 13*1500). > If all the forwarding optimization in today's routers has made the > switching speed of 13 consecutive Ethernet "cells" from the same flow > similar to 2 back-to-back jumbo frames, why would the former be any > more evil than the latter? The problem is that in today's routers the buffer sizes are typically accounted in packets, not in bytes. So looking at your example, and supposing that the line card buffer is limited to 100 packets, a burst of small frames will instantly consume 13% of available buffer slots, while jumbos will only use 2%. This is of course no problem if the line card can transmit all those frames instantly, but what if it cannot? > > >> BTW, I asked a few transport folks in Minneapolis IETF about how > >> "evil" is traffic burst in today's enviroment, but did not get any > >> concrete answer. Perhaps this topic should be discussed in tsvwg > >> or tcpm. > > > >Because queues in todays routers have finite maximum lengths, and > > this model is unlikely to change in the forseeable future, > > excessive traffic bursts will be more likely subject to drop-tail > > policing than other kinds of more smoothly shaped traffic. More > > than that, the bursty traffic will not only have less chance of > > reaching its target with all fragments in place, but it will also > > most probably do much harm to > > Note that these are not IP fragments. Dropping one of them from a > burst is no different from dropping one from any other random flow. It _is_ different, because with spiky bursts, you won't be occasionaly losing only a packet or two, but you can expect to loose the entire (or most of the) burst at once. Marko _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 30 18:20:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28744 for ; Tue, 30 Mar 2004 18:20:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006Zv-UM for tcpm-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MT8SJ003450 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFE-0000tZ-Qo for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07338 for ; Mon, 8 Mar 2004 17:29:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TFC-0000nz-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:29:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEN-0000bn-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDF-0000Q1-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDH-0000Ly-A9; Mon, 08 Mar 2004 17:27:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Opp-0001ml-RL for tcpm@optimus.ietf.org; Mon, 08 Mar 2004 12:46:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15997 for ; Mon, 8 Mar 2004 12:46:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Opo-0007ly-00 for tcpm@ietf.org; Mon, 08 Mar 2004 12:46:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Oo2-0007HW-00 for tcpm@ietf.org; Mon, 08 Mar 2004 12:44:47 -0500 Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx with esmtp (Exim 4.12) id 1B0OmE-0006ZF-00; Mon, 08 Mar 2004 12:42:54 -0500 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" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Mar 2004 12:42:21 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA399714022A05B7@mailserv.hatteras.com> Thread-Topic: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Thread-Index: AcQFK4E2JXFBLXfhSuezcemNGmEjmAACHmHA From: "Stephen Suryaputra" To: "Craig Partridge" , "Marko Zec" Cc: , , Content-Transfer-Encoding: quoted-printable Subject: [tcpm] RE: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I think Marko is referring to the situation when there is a congestion. Because of that the queue builds up and if the queue space is in term of the number of packets, then a bunch of small packets can potentially dominate the queue and left little room for large packets eventhough there is a space in the buffer to accomodate the large ones. Unless if there is anything I miss. Cheers, -----Original Message----- From: Craig Partridge [mailto:craig@bbn.com] Sent: Monday, March 08, 2004 11:15 AM To: Marko Zec Cc: tcpm@ietf.org; tsvwg@ietf.org; end2end-interest@postel.org Subject: Re: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues=20 In message <200403081646.48030.zec@tel.fer.hr>, Marko Zec writes: >On Sunday 07 March 2004 23:06, Alexandre L. Grojsgold wrote: >> Small packets get more buffer frames, but are also more rapidly sent. >> The gueue grows fats, but shrinks fast too. It means that a burst of >> small packets will not increase the packet loss, no mather the length >> of the buffer (in packets). > > >This theory is unfortunately wrong, because it ignores the fact that=20 >when congestions do occur, traffic flows consisting of small packets=20 >(regardless whether they are bursty or smooth) will use more buffer=20 >slots then the flows carrying the larger ones, leaving less remaining=20 >buffer slots available for queuing further packets / bursts. I must be missing something here. I think Alexandre's generally right. If the buffers load and empty according to the amount of data in them, then packet size isn't an issue. The only situations in which this isn't true, that I can think off the top of my head, are: * If the router has places where it moves all the bytes in the = packet buffer, regardless of how much data the buffer actually contains. Since this would cause extraordinary internal bandwidth = challenges, I doubt anyone does it for any but the lowest speed routers. * If the router has a deep pipeline and the time at each stage in = the pipeline is set to equal the average packet time rather than the minimum packet time. But most folks carefully design router = pipelines for minimum packet times precisely because of this risk. So clue me in -- what detail of router design am I missing? Craig _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 30 18:25:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00042 for ; Tue, 30 Mar 2004 18:25:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006a4-3F for tcpm-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MT7x0003434 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFD-0000tF-Cc for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07335 for ; Mon, 8 Mar 2004 17:29:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TFB-0000nl-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:29:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEM-0000bd-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDE-0000Pv-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDG-0000Jq-3x; Mon, 08 Mar 2004 17:27:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B02Lc-0005SD-F9 for tcpm@optimus.ietf.org; Sun, 07 Mar 2004 12:45:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27797 for ; Sun, 7 Mar 2004 12:45:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B02La-0001RT-00 for tcpm@ietf.org; Sun, 07 Mar 2004 12:45:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B02KM-0001Dy-00 for tcpm@ietf.org; Sun, 07 Mar 2004 12:44:38 -0500 Received: from adsl-68-22-232-249.dsl.lgtpmi.ameritech.net ([68.22.232.249] helo=aland.bbn.com) by ietf-mx with esmtp (Exim 4.12) id 1B02JL-0000zm-00; Sun, 07 Mar 2004 12:43:36 -0500 Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (Postfix) with ESMTP id 9271A1AA; Sun, 7 Mar 2004 12:43:26 -0500 (EST) To: David Borman Cc: Craig Partridge , tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org, Sunay Tripathi Subject: Re: [tcpm] Re: [e2e] Are you interested in TOEs and related issues (Resend) In-Reply-To: Your message of "Thu, 04 Mar 2004 16:12:37 +0900." <510B9F0C-6DAB-11D8-AE57-000A95D7D4C0@cray.com> Date: Sun, 07 Mar 2004 12:43:26 -0500 From: Craig Partridge Message-Id: <20040307174326.9271A1AA@aland.bbn.com> Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <510B9F0C-6DAB-11D8-AE57-000A95D7D4C0@cray.com>, David Borman writes : >I wouldn't say in general that we found out that TOEs didn't work. I >think a more qualified comment of what we found out was that in an >environment where the network is the bottle neck, TOEs did not provide >any cost effective benefits; and as CPUs got faster, the TOEs just >provided costs without benefits. :-) I take a stronger view, but also agree we need to clarify. >TOE has become a buzz-word that needs to be qualified. Some folks >include Checksum Offload and Large Segmentation Offload when talking >about TOE. When others talk about TOE, they refer to offloading the >whole TCP/IP stack. I understood TOE as being offloading just about the entire stack. I would agree that experience shows that certain functions can be offfloaded very effectively, including checksums and some memory management. I also agree with your thought question -- namely which functions to offload in a high performance environment -- is the right one. Craig _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 30 18:31:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01589 for ; Tue, 30 Mar 2004 18:31:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjI-0006YH-Eu for tcpm-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MTBX9003497 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TFH-0000uK-8G for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07347 for ; Mon, 8 Mar 2004 17:29:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TFE-0000oF-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:29:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEP-0000cC-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDI-0000Q0-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDH-0000LR-1Q; Mon, 08 Mar 2004 17:27:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0NQj-0002WI-2M for tcpm@optimus.ietf.org; Mon, 08 Mar 2004 11:16:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11127 for ; Mon, 8 Mar 2004 11:16:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0NQi-0005nk-00 for tcpm@ietf.org; Mon, 08 Mar 2004 11:16:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0NPn-0005gA-00 for tcpm@ietf.org; Mon, 08 Mar 2004 11:15:39 -0500 Received: from adsl-68-22-232-249.dsl.lgtpmi.ameritech.net ([68.22.232.249] helo=aland.bbn.com) by ietf-mx with esmtp (Exim 4.12) id 1B0NPM-0005YT-00; Mon, 08 Mar 2004 11:15:12 -0500 Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (Postfix) with ESMTP id 5DF5D1A4; Mon, 8 Mar 2004 11:15:05 -0500 (EST) To: Marko Zec Cc: tcpm@ietf.org, tsvwg@ietf.org, end2end-interest@postel.org In-Reply-To: Your message of "Mon, 08 Mar 2004 16:46:47 +0100." <200403081646.48030.zec@tel.fer.hr> Date: Mon, 08 Mar 2004 11:15:05 -0500 From: Craig Partridge Message-Id: <20040308161505.5DF5D1A4@aland.bbn.com> Subject: [tcpm] Re: [Tsvwg] Re: [e2e] Are you interested in TOEs and related issues Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <200403081646.48030.zec@tel.fer.hr>, Marko Zec writes: >On Sunday 07 March 2004 23:06, Alexandre L. Grojsgold wrote: >> Small packets get more buffer frames, but are also more rapidly sent. >> The gueue grows fats, but shrinks fast too. It means that a burst of >> small packets will not increase the packet loss, no mather the length >> of the buffer (in packets). > > >This theory is unfortunately wrong, because it ignores the fact that >when congestions do occur, traffic flows consisting of small packets >(regardless whether they are bursty or smooth) will use more buffer >slots then the flows carrying the larger ones, leaving less remaining >buffer slots available for queuing further packets / bursts. I must be missing something here. I think Alexandre's generally right. If the buffers load and empty according to the amount of data in them, then packet size isn't an issue. The only situations in which this isn't true, that I can think off the top of my head, are: * If the router has places where it moves all the bytes in the packet buffer, regardless of how much data the buffer actually contains. Since this would cause extraordinary internal bandwidth challenges, I doubt anyone does it for any but the lowest speed routers. * If the router has a deep pipeline and the time at each stage in the pipeline is set to equal the average packet time rather than the minimum packet time. But most folks carefully design router pipelines for minimum packet times precisely because of this risk. So clue me in -- what detail of router design am I missing? Craig _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Mar 30 18:36:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02815 for ; Tue, 30 Mar 2004 18:36:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjD-0006Yx-D7 for tcpm-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MT3kr003356 for tcpm-archive@odin.ietf.org; Mon, 8 Mar 2004 17:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TF9-0000s3-7j for tcpm-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:29:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07316 for ; Mon, 8 Mar 2004 17:28:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TF6-0000nI-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:29:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TEG-0000ao-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:28:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0TDC-0000Pa-00 for tcpm-web-archive@ietf.org; Mon, 08 Mar 2004 17:27:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TDD-0000Fb-CK; Mon, 08 Mar 2004 17:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az5UO-0006QC-3o for tcpm@optimus.ietf.org; Thu, 04 Mar 2004 21:55:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29679 for ; Thu, 4 Mar 2004 21:55:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az5UL-0006Sb-00 for tcpm@ietf.org; Thu, 04 Mar 2004 21:55:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az5TL-0006Ie-00 for tcpm@ietf.org; Thu, 04 Mar 2004 21:54:00 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az5SJ-0005zv-00 for tcpm@ietf.org; Thu, 04 Mar 2004 21:52:55 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i252qOO21700; Fri, 5 Mar 2004 04:52:24 +0200 Date: Fri, 5 Mar 2004 04:52:24 +0200 (EET) From: Pekka Savola To: tcpm@ietf.org cc: v6ops@ops.ietf.org, Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [tcpm] TCP, multiple addresses and soft errors when connecting Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi all (mainly the TCP guys!), v6ops WG is in the process of documenting issues which are caused or made more severe by the introduction of IPv6. The document is draft-ietf-v6ops-v6onbydefault-01.txt TCP timeouts when connecting to a destination, but when the destination is unreachable (e.g., because you don't have global IPv6 routes, your first-hop router is not operational, the packets are sent on-link by default, etc.), TCP does not abort the connectivity (and try the next address quicker -- instead of waiting for the TCP timeout). The critical observation to make here is as IPv6 addresses are tried first (I'm simplifying; it's more complex than that), one must cycle through all the addresses, before trying with IPv4. However, IPv4 connections might still work! With TCP timeouts, this takes a lot of time --- and should be made quicker. There is going to be a WG last call on the document soon, aimed for Informational -- just for documenting the issues. The actual fixes (or not) would have to be done elsewhere (e.g., in TCPM WG ;-). Please provide feedback especially on the language used for TCP. (Below.) draft-ietf-v6ops-v6onbydefault-01.txt: ========== 2.3.1 TCP Implications In the case of a socket application attempting a connection via TCP, it would be unreasonable for the application to block even after the system has received notification that the destination address is unreachable via an ICMPv6 Destination Unreachable message. Following are some ways of solving TCP related delays associated with destination unreachability when ICMPv6 errors are generated. 2.3.1.1 TCP Connection Termination One solution is for TCP to abort connections in SYN-SENT or SYN-RECEIVED state when it receives an ICMPv6 Destination Unreachable message. [HOSTREQS] document, in section 4.2.3.9., states that TCP MUST NOT abort connections when receiving ICMP Destination Unreachable messages that indicate "soft errors", where soft errors are defined as ICMP codes 0 (network unreachable), 1 (host unreachable), and 5 (source route failed), and SHOULD abort connections upon receiving the other codes (which are considered "hard errors"). ICMPv6 didn't exist when that document was written, but one could extrapolate the concept of soft errors to ICMPv6 Type 1 codes 0 (no route to destination) and 3 (address unreachable), and hard errors to the other codes. Thus, it could be argued that a TCP implementation that behaves as suggested in this section is in conflict with [HOSTREQS]. When [HOSTREQS] was written, most applications would mostly only try one address when establishing communication with a destination. Not aborting a connection was a sane thing to do if re-trying a single address was a better alternative over quitting the application altogether. With IPv6, and especially on dual stack systems, destinations are often assigned multiple addresses (at least one IPv4 and one IPv6 address), and applications iterate through destination addresses when attempting connections. Since soft errors conditions are those that would entice an application to continue iterating to another address, TCP shouldn't make the distinction between ICMPv6 soft errors and hard errors when in SYN-SENT or SYN-RECEIVED state. It should abort a connection in those states when receiving any ICMPv6 Destination Unreachable message. When in any other state, TCP would behave as described in [HOSTREQS]. Many TCP implementations already behave this way, but others do not. This should be noted as a best current practice in this case. A tangential method of handling the problem in this way would be for applications to somehow notify the TCP layer of their preference in the matter. An application could notify TCP that it should abort a connection upon receipt of particular ICMPv6 errors. Similarly, it could notify TCP that it should not abort a connection. This would allow existing TCP implementations to maintain their status quo at the expense of increased application complexity. 2.3.1.2 Asynchronous Application Notification In section 4.2.4.1, [HOSTREQS] states that there MUST be a mechanism for reporting soft TCP error conditions to the application. Such a mechanism (assuming one is implemented) could be used by applications to cycle through destination addresses. =========== -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm