From owner-pilc@lerc.nasa.gov Fri Dec 1 07:21:44 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23117 for ; Fri, 1 Dec 2000 07:21:43 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA06166 for pilc-outgoing; Fri, 1 Dec 2000 06:33:57 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id GAA06146 for ; Fri, 1 Dec 2000 06:33:55 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA18567; Fri, 1 Dec 2000 06:33:54 -0500 Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.5) id xma018530; Fri, 1 Dec 00 06:33:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25781; Fri, 1 Dec 2000 06:32:58 -0500 (EST) Message-Id: <200012011132.GAA25781@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pilc@grc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pilc-link-design-04.txt Date: Fri, 01 Dec 2000 06:32:58 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF. Title : Advice for Internet Subnetwork Designers Author(s) : P. Karn, A. Falk, J. Touch, M. Montpetit, J. Mahdavi, G. Montenegro, D. Grossman, G. Fairhurst Filename : draft-ietf-pilc-link-design-04.txt Pages : 21 Date : 30-Nov-00 This document provides advice to the designers of digital communication equipment, link layer protocols and packet switched subnetworks (collectively referred to as subnetworks) who wish to support the Internet protocols but who may be unfamiliar with the architecture of the Internet and the implications of their design choices on the performance and efficiency of the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pilc-link-design-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-link-design-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001130115219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-link-design-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-link-design-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130115219.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Fri Dec 1 07:22:39 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23655 for ; Fri, 1 Dec 2000 07:22:38 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA06162 for pilc-outgoing; Fri, 1 Dec 2000 06:33:57 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id GAA06144 for ; Fri, 1 Dec 2000 06:33:54 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA18561; Fri, 1 Dec 2000 06:33:53 -0500 Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.5) id xma018528; Fri, 1 Dec 00 06:33:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25881; Fri, 1 Dec 2000 06:33:08 -0500 (EST) Message-Id: <200012011133.GAA25881@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pilc@grc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pilc-pep-05.txt Date: Fri, 01 Dec 2000 06:33:07 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF. Title : Performance Enhancing Proxies Author(s) : J. Border, M. Kojo, J. Griner, G. Montenegro, Z. Shelby Filename : draft-ietf-pilc-pep-05.txt Pages : 45 Date : 30-Nov-00 This document provides a high level overview of Performance Enhancing Proxies. Different types of Performance Enhancing Proxies are described as well as the mechanisms used to improve performance. In addition, motivations for their development and use are described along with some the consequences of using them, especially in the context of the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-pep-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pilc-pep-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-pep-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001130115239.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-pep-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-pep-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130115239.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Fri Dec 1 07:54:23 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23118 for ; Fri, 1 Dec 2000 07:21:43 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA06165 for pilc-outgoing; Fri, 1 Dec 2000 06:33:57 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id GAA06145 for ; Fri, 1 Dec 2000 06:33:55 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA18564; Fri, 1 Dec 2000 06:33:54 -0500 Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.5) id xma018529; Fri, 1 Dec 00 06:33:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25827; Fri, 1 Dec 2000 06:33:03 -0500 (EST) Message-Id: <200012011133.GAA25827@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pilc@grc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pilc-slow-05.txt Date: Fri, 01 Dec 2000 06:33:02 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF. Title : End-to-end Performance Implications of Slow Links Author(s) : S. Dawkins, G. Montenegro, M. Kojo, V. Magret Filename : draft-ietf-pilc-slow-05.txt Pages : 16 Date : 30-Nov-00 This document makes performance-related recommendations for users of network paths that traverse 'very low bit-rate' links. 'Very low bit-rate' implies 'slower than we would like'. This recommendation may be useful in any network where hosts can saturate available bandwidth, but the design space for this recommendation explicitly includes connections that traverse 56 Kb/second modem links or 4.8 Kb/second wireless access links - both of which are widely deployed. This document discusses general-purpose mechanisms. Where application-specific mechanisms can outperform the relevant general-purpose mechanism, we point this out and explain why. This document has some recommendations in common with RFC 2689, 'Providing integrated services over low-bitrate links', especially in areas like header compression. This document focuses more on traditional data applications for which 'best-effort delivery' is appropriate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-slow-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pilc-slow-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-slow-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001130115230.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-slow-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-slow-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130115230.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Tue Dec 5 20:01:11 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29012 for ; Tue, 5 Dec 2000 20:01:10 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25392 for pilc-outgoing; Tue, 5 Dec 2000 19:09:29 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25345 for ; Tue, 5 Dec 2000 19:09:26 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14400; Tue, 5 Dec 2000 19:09:21 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014307; Tue, 5 Dec 00 19:09:12 -0500 Received: (qmail 3770 invoked by uid 0); 6 Dec 2000 00:08:36 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:08:36 +0900 (JST) Received: (qmail 4217 invoked from network); 27 Nov 2000 19:51:42 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 27 Nov 2000 19:51:42 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA21630 for pilc-outgoing; Mon, 27 Nov 2000 11:22:44 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA21607 for ; Mon, 27 Nov 2000 11:22:42 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA21854; Mon, 27 Nov 2000 11:22:41 -0500 Received: from motgate.mot.com(129.188.136.100) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021787; Mon, 27 Nov 00 11:22:27 -0500 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA21258; Mon, 27 Nov 2000 09:22:25 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA06425; Mon, 27 Nov 2000 09:22:24 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id LAA19633; Mon, 27 Nov 2000 11:22:24 -0500 (EST) Message-Id: <200011271622.LAA19633@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: karn@qualcomm.com cc: pilc@grc.nasa.gov Subject: Re: Updating LINK In-reply-to: Your message of "Wed, 22 Nov 2000 15:14:27 EST." <200011222314.PAA17328@patty.ka9q.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Nov 2000 11:22:23 -0500 From: Dan Grossman Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Phil, The reason for the lengthy exposition was that most people who aren't actively involved in QoS work usually don't understand the issues. My view was (and still is) that a "level set" is needed. Unfortunately, there is not one RFC (and I haven't found a good single paper in the literature) that one can point to that has information of this nature. QoS stuff is somewhat abstract, because unless one starts at first principle, one is likely to get it wrong. I disagree that "this has kept it from making progress in the real world." There are other reasons, which rate a side-discussion in San Diego but are off topic for this list. I don't think that the amount of exposiontion in my proposed text is inconsistent with the amount of exposition on, say TCP. There probably is some material which could be cut back, and if you strongly need to do that, it could be done. However, I really think your current version threw out the baby with the bathwater. It also retained some material that is at least misleading if not incorrect, namely the first couple of paragraphs. WRT subnet designers, in addition to the tutorial material, I think we need at a minimum to make the following points: -- QoS is quantitative and measureable. QoS != priority. -- Don't waste your time on QoS classes; use network mechanisms like RSVP to negotiate -- Don't assume that just setting a few bits in the IP header (TOS or Diffserv) solve your QoS problems -- QoS guarantees require cooperating mechanisms that play together as a system. Some of these are not stateless. I'm not able to do much on this for the next few days. We can talk about this in San Diego, or if you can be specific as to how much material you think needs to be cut out, I can try to rework. Dan From owner-pilc@lerc.nasa.gov Tue Dec 5 20:01:14 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29049 for ; Tue, 5 Dec 2000 20:01:13 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25564 for pilc-outgoing; Tue, 5 Dec 2000 19:10:31 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25503 for ; Tue, 5 Dec 2000 19:10:27 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14535; Tue, 5 Dec 2000 19:10:23 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014363; Tue, 5 Dec 00 19:09:21 -0500 Received: (qmail 3881 invoked by uid 0); 6 Dec 2000 00:08:42 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:08:42 +0900 (JST) Received: (qmail 2039 invoked from network); 28 Nov 2000 18:20:49 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 28 Nov 2000 18:20:49 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA14282 for pilc-outgoing; Tue, 28 Nov 2000 10:41:58 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA14243 for ; Tue, 28 Nov 2000 10:41:56 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA15481; Tue, 28 Nov 2000 10:41:54 -0500 Received: from porsta.cs.helsinki.fi(128.214.48.124) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015391; Tue, 28 Nov 00 10:41:18 -0500 Received: from kaloure.cs.Helsinki.FI (kojo@kaloure.cs.Helsinki.FI [128.214.9.79]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with ESMTP id RAA16003; Tue, 28 Nov 2000 17:41:11 +0200 Date: Tue, 28 Nov 2000 17:41:10 +0200 (EET) From: Markku Kojo To: Subject: PEP -05 and SLOW -05 submitted for IETF-49 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk New versions of draft-ietf-pilc-pep-05.txt and draft-ietf-pilc-slow-05.txt have been submitted to internet-drafts@ietf.org. As it might take a while before they will be available at the IETF central repository, I've also made them available at http://www.cs.helsinki.fi/u/kojo/draft-ietf-pilc-pep-05.txt and http://www.cs.helsinki.fi/u/kojo/draft-ietf-pilc-slow-05.txt Thanks, /Markku From owner-pilc@lerc.nasa.gov Tue Dec 5 20:01:21 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29088 for ; Tue, 5 Dec 2000 20:01:20 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25632 for pilc-outgoing; Tue, 5 Dec 2000 19:10:46 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25596 for ; Tue, 5 Dec 2000 19:10:42 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14622; Tue, 5 Dec 2000 19:10:40 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014496; Tue, 5 Dec 00 19:10:12 -0500 Received: (qmail 4411 invoked by uid 0); 6 Dec 2000 00:09:18 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:09:18 +0900 (JST) Received: (qmail 6470 invoked from network); 1 Dec 2000 13:33:45 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 1 Dec 2000 13:33:45 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA06166 for pilc-outgoing; Fri, 1 Dec 2000 06:33:57 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id GAA06146 for ; Fri, 1 Dec 2000 06:33:55 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA18567; Fri, 1 Dec 2000 06:33:54 -0500 Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.5) id xma018530; Fri, 1 Dec 00 06:33:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25781; Fri, 1 Dec 2000 06:32:58 -0500 (EST) Message-Id: <200012011132.GAA25781@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pilc@grc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pilc-link-design-04.txt Date: Fri, 01 Dec 2000 06:32:58 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF. Title : Advice for Internet Subnetwork Designers Author(s) : P. Karn, A. Falk, J. Touch, M. Montpetit, J. Mahdavi, G. Montenegro, D. Grossman, G. Fairhurst Filename : draft-ietf-pilc-link-design-04.txt Pages : 21 Date : 30-Nov-00 This document provides advice to the designers of digital communication equipment, link layer protocols and packet switched subnetworks (collectively referred to as subnetworks) who wish to support the Internet protocols but who may be unfamiliar with the architecture of the Internet and the implications of their design choices on the performance and efficiency of the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pilc-link-design-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-link-design-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001130115219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-link-design-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-link-design-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130115219.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Tue Dec 5 20:01:26 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29115 for ; Tue, 5 Dec 2000 20:01:26 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25610 for pilc-outgoing; Tue, 5 Dec 2000 19:10:43 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25577 for ; Tue, 5 Dec 2000 19:10:40 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14584; Tue, 5 Dec 2000 19:10:39 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014417; Tue, 5 Dec 00 19:09:26 -0500 Received: (qmail 3920 invoked by uid 0); 6 Dec 2000 00:08:45 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:08:45 +0900 (JST) Received: (qmail 2395 invoked from network); 29 Nov 2000 01:33:46 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 29 Nov 2000 01:33:46 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA11485 for pilc-outgoing; Tue, 28 Nov 2000 18:36:22 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA11464; Tue, 28 Nov 2000 18:36:20 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA23830; Tue, 28 Nov 2000 18:36:18 -0500 Received: from tc070.bbn.com(128.33.238.70) by seraph3.lerc.nasa.gov via smap (V5.5) id xmaa23735; Tue, 28 Nov 00 18:36:00 -0500 Received: from lawyers.grc.nasa.gov (mallman@localhost) by lawyers.grc.nasa.gov (8.9.3/8.9.3) with ESMTP id LAA00331; Tue, 28 Nov 2000 11:35:17 -0500 Message-Id: <200011281635.LAA00331@lawyers.grc.nasa.gov> To: tcpsat@grc.nasa.gov, pilc@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: Michael Hadjitheodosiou: CFP: Communications for Space Missions Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Roadhouse Blues Date: Tue, 28 Nov 2000 11:35:16 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk I was asked to forward this announcement to folks on tcpsat and pilc, as there very well could be interested folks on these lists. allman ------- Forwarded Message Date: Fri, 20 Oct 2000 15:51:09 -0400 To: mallman@grc.nasa.gov From: Michael Hadjitheodosiou Subject: CFP: Communications for Space Missions Call For Papers: Special Issue of the International Journal of Satellite Communications: Communications for Space Missions - ------------------------------------------------------------------------------- The start of the deployment of the International Space Station and an increasing number of planetary and other scientific missions have ushered in a new era in space exploration. At the same time, advances in communication technologies will allow investigators on Earth to enjoy a virtual presence in space. This generates a need to provide researchers with high quality communication support that will enable cost effective global access to experimental data from future space missions. Space agencies, like NASA, as well as Industry are also interested to gradually facilitate broadband Internet services throughout future space missions, eventually leading to a scenario where every spacecraft and instrument can be an addressable node and have a direct connection to the Internet. At the same time, there is a drive for space agencies to start utilizing capacity from commercial providers and adopt Commercial Of The Shelf technology. There is clearly a gradual transition to an operational scenario that will enable investigators to access their data "anytime, anywhere" through the Internet. For these reasons, the International Journal of Satellite Communications is launching a special issue on "Communications for Space Missions". This special issue will publish papers describing recent experiences and innovative new ideas on these issues. Specific topics of interest include, but are not limited to: - -Communication Architectures for supporting future near-Earth or Planetary missions. - - Network Issues related to extending IP services to next generation spacecraft. - - New Coding and Modulation techniques for Deep Space Missions. - - Related Antenna Technology developments (e.g. Ka-band, Phased Arrays). - - Protocol support for space missions [Custom protocols (SAFE, SCPS) Vs standard internet protocols (TCP/IP, FTP)]. - - Networking issues for constellations of : -formation flying Nano-satellites,; -networked sensors in space; -the "distributed spacecraft" concept. - - Supporting mission requirements using commercial satcomm providers. DEADLINES Intention to Submit with Abstract (up to 500 words): December 31st, 2000 (Include Full Paper, if available) Full Paper Due: February 28, 2001 Review Process/ Final Paper Due: June 30, 2001 Expected Publication Date: Summer 2001 SUBMISSION INSTRUCTIONS Interested authors should submit a Title / Abstract to : Dr. Michael Hadjitheodosiou Center for Satellite & Hybrid Communication Networks ISR, A.V. Williams Building University of Maryland, College Park MD 20742, USA Tel:+301-405-7904 Fax:+301-314-8586 e-mail: michalis@isr.umd.edu Preferred Method of Submission: - ------------------------------- By e-mail to: michalis@isr.umd.edu Abstract: TXT Format Full Paper: PDF (preferred), Postscript or MS Word electronic attachment. - --------------------------------------------------------------------------- The International Journal of Satellite Communications provides a focus for professionals in all aspects of satellite communications. The Journal covers all aspects of the theory and practice of satellite systems and networks. Information about the Journal: http://www.interscience.wiley.com/jpages/0737-2884/info.html ------- End of Forwarded Message From owner-pilc@lerc.nasa.gov Tue Dec 5 20:01:30 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29140 for ; Tue, 5 Dec 2000 20:01:29 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25386 for pilc-outgoing; Tue, 5 Dec 2000 19:09:28 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25338 for ; Tue, 5 Dec 2000 19:09:23 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14391; Tue, 5 Dec 2000 19:09:21 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014281; Tue, 5 Dec 00 19:08:57 -0500 Received: (qmail 3535 invoked by uid 0); 6 Dec 2000 00:08:21 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:08:21 +0900 (JST) Received: (qmail 10807 invoked from network); 24 Nov 2000 20:52:39 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 24 Nov 2000 20:52:39 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA13695 for pilc-outgoing; Fri, 24 Nov 2000 13:09:45 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA13686 for ; Fri, 24 Nov 2000 13:09:43 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA04821; Fri, 24 Nov 2000 13:09:42 -0500 Received: from diesel.erg.abdn.ac.uk(139.133.204.76) by seraph3.lerc.nasa.gov via smap (V5.5) id xma004798; Fri, 24 Nov 00 13:09:40 -0500 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.11.1/8.11.1) with ESMTP id eAOI9Y707019; Fri, 24 Nov 2000 18:09:35 GMT Message-ID: <3A1EAEDF.5EB481F3@erg.abdn.ac.uk> Date: Fri, 24 Nov 2000 18:09:37 +0000 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.73C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Reiner Ludwig , pilc@grc.nasa.gov Subject: Re: Comments to "Advice for Internet Subnetwork Designers" References: <4.3.2.7.0.20000801115412.00b847e0@chapelle.ericsson.se> < <5E5172B4DE05D311B3AB0008C75DA941019EF683@edeacnt100.eed.ericsson.se> <5E5172B4DE05D311B3AB0008C75DA941019EF683@edeacnt100.eed.ericsson.se> <4.3.2.7.0.20000801115412.00b847e0@chapelle.ericsson.se> <5.0.1.4.0.20001123152149.0244ab10@chapelle.ericsson.se> Content-Type: text/plain; charset=iso-8859-1; x-mac-type="54455854"; x-mac-creator="4D4F5353" X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id eAOI9Y707019 X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id NAA13688 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by lombok-fi.lerc.nasa.gov id TAA25386 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA29140 You make many interesting points... >Reiner Ludwig wrote: >I would also like to strongly promote clean designs, i.e., without layer > violations. But to implement what I call inter-flow out-of-order delivery > (as opposed to intra- > flow out-of-order delivery, i.e., o-o-o delivery > within a single flow), you do not need to have the link layer inspect IP > headers. > Instead, you could, e.g., run multiple logical link layers (one per flow) > across a hop, and have IP distribute the packets onto those links based on > port numbers. "one per flow" clearly does not scale, but for the first/last > hop this shouldn't be a problem. I agree with this idea. I like the idea of decoupling the ARQ between different flows. Ordering does not require persistence, or vice versa - yet many link protocols I have seen do both of these or neither. I know there are protocols which do not, and I am very interested in thinking about the implications of this. Have you thought about the pros and cons of using parallel links with individual ARQ? > I see highly persistent LL ARQ as independent from buffer memory. When some > people hear highly persistent LL ARQ, they often think that this equals > "buffering for ever". *No, it does not!* The queues need to remain > appropriately small also with highly persistent LL ARQ. > ///Reiner I think this is where I begin to get confused? When the link carries some TCP and some UDP flows. The UDP sources don’t simply stop because some of their data is lost or waiting transmission in the link layer. Then, don’t you end up with an excess of data queued at the link transmit interface. If the window/queue is small, then you drop? Do you have to drop UDP preferentially to keep TCP performance? I wonder what happens when you have many many TCP flows all sharing then, don’t you need to buffer a lot? or drop a lot? Gorry Fairhurst ------------------------------ http://www.erg.abdn.ac.uk/users/gorry From owner-pilc@lerc.nasa.gov Tue Dec 5 20:01:33 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29163 for ; Tue, 5 Dec 2000 20:01:32 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25565 for pilc-outgoing; Tue, 5 Dec 2000 19:10:31 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25518 for ; Tue, 5 Dec 2000 19:10:28 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14561; Tue, 5 Dec 2000 19:10:24 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014280; Tue, 5 Dec 00 19:08:56 -0500 Received: (qmail 3545 invoked by uid 0); 6 Dec 2000 00:08:22 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:08:22 +0900 (JST) Received: (qmail 10922 invoked from network); 24 Nov 2000 23:31:27 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 24 Nov 2000 23:31:27 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA25937 for pilc-outgoing; Fri, 24 Nov 2000 16:39:32 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA25921 for ; Fri, 24 Nov 2000 16:39:30 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA20662; Fri, 24 Nov 2000 16:39:29 -0500 Received: from servo.qualcomm.com(129.46.76.82) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020612; Fri, 24 Nov 00 16:38:40 -0500 Received: (from karn@localhost) by servo.qualcomm.com (8.9.3/8.9.3/1.0) id NAA04940; Fri, 24 Nov 2000 13:38:38 -0800 (PST) Date: Fri, 24 Nov 2000 13:38:38 -0800 (PST) Message-Id: <200011242138.NAA04940@servo.qualcomm.com> From: Phil Karn To: pilc@grc.nasa.gov Subject: draft-ietf-pilc-link-design-04.txt submitted Sender: owner-pilc@lerc.nasa.gov Precedence: bulk I have just submitted the latest version of the LINK document to internet-drafts@ietf.org. It's also up on my website as http://people.qualcomm.com/karn/pilc.txt The major changes in this version: 1. Fixed erroneous reference to the minimum MTU allowed in IP (thanks to Kevin Lahey for spotting this one). 2. Reworked the QoS section largely as I discussed on the list the other day. I removed the obsolete text about the old TOS bits, inserted some new explanatory text, and included the latter part of Dan Grossman's suggested text (the part with the list of actual recommendations to the subnetwork designers). 3. Wrote a new section on Fairness vs Performance. 4. Wrote a new section on Delay Characteristics. 5. Reworked the section on Packet Reordering to cite the Bennett/Partridge/Shectman paper, and to recommend that subnetwork packet reordering should be avoided unless doing so impairs performance, latency and/or reliability. 6. Wrote a new section on Multicasting. 7. Wrote a new section on Routing. 8. Wrote a new section on Security. Although the deadline for formal submissions is in about 20 minutes, comments are still welcome; I'll keep updating the copy on my website. Phil From owner-pilc@lerc.nasa.gov Tue Dec 5 20:01:35 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29184 for ; Tue, 5 Dec 2000 20:01:34 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25528 for pilc-outgoing; Tue, 5 Dec 2000 19:10:25 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25497 for ; Tue, 5 Dec 2000 19:10:23 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14516; Tue, 5 Dec 2000 19:10:22 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014240; Tue, 5 Dec 00 19:08:06 -0500 Received: (qmail 3098 invoked by uid 0); 6 Dec 2000 00:07:52 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:07:52 +0900 (JST) Received: (qmail 5410 invoked from network); 23 Nov 2000 01:46:57 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 23 Nov 2000 01:46:57 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA25146 for pilc-outgoing; Wed, 22 Nov 2000 18:14:40 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA25127 for ; Wed, 22 Nov 2000 18:14:39 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA00518; Wed, 22 Nov 2000 18:14:37 -0500 Received: from dhcp000913092958.qualcomm.com(129.46.77.76) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000477; Wed, 22 Nov 00 18:14:30 -0500 Received: (from karn@localhost) by patty.ka9q.net (8.9.3/8.9.3/Debian 8.9.3-21) id PAA17328; Wed, 22 Nov 2000 15:14:27 -0800 Date: Wed, 22 Nov 2000 15:14:27 -0800 Message-Id: <200011222314.PAA17328@patty.ka9q.net> From: Phil Karn To: pilc@grc.nasa.gov Reply-To: karn@qualcomm.com Subject: Updating LINK Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Hi all. I've been going over the PILC mail since the last IETF and am currently revising the LINK document before Friday's deadline. The old obsolete text is now gone from my copy; the question is how to replace it. In re-reading the discussion started by Dan Grossman's suggested new text for the QoS section, a few things occurred to me. I have always been struck by how discussions about QoS inevitably become extremely abstract, and I believe this has kept QoS from making much concrete progress in the real world. For example, Dan's section begins with a fairly lengthy (and abstract) review of current differentiated services work and ends with a single paragraph that dealt directly with link design issues. Given that not much of a consensus was reached in the ensuing list discussion, I'm inclined to leave out much of the review stuff in favor of pointers to existing documents, and to keep his last section. Since this is a document intended for subnetwork designers, any recommendations we make about QoS should be in concrete terms that subnetwork designers already understand. I still believe we should simply point out that many subnetworks have "knobs" that can make qualitative tradeoffs between competing measures of performance, that applications differ in which performance measures they consider important, give a few representative examples of such knobs, and recommend that the designers not preclude the ability of some future IP QoS mechanism to control them should the QoS folks ever figure out what they really want to do. Any comments? Phil From owner-pilc@lerc.nasa.gov Tue Dec 5 20:01:57 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29255 for ; Tue, 5 Dec 2000 20:01:56 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25391 for pilc-outgoing; Tue, 5 Dec 2000 19:09:29 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25319 for ; Tue, 5 Dec 2000 19:09:26 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14369; Tue, 5 Dec 2000 19:09:20 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014275; Tue, 5 Dec 00 19:08:51 -0500 Received: (qmail 3447 invoked by uid 0); 6 Dec 2000 00:08:16 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:08:16 +0900 (JST) Received: (qmail 8256 invoked from network); 24 Nov 2000 15:40:12 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 24 Nov 2000 15:40:12 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA24942 for pilc-outgoing; Fri, 24 Nov 2000 08:32:17 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id IAA24928 for ; Fri, 24 Nov 2000 08:32:16 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA13008; Fri, 24 Nov 2000 08:32:14 -0500 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012965; Fri, 24 Nov 00 08:31:48 -0500 Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 13zIx0-0007Fw-00; Fri, 24 Nov 2000 13:31:38 +0000 Date: Fri, 24 Nov 2000 13:31:38 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Reiner Ludwig cc: pilc@grc.nasa.gov Subject: Re: Comments to "Advice for Internet Subnetwork Designers" In-Reply-To: <5.0.1.4.0.20001123225519.0250dec0@chapelle.ericsson.se> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Thu, 23 Nov 2000, Reiner Ludwig wrote: > At 17:09 23.11.00, Lloyd Wood wrote: > >On Thu, 23 Nov 2000, Reiner Ludwig wrote: > > > A compliant TCP has no other chance but to go into go-back-N after a > > > spurious timeout, i.e., a spurious timeout forces TCP into the go-back-N. > > > >even with use of SACK and knowledge of the receiver window state? (Did > >I miss a timeout causing the SACK scoreboard to be discarded?) > > Yes, even with SACK. Note, that the first thing(s) a sender sees after a > spurious timeout are the returning ACKs that were triggered by the > *original* segments arriving at the receiver. Those ACKs will not carry any > SACK info. > > Sure, *after* the go-back-N has been performed, the sender will then find > out what went wrong when it receives D-SACK info in the ACKs that are > triggered by the duplicate segments sent during the go-back-N. But at that > point it's too late; an entire flight has already been resent unnecessarily. isn't this really an argument against bursts and in favour of TCP pacing? L. PGP From owner-pilc@lerc.nasa.gov Tue Dec 5 20:02:34 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29406 for ; Tue, 5 Dec 2000 20:02:33 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25620 for pilc-outgoing; Tue, 5 Dec 2000 19:10:44 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25593 for ; Tue, 5 Dec 2000 19:10:42 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14606; Tue, 5 Dec 2000 19:10:40 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014440; Tue, 5 Dec 00 19:09:59 -0500 Received: (qmail 4182 invoked by uid 0); 6 Dec 2000 00:09:03 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:09:03 +0900 (JST) Received: (qmail 4678 invoked from network); 30 Nov 2000 13:27:55 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 30 Nov 2000 13:27:55 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA11093 for pilc-outgoing; Thu, 30 Nov 2000 05:57:29 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id FAA11079 for ; Thu, 30 Nov 2000 05:57:27 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id FAA28849; Thu, 30 Nov 2000 05:57:26 -0500 Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028826; Thu, 30 Nov 00 05:57:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28006; Thu, 30 Nov 2000 05:57:14 -0500 (EST) Message-Id: <200011301057.FAA28006@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pilc@grc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pilc-asym-02.txt Date: Thu, 30 Nov 2000 05:57:13 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF. Title : TCP Performance Implications of Network Asymmetry Author(s) : H. Balakrishnan, V. Padmanabhan Filename : draft-ietf-pilc-asym-02.txt Pages : 15 Date : 29-Nov-00 This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio networks, for different underlying reasons. However, the net effect on TCP performance is the same in both cases: performance degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender. This document details several solutions to these problems, which use a combination of local link-layer techniques and end-to-end mechanisms. Solutions to the problem of asymmetry are two-pronged: (i) techniques to manage the reverse channel used by ACKs, typically using header compression or reducing the frequency of TCP ACKs, and (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's acknowledgment-triggered self-clocking. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-asym-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pilc-asym-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-asym-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001129114548.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-asym-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-asym-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001129114548.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Tue Dec 5 20:02:37 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29417 for ; Tue, 5 Dec 2000 20:02:36 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25271 for pilc-outgoing; Tue, 5 Dec 2000 19:07:59 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25262 for ; Tue, 5 Dec 2000 19:07:57 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14215; Tue, 5 Dec 2000 19:07:57 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014185; Tue, 5 Dec 00 19:07:40 -0500 Received: (qmail 2832 invoked by uid 0); 6 Dec 2000 00:07:33 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:07:33 +0900 (JST) Received: (qmail 590 invoked from network); 21 Nov 2000 18:18:19 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 21 Nov 2000 18:18:19 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA19859 for pilc-outgoing; Tue, 21 Nov 2000 10:14:28 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA19803 for ; Tue, 21 Nov 2000 10:14:26 -0500 (EST) From: aaron@PanAmSat.com Received: by seraph3.lerc.nasa.gov; id KAA03536; Tue, 21 Nov 2000 10:14:23 -0500 Received: from unknown(208.217.183.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003419; Tue, 21 Nov 00 10:14:15 -0500 Received: by atlconn1.panamsat.com with Internet Mail Service (5.5.2650.10) id ; Tue, 21 Nov 2000 10:14:15 -0500 Message-ID: <0703A3E1D430D411866100508BDFCF331918A0@CTOEXCH1> To: pilc@grc.nasa.gov Subject: FW: A New IETF Work Area Date: Tue, 21 Nov 2000 10:12:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk I don't think everyone on the PILC list is on the IETF Announce list. This may be of interest. The creation of this area will not affect the PILC working group. --aaron -----Original Message----- From: Fred Baker [mailto:chair@ietf.org] Sent: Monday, November 20, 2000 5:15 PM Subject: A New IETF Work Area Traditionally the IETF has focused its efforts "above the wire and below the application." Occasionally standards track RFCs have given advice to application implementors about what application-level commands a user should be able to execute ( e.g., Requirements for Internet Hosts -- Application and Support - RFC 1123), defined software APIs (e.g., GSSAPI - RFC 2743), and given advice on the proper use of the features of IETF technology (e.g., Use of HTTP State Management. - RFC 2964). But mostly we have left the specifications of applications and how 'wires' such as Ethernet or ATM are defined and operate to other standards organizations or to the market place. Over the years the boundary between 'wires' and IP protocols has become harder to define and the interaction has become more intertwined. For example, what appear as 'wires' or 'circuits' in a virtual network may in fact be routed datagrams in an underlying IP network. The topology of dynamic underlying networks such as ATM and soon switched optical networks can interact with IP-level traffic engineering and routing. Additionally, with IETF technologies such as MPLS we are defining a whole new class of 'wires'. It has become increasingly clear that the IETF needs to develop a systematic approach to dealing with what we used to describe as "sub-IP" technologies. This approach should be able to help clarify what specific technologies the IETF should work on, what technologies we should forward to other organizations, and what technologies we need to work with other organizations to develop. In this effort the IETF is not proposing to develop physical wire technologies such as Ethernet, we are proposing to figure out common ways to monitor and control such technologies as they apply to IP networks. The existing and any new IETF sub-IP efforts such as MPLS should be grouped together under common management. As a first cut at such a systematic approach the IESG has decided to establish a new sub-IP pseudo-area. This pseudo-area will be temporarily housed in the General Area with the IETF Chair acting as Area Director and with the Area Directors of a number of existing IETF Areas acting as a joint technical and management team. We do not expect this to be a long term arrangement and the status of the sub-IP effort will be reviewed during the Spring of 2001. At that time, the IESG will determine which of the following three options will be pursued. The IESG could determine that there is a need for a long term effort in this arena. If that is the case the IESG will establish an additional IETF Area and ask the nomcom to select one or two Area Directors to manage it. A second possibility is that the IESG could determine that there is a need for a short term (one to two year) coordinated effort in which case the IESG could establish a new temporary area as was done in the case of IPng and appoint two current Area Directors to manage the effort co-terminus with their current assignments. The third possibility is that some of the working groups being moved into the pseudo-area and some of the new working groups will finish up their work by the fall of 2001 with insufficient remaining work left over to justify the creation of even a temporary area. In that case whatever working groups remain would be dispersed to existing IETF areas. Some existing IETF working groups will be moved into this pseudo-area and a number of new working groups will be created. They will be listed under the General Area on the agenda for the San Diego IETF meeting. There are also some BOFs scheduled to be held in San Diego that may, if they become working groups, be located in the pseudo-area. One example is the Circuit over IP BOF (coip). The existing IETF working groups that will be moved into the pseudo-area are Multiprotocol Label Switching (mpls) and Internet Traffic Engineering (tewg). New and proposed working groups that are being located in this pseudo-area include: Common Control and Measurement Planes (CoMa), Provider Provisioned Virtual Private Networks (ppvpn), IP over Packet Transport Rings (ipoptr), and IP over Optical (ipo). Draft charters for these working groups were posted earlier today. From owner-pilc@lerc.nasa.gov Tue Dec 5 20:02:41 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29443 for ; Tue, 5 Dec 2000 20:02:41 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25346 for pilc-outgoing; Tue, 5 Dec 2000 19:09:22 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25292 for ; Tue, 5 Dec 2000 19:09:19 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14325; Tue, 5 Dec 2000 19:09:18 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014194; Tue, 5 Dec 00 19:07:49 -0500 Received: (qmail 2969 invoked by uid 0); 6 Dec 2000 00:07:44 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:07:44 +0900 (JST) Received: (qmail 4514 invoked from network); 22 Nov 2000 13:37:48 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 22 Nov 2000 13:37:48 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA18396 for pilc-outgoing; Wed, 22 Nov 2000 06:14:31 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id GAA18375 for ; Wed, 22 Nov 2000 06:14:30 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA21733; Wed, 22 Nov 2000 06:14:29 -0500 Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021661; Wed, 22 Nov 00 06:13:32 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21522; Wed, 22 Nov 2000 06:13:31 -0500 (EST) Message-Id: <200011221113.GAA21522@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pilc@grc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pilc-link-arq-issues-00.txt Date: Wed, 22 Nov 2000 06:13:30 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF. Title : Link ARQ issues for IP traffic Author(s) : G. Fairhurst, L. Wood Filename : draft-ietf-pilc-link-arq-issues-00.txt Pages : 17 Date : 21-Nov-00 This document discusses use of automatic repeat request (ARQ) procedures as an option in the design of a link protocol, and the impact of the use of ARQ on IP traffic travelling over the link. ARQ is described in a general way that includes its use over a wide range of underlying physical media, including cellular wireless, wireless LANs, RF links, and other types of bearer channel. This document is intended to provide guidance, and to outline matters for consideration, for designers and implementers of future link ARQ mechanisms. The material presented here is intended to be combined with the PILC 'Advice for Internet Subnetwork Designers' draft [DRAFTKARN00] to provide a single document giving guidance to subnetwork designers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-arq-issues-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pilc-link-arq-issues-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-link-arq-issues-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001121111444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-link-arq-issues-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-link-arq-issues-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001121111444.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Tue Dec 5 20:02:44 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29467 for ; Tue, 5 Dec 2000 20:02:44 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25350 for pilc-outgoing; Tue, 5 Dec 2000 19:09:22 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25293 for ; Tue, 5 Dec 2000 19:09:20 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14333; Tue, 5 Dec 2000 19:09:19 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014252; Tue, 5 Dec 00 19:08:25 -0500 Received: (qmail 3278 invoked by uid 0); 6 Dec 2000 00:08:05 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:08:05 +0900 (JST) Received: (qmail 7152 invoked from network); 24 Nov 2000 01:33:34 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 24 Nov 2000 01:33:34 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA24475 for pilc-outgoing; Thu, 23 Nov 2000 17:14:49 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA24461 for ; Thu, 23 Nov 2000 17:14:47 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA12631; Thu, 23 Nov 2000 17:14:46 -0500 Received: from albatross-ext.wise.edt.ericsson.se(194.237.142.116) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012599; Thu, 23 Nov 00 17:14:40 -0500 Received: from aachen.eed.ericsson.se (aachen.eed.ericsson.se [164.48.130.2]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eANMEct05575; Thu, 23 Nov 2000 23:14:39 +0100 (MET) Received: from e00d059101eba.Ericsson.com (rac166pc.edd.ericsson.se [164.48.123.166]) by aachen.eed.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id XAA21801; Thu, 23 Nov 2000 23:14:35 +0100 (MET) Message-Id: <5.0.1.4.0.20001123225519.0250dec0@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 23 Nov 2000 23:03:35 +0100 To: L.Wood@eim.surrey.ac.uk From: Reiner Ludwig Subject: Re: Comments to "Advice for Internet Subnetwork Designers" Cc: pilc@grc.nasa.gov In-Reply-To: References: <5.0.1.4.0.20001123152149.0244ab10@chapelle.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 17:09 23.11.00, Lloyd Wood wrote: >On Thu, 23 Nov 2000, Reiner Ludwig wrote: > > A compliant TCP has no other chance but to go into go-back-N after a > > spurious timeout, i.e., a spurious timeout forces TCP into the go-back-N. > >even with use of SACK and knowledge of the receiver window state? (Did >I miss a timeout causing the SACK scoreboard to be discarded?) Yes, even with SACK. Note, that the first thing(s) a sender sees after a spurious timeout are the returning ACKs that were triggered by the *original* segments arriving at the receiver. Those ACKs will not carry any SACK info. Sure, *after* the go-back-N has been performed, the sender will then find out what went wrong when it receives D-SACK info in the ACKs that are triggered by the duplicate segments sent during the go-back-N. But at that point it's too late; an entire flight has already been resent unnecessarily. ///Reiner From owner-pilc@lerc.nasa.gov Tue Dec 5 20:03:32 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29634 for ; Tue, 5 Dec 2000 20:03:31 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25272 for pilc-outgoing; Tue, 5 Dec 2000 19:07:59 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25261 for ; Tue, 5 Dec 2000 19:07:57 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14211; Tue, 5 Dec 2000 19:07:56 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014186; Tue, 5 Dec 00 19:07:37 -0500 Received: (qmail 2849 invoked by uid 0); 6 Dec 2000 00:07:35 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:07:35 +0900 (JST) Received: (qmail 1790 invoked from network); 22 Nov 2000 02:21:24 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 22 Nov 2000 02:21:24 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA11295 for pilc-outgoing; Tue, 21 Nov 2000 18:15:06 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA11282 for ; Tue, 21 Nov 2000 18:15:05 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA17209; Tue, 21 Nov 2000 18:15:03 -0500 Received: from lagrange.ee.washington.edu(128.95.31.212) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017163; Tue, 21 Nov 00 18:14:50 -0500 Received: from localhost (hussein@localhost) by lagrange.ee.washington.edu (8.9.3/8.9.3) with ESMTP id PAA12405; Tue, 21 Nov 2000 15:13:47 -0800 (PST) Date: Tue, 21 Nov 2000 15:13:47 -0800 (PST) From: "A. Abou-Zeid" To: pilc@grc.nasa.gov cc: Marcelo Albuquerque , "Prof. Sumit Roy" Subject: Error Models for TCP performance evaluation over lossy links Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk The attached note describes briefly our experience with regard to the above mentioned topic, with pointers to more detailed information that may be of interest to this list. Most of the research involving TCP and lossy channels face a critical decision when choosing the most adequate error model to be used. One should use caution when opting between a discrete-time two-state error model, where channel state transitions occur synchronously with packet transmissions, and a continuous-time two-state error model, where channel state transitions occur independently from packet transmissions. In the network simulator (http://www.isi.edu/nsnam), the discrete-time two state model corresponds to the former while the continuous-time model proposed in (http://students.washington.edu/abouzeid/research.htm) corresponds to the latter. The discrete-time model has the advantage of allowing for a direct computation of relevant statistics such as average packet error rate and correlation between errors. Expressing results such as throughput as a function of these parameters is quite standard in most research work. However, the model fails to be physically realistic since its state transitions are dependent on TCP dynamics. In some situations this translates into unreasonable patterns in channel state transition. The continuous-time model makes the channel state independent from TCP dynamics but makes it very difficult to obtain the most widely used error statistics, such as packet error rate. Please refer to http://students.washington.edu/marcelo/errormodels.html for a more detailed report on this issue. Best regards, Alhussein for Marcelo Albuquerque, Alhussein Abouzeid, Sumit Roy Fundamentals of Networking Laboratory (FuNLab) Department of Electrical Engineering University of Washington, Seattle From owner-pilc@lerc.nasa.gov Tue Dec 5 20:03:44 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29687 for ; Tue, 5 Dec 2000 20:03:44 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25370 for pilc-outgoing; Tue, 5 Dec 2000 19:09:25 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25335 for ; Tue, 5 Dec 2000 19:09:22 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14382; Tue, 5 Dec 2000 19:09:20 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014279; Tue, 5 Dec 00 19:08:55 -0500 Received: (qmail 3525 invoked by uid 0); 6 Dec 2000 00:08:21 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:08:21 +0900 (JST) Received: (qmail 10725 invoked from network); 24 Nov 2000 19:29:03 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 24 Nov 2000 19:29:02 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA09303 for pilc-outgoing; Fri, 24 Nov 2000 11:59:08 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA09280 for ; Fri, 24 Nov 2000 11:59:05 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA29198; Fri, 24 Nov 2000 11:59:04 -0500 Received: from 24-130-188-101.san.rr.com(24.130.188.101) by seraph3.lerc.nasa.gov via smap (V5.5) id xma029141; Fri, 24 Nov 00 11:58:43 -0500 Received: (from karn@localhost) by homer.ka9q.net (8.9.3/8.9.3/Debian 8.9.3-21) id IAA20743; Fri, 24 Nov 2000 08:58:15 -0800 Date: Fri, 24 Nov 2000 08:58:15 -0800 Message-Id: <200011241658.IAA20743@homer.ka9q.net> From: Phil Karn To: L.Wood@eim.surrey.ac.uk CC: Reiner.Ludwig@ericsson.com, pilc@grc.nasa.gov In-reply-to: (message from Lloyd Wood on Thu, 23 Nov 2000 16:09:43 +0000 (GMT)) Subject: Re: Comments to "Advice for Internet Subnetwork Designers" Reply-to: karn@qualcomm.com References: Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >> A compliant TCP has no other chance but to go into go-back-N after a >> spurious timeout, i.e., a spurious timeout forces TCP into the go-back-N. >even with use of SACK and knowledge of the receiver window state? (Did >I miss a timeout causing the SACK scoreboard to be discarded?) I'm still confused here. I have always understood TCP to requre (or at least strongly encourage) that when a timeout occurs, only the oldest unacknowledged segment is retransmitted. If this fills a hole in the receiver's reassembly queue (the receiver has already received subsequent segments), the receiver will ack as much as it can. This is not classic "go-back-N" as it was implemented in HDLC LAPB, for example. In LAPB, anything received after a missing frame was discarded, and the sender resends all N frames from the missing frame onward. Obviously this is much less efficient than resending just the missing frame. So perhaps by "go back N" you simply meant that TCP has to go back and fill in the missing packet with a retransmission, not retransmit the entire window's worth of data? Phil From owner-pilc@lerc.nasa.gov Tue Dec 5 20:04:12 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29799 for ; Tue, 5 Dec 2000 20:04:12 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25531 for pilc-outgoing; Tue, 5 Dec 2000 19:10:26 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25496 for ; Tue, 5 Dec 2000 19:10:23 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14508; Tue, 5 Dec 2000 19:10:22 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014237; Tue, 5 Dec 00 19:08:03 -0500 Received: (qmail 3102 invoked by uid 0); 6 Dec 2000 00:07:53 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:07:52 +0900 (JST) Received: (qmail 5454 invoked from network); 23 Nov 2000 02:47:41 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 23 Nov 2000 02:47:41 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA00151 for pilc-outgoing; Wed, 22 Nov 2000 19:45:37 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA00126 for ; Wed, 22 Nov 2000 19:45:35 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA08273; Wed, 22 Nov 2000 19:45:34 -0500 Received: from dhcp000913092958.qualcomm.com(129.46.77.76) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008242; Wed, 22 Nov 00 19:45:06 -0500 Received: (from karn@localhost) by patty.ka9q.net (8.9.3/8.9.3/Debian 8.9.3-21) id QAA17520; Wed, 22 Nov 2000 16:45:02 -0800 Date: Wed, 22 Nov 2000 16:45:02 -0800 Message-Id: <200011230045.QAA17520@patty.ka9q.net> From: Phil Karn To: Reiner.Ludwig@ericsson.com CC: pilc@grc.nasa.gov Reply-To: karn@qualcomm.com In-reply-to: <4.3.2.7.0.20000801115412.00b847e0@chapelle.ericsson.se> (message from Reiner Ludwig on Tue, 01 Aug 2000 12:33:54 +0200) Subject: Re: Comments to "Advice for Internet Subnetwork Designers" References: < <5E5172B4DE05D311B3AB0008C75DA941019EF683@edeacnt100.eed.ericsson.se> <5E5172B4DE05D311B3AB0008C75DA941019EF683@edeacnt100.eed.ericsson.se> <4.3.2.7.0.20000801115412.00b847e0@chapelle.ericsson.se> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Going back to some mail of yours from early August, I've been giving your comments a lot of thought, and I have to admit I'm moving closer to your point of view on some things. >>What you really want to avoid are the nasty interactions between TCP >>and link/physical layer retransmissions that can occur in certain link >>operating regions. >People often talk about those interactions as if there where so many of >those. What are those interactions you are talking about? >I only know of two such interactions: >(1) spurious timeouts that lead to a go-back-N retransmisison mode in TCP, and A compliant TCP never does go-back-N; it only retransmits the oldest unacked segment. But even this could be a spurious retransmission if the earlier delay was caused by a link layer retransmission. >(2) out-of-order delivery at the link layer that falsely triggers fast >retransmit / fast recovery. I think this is not as significant a problem in practice, since most link layers already enforce packet ordering. >Given that PILC recommends that link layers should avoid out-of-order >delivery (also for the sake of not causing trouble for TCP/IP header >compression) this leaves spurious timeouts as the cardinal problem. But now I'm no longer sure that ordered delivery at the link level is even a good thing. The basic problem is that ordered delivery can only be done by intentionally delaying any packets that would otherwise be delivered out of order. This is harmless or even beneficial if the delayed packets belong to the same TCP connection. But if they don't, then you merely impair the performance of the other connection(s) with no compensating benefit. (True, the link *could* peek at the TCP and IP headers and only enforce in-order delivery of packets belonging to the same TCP connection, but that would be an egregious layer violation -- i.e., it wouldn't work with IPSEC). I believe this is much the same reasoning that originally led to the Internet architects to say that IP need not deliver packets in sequence, that reordering is a transport layer responsibility. Transport protocols can compensate for many subnetwork and Internet ills, including packet loss, duplication and reordering. But high delay is one subnetwork ill that a transport protocol can *never* overcome. That's why I think any low-level mechanism that deliberately introduces delay should be viewed with great skepticism. This also leads to the conclusion that if packet reordering spuriously triggers TCP's dup ack mechanism, then this is really TCP's fault and it should be fixed inside TCP. (I didn't say this would be easy, though.) This leaves one remaining argument for ordered delivery on links: VJ header compression. So we could simply say that in-order delivery is important only if you plan to implement VJ header compression. Anyway, back to retransmission interactions. >>But whenever the link layer retransmits, the RTT spikes >>and there's a spurious TCP retransmission. >This is a simply not true. You have to let things go really bad to force a >spurious timeout in TCP. Depending on your path characteristics especially You say it's rare, but it is something I've seen quite often in TCP traces. I think this difference is simply due to our having operated over different environments. Our air links tend to have relatively high latencies even without link level retransmissions, and more significantly this latency tends to dominate that of the total Internet path. So we probably see many more cases of spurious TCP retransmissions being triggered by link retransmissions than you do. Also, our link protocols have historically been implemented in cell phones with severely limited memory resources, and this has led us to implement non-persistent link ARQ schemes that don't require a lot of buffer memory. Of course, this problem is going away over time. But perhaps you're right that, overall, it's better to not limit the persistence of the link layer ARQ scheme. Fair queuing might help limit the effect of the spurious retransmissions on other competing flows, for example. Also, having a highly persistent link layer ARQ might be the best way to help TCP recover quickly from sustained link outages. Phil From owner-pilc@lerc.nasa.gov Tue Dec 5 20:04:32 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29879 for ; Tue, 5 Dec 2000 20:04:31 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25385 for pilc-outgoing; Tue, 5 Dec 2000 19:09:27 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25315 for ; Tue, 5 Dec 2000 19:09:24 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14362; Tue, 5 Dec 2000 19:09:20 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014271; Tue, 5 Dec 00 19:08:46 -0500 Received: (qmail 3451 invoked by uid 0); 6 Dec 2000 00:08:16 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:08:16 +0900 (JST) Received: (qmail 8257 invoked from network); 24 Nov 2000 15:40:12 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 24 Nov 2000 15:40:12 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA23775 for pilc-outgoing; Fri, 24 Nov 2000 08:13:13 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id IAA23761 for ; Fri, 24 Nov 2000 08:13:11 -0500 (EST) From: Marie-Jose.Montpetit@nokia.com Received: by seraph3.lerc.nasa.gov; id IAA11679; Fri, 24 Nov 2000 08:13:10 -0500 Received: from mgw-dax2.ext.nokia.com(63.78.179.217) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011635; Fri, 24 Nov 00 08:12:58 -0500 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eAODCt620294 for ; Fri, 24 Nov 2000 07:13:15 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Fri, 24 Nov 2000 07:12:27 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 24 Nov 2000 07:12:27 -0600 Message-ID: To: karn@qualcomm.com, pilc@grc.nasa.gov Subject: RE: Updating LINK Date: Fri, 24 Nov 2000 07:04:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk snip/snip Since this is a document intended for subnetwork designers, any recommendations we make about QoS should be in concrete terms that subnetwork designers already understand. I still believe we should simply point out that many subnetworks have "knobs" that can make qualitative tradeoffs between competing measures of performance, that applications differ in which performance measures they consider important, give a few representative examples of such knobs, and recommend that the designers not preclude the ability of some future IP QoS mechanism to control them should the QoS folks ever figure out what they really want to do. Any comments? Well yes I agree with the approach. I think we have erred maybe a bit to much on the high level advice :-) I think for QoS in particular whatever is at the edge of the subnet has to do the "translation" from what the application/session needs into what the subnet can deliver (or cannot deliver for that matter). In any subnet that does encapsulation or segmenting of the IP packet there are often a native set of QoS "levels" that will be used and mapped to the diffserv classes. Phil, are you suggesting we (pilc) should define the mapping mechanisms or the QoS signaling (some RSVP-light for edge devices that are not routers?) and look at subnet-level admission control based on resource management methods? I think that would be valuable but maybe worth of a draft of it's own. Marie-Jose From owner-pilc@lerc.nasa.gov Tue Dec 5 20:04:44 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29922 for ; Tue, 5 Dec 2000 20:04:43 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25631 for pilc-outgoing; Tue, 5 Dec 2000 19:10:46 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25583 for ; Tue, 5 Dec 2000 19:10:41 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14600; Tue, 5 Dec 2000 19:10:40 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014436; Tue, 5 Dec 00 19:09:48 -0500 Received: (qmail 4100 invoked by uid 0); 6 Dec 2000 00:08:56 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:08:56 +0900 (JST) Received: (qmail 3848 invoked from network); 29 Nov 2000 21:29:56 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 29 Nov 2000 21:29:56 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA20605 for pilc-outgoing; Wed, 29 Nov 2000 13:51:39 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA20510 for ; Wed, 29 Nov 2000 13:51:36 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA23591; Wed, 29 Nov 2000 13:51:30 -0500 Received: from ertpg14e1.nortelnetworks.com(47.234.0.35) by seraph3.lerc.nasa.gov via smap (V5.5) id xma023484; Wed, 29 Nov 00 13:50:57 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Wed, 29 Nov 2000 13:30:41 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 29 Nov 2000 13:30:41 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A893D@zwdld001.ca.nortel.com> From: "Gary Kenward" To: pilc@grc.nasa.gov Subject: comments on draft-pilc-link-arq-issues-00 Date: Wed, 29 Nov 2000 13:30:28 -0500 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05A32.72DEC2C0" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C05A32.72DEC2C0 Content-Type: text/plain; charset="iso-8859-1" I have two comments on the draft draft-pilc-link-arq-issues-00: 1. Under Section 2, ARQ Persistence, the second paragraph attempts to define "retransmission persistence". There are many dimensions to persistence at the link layer, and I feel the current description is not clear enough. From an ARQ perspective, there is not only the duration of repeated attempts, but also the frequency and priority of the attempts. The reason I was initially confused by the text is that I am more familiar with the definition of persistence as used with stochastic contention resolution protocols such as CSMA; e.g. p-persistent CSMA refers to the probability that a retransmission will be attempted within a certain time period. Perhaps this is too much detail for a draft of this scope, however, given that the concept of persistence is used throughout the draft, it should be defined more crisply, and, the definition should be complete. 2. In the subsections 2.n, you characterize different types of persistence as a trade off between delay and reliability. Again, frequency and priority of repeats must be accounted for in your taxonomy. However, I also wanted to point out that the reason many protocols, including Ethernet, use a finite number of repeated transfer attempts (or retransmissions in Ethernet) is to ensure *stability* of the channel. An ARQ protocol with an infinite number of repeated attempts is generally unstable. A finite number of retransmissions does not necessarily ensure stability. I do not have the references at hand (I could probably find them if you are interested), but for a finite population size, stability bounds on the number of repeats have been derived for particular protocols (e.g. CSMA, ALOHA, S-CSMA, S-ALOHA). I hope these comments help. If I have missed something, I would happy to know it. Gary Kenward ========================================================================== Gary W. Kenward gkenward@nortelnetworks.com ========================================================================== As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. -- Albert Einstein ------_=_NextPart_001_01C05A32.72DEC2C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable comments on draft-pilc-link-arq-issues-00

I have two comments = on the draft draft-pilc-link-arq-issues-00:

 1. Under = Section 2, ARQ Persistence, the second paragraph attempts
     to define "retransmission = persistence".  There are many dimensions to
     persistence at the link layer, and I feel = the current description is
     not clear enough. From an ARQ perspective, = there is not only the
     duration of repeated attempts, but also = the frequency and priority
     of the attempts.

     The reason I was initially confused by the = text is that I am more
     familiar with the definition of = persistence as used with stochastic
     contention resolution protocols such as = CSMA; e.g. p-persistent
     CSMA refers to the probability that a = retransmission will be
     attempted within a certain time = period.

     Perhaps this is too much detail for a = draft of this scope, however,
     given that the concept of persistence is = used throughout the draft,
     it should be defined more crisply, and, = the definition should
     be complete.

  2. In the = subsections 2.n, you characterize different types of persistence
      as a trade off between delay and = reliability. Again, frequency
      and priority of repeats must be = accounted for in your taxonomy.

      However, I also wanted to point out = that the reason many protocols,
      including Ethernet, use a finite = number of repeated transfer attempts
      (or retransmissions in Ethernet) is = to ensure *stability* of the channel.
      An ARQ protocol with an infinite = number of repeated attempts is
      generally unstable.

      A finite number of retransmissions = does not necessarily ensure stability.
      I do not have the references at hand = (I could probably find them if you
      are interested), but for a finite = population size, stability bounds on the
      number of repeats have been derived = for particular protocols (e.g. CSMA,
      ALOHA, S-CSMA, S-ALOHA).

I hope these comments = help. If I have missed something, I would happy
to know it.

Gary Kenward
    =20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
Gary W. = Kenward           = ;            = ;            = gkenward@nortelnetworks.com       &nb= sp;           &nb= sp; 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

As far as = the laws of mathematics refer to reality, they are not certain;
and as far = as they are certain, they do not refer to reality.
-- Albert = Einstein


------_=_NextPart_001_01C05A32.72DEC2C0-- From owner-pilc@lerc.nasa.gov Tue Dec 5 20:05:33 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00052 for ; Tue, 5 Dec 2000 20:05:28 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25379 for pilc-outgoing; Tue, 5 Dec 2000 19:09:27 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25353 for ; Tue, 5 Dec 2000 19:09:24 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14410; Tue, 5 Dec 2000 19:09:21 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014309; Tue, 5 Dec 00 19:09:15 -0500 Received: (qmail 3787 invoked by uid 0); 6 Dec 2000 00:08:37 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:08:37 +0900 (JST) Received: (qmail 4536 invoked from network); 28 Nov 2000 02:38:06 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 28 Nov 2000 02:38:06 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA01417 for pilc-outgoing; Mon, 27 Nov 2000 19:16:18 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA01410 for ; Mon, 27 Nov 2000 19:16:17 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA22006; Mon, 27 Nov 2000 19:16:16 -0500 Received: from ertpg14e1.nortelnetworks.com(47.234.0.35) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021959; Mon, 27 Nov 00 19:15:44 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Mon, 27 Nov 2000 17:44:44 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 27 Nov 2000 17:44:40 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8923@zwdld001.ca.nortel.com> From: "Gary Kenward" To: "'Dan Grossman'" , karn@qualcomm.com Cc: pilc@grc.nasa.gov Subject: RE: Updating LINK Date: Mon, 27 Nov 2000 17:44:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C058C3.9DDF0680" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C058C3.9DDF0680 Content-Type: text/plain; charset="iso-8859-1" Dan: I could not agree with your email more. It echoes every point I have been trying to designers for the last year. While I also agree with your statement "QoS is quantitative and measurable", I have found that the Diff Serv model tends to, at best, muddy the water. Subnet designers tend to want to define Classes of Service and specify performance bounds (c.f. 3GPP QoS). I consider this a bad approach, as it embeds, at the subnetwork level, QoS definitions that are ultimately application driven. If I understand your observations completely, you are proposing a "parametric control" approach to QoS configuration on the subnet (perhaps using RSVP)? Do you foresee any problems in saying as much in the draft? Regards, Gary Kenward ========================================================================== Gary W. Kenward gkenward@nortelnetworks.com Advisor, Wireless Architecture (613) 765-1437 Advanced Technology Labs FAX: (613) 763-2686 Nortel Networks ========================================================================== As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. -- Albert Einstein -----Original Message----- From: Dan Grossman [mailto:dan@dma.isg.mot.com] Sent: Monday, November 27, 2000 11:22 AM To: karn@qualcomm.com Cc: pilc@grc.nasa.gov Subject: Re: Updating LINK Phil, The reason for the lengthy exposition was that most people who aren't actively involved in QoS work usually don't understand the issues. My view was (and still is) that a "level set" is needed. Unfortunately, there is not one RFC (and I haven't found a good single paper in the literature) that one can point to that has information of this nature. QoS stuff is somewhat abstract, because unless one starts at first principle, one is likely to get it wrong. I disagree that "this has kept it from making progress in the real world." There are other reasons, which rate a side-discussion in San Diego but are off topic for this list. I don't think that the amount of exposiontion in my proposed text is inconsistent with the amount of exposition on, say TCP. There probably is some material which could be cut back, and if you strongly need to do that, it could be done. However, I really think your current version threw out the baby with the bathwater. It also retained some material that is at least misleading if not incorrect, namely the first couple of paragraphs. WRT subnet designers, in addition to the tutorial material, I think we need at a minimum to make the following points: -- QoS is quantitative and measureable. QoS != priority. -- Don't waste your time on QoS classes; use network mechanisms like RSVP to negotiate -- Don't assume that just setting a few bits in the IP header (TOS or Diffserv) solve your QoS problems -- QoS guarantees require cooperating mechanisms that play together as a system. Some of these are not stateless. I'm not able to do much on this for the next few days. We can talk about this in San Diego, or if you can be specific as to how much material you think needs to be cut out, I can try to rework. Dan ------_=_NextPart_001_01C058C3.9DDF0680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Updating LINK

Dan:

  I could not agree with your email more. It = echoes every point I have been trying to
designers for the last year.

  While I also agree with your statement = "QoS is quantitative and measurable", I have
found that the Diff Serv model tends to, at best, = muddy the water. Subnet designers
tend to want to define Classes of Service and = specify performance bounds (c.f. 3GPP
QoS). I consider this a bad approach, as it embeds, = at the subnetwork level, QoS
definitions that are ultimately application = driven.

  If I understand your observations completely, = you are proposing a "parametric control"
approach to QoS configuration on the subnet (perhaps = using RSVP)? Do you foresee any
problems in saying as much in the draft?

Regards,
Gary Kenward

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Gary W. = Kenward           = ;            = ;            = gkenward@nortelnetworks.com
Advisor, Wireless = Architecture          =      (613) 765-1437
Advanced Technology = Labs           &n= bsp;          FAX: (613) = 763-2686          &nbs= p;           &nbs= p;       
Nortel Networks
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

As far as the laws of mathematics refer to reality, = they are not certain;
and as far as they are certain, they do not refer to = reality.
-- Albert Einstein



-----Original Message-----
From: Dan Grossman [mailto:dan@dma.isg.mot.com]
Sent: Monday, November 27, 2000 11:22 AM
To: karn@qualcomm.com
Cc: pilc@grc.nasa.gov
Subject: Re: Updating LINK


Phil,
The reason for the lengthy exposition was that most = people who aren't actively
involved in QoS work usually don't understand the = issues.  My view was (and
still is) that a "level set" is = needed.  Unfortunately, there is not one RFC
(and I haven't found a good single paper in the = literature) that one can point
to that has information of this nature.  =

QoS stuff is somewhat abstract, because unless one = starts at first principle,
one is likely to get it wrong.  I disagree that = "this has kept it from making
progress in the real world."  There are = other reasons, which rate a
side-discussion in San Diego but are off topic for = this list.

I don't think that the amount of exposiontion in my = proposed text is
inconsistent with the amount of exposition on, say = TCP.  There probably is
some material which could be cut back, and if you = strongly need to do that, it
could be done.  However, I really think your = current version threw out the
baby with the bathwater.  It also retained some = material that is at least
misleading if not incorrect, namely the first couple = of paragraphs.

WRT subnet designers, in addition to the tutorial = material, I think we need at
a minimum to make the following points:
 -- QoS is quantitative and measureable.  = QoS !=3D priority.
 -- Don't waste your time on QoS classes;  = use network mechanisms like RSVP to
negotiate
  -- Don't assume that just setting a few bits = in the IP header (TOS or
Diffserv) solve your QoS problems
 -- QoS guarantees require cooperating = mechanisms that play together as a
system.  Some of these are not = stateless.

I'm not able to do much on this for the next few = days.  We can talk about this
in San Diego, or if you can be specific as to how = much material you think
needs to be cut out, I can try to rework.

Dan

 




------_=_NextPart_001_01C058C3.9DDF0680-- From owner-pilc@lerc.nasa.gov Tue Dec 5 20:06:05 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00137 for ; Tue, 5 Dec 2000 20:06:05 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25557 for pilc-outgoing; Tue, 5 Dec 2000 19:10:29 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25517 for ; Tue, 5 Dec 2000 19:10:26 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14554; Tue, 5 Dec 2000 19:10:23 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014249; Tue, 5 Dec 00 19:08:21 -0500 Received: (qmail 3249 invoked by uid 0); 6 Dec 2000 00:08:03 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:08:03 +0900 (JST) Received: (qmail 6829 invoked from network); 23 Nov 2000 18:45:51 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 23 Nov 2000 18:45:51 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA10569 for pilc-outgoing; Thu, 23 Nov 2000 11:10:06 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA10561 for ; Thu, 23 Nov 2000 11:10:04 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA16077; Thu, 23 Nov 2000 11:10:03 -0500 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016007; Thu, 23 Nov 00 11:09:49 -0500 Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 13yywS-0007ZO-00; Thu, 23 Nov 2000 16:09:44 +0000 Date: Thu, 23 Nov 2000 16:09:43 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Reiner Ludwig cc: karn@qualcomm.com, pilc@grc.nasa.gov Subject: Re: Comments to "Advice for Internet Subnetwork Designers" In-Reply-To: <5.0.1.4.0.20001123152149.0244ab10@chapelle.ericsson.se> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Thu, 23 Nov 2000, Reiner Ludwig wrote: > Phil Karn wrote in replky to Reiner: > > > >>What you really want to avoid are the nasty interactions between TCP > > >>and link/physical layer retransmissions that can occur in certain link > > >>operating regions. > > > > >People often talk about those interactions as if there where so many of > > >those. What are those interactions you are talking about? > > > > >I only know of two such interactions: > > >(1) spurious timeouts that lead to a go-back-N retransmisison mode in > > TCP, and > > > >A compliant TCP never does go-back-N; it only retransmits the oldest > >unacked segment. But even this could be a spurious retransmission if the > >earlier delay was caused by a link layer retransmission. > > Please, check out section 3.1 in this paper: > http://www.acm.org/sigcomm/ccr/archive/2000/jan00/ccr-200001-ludwig.html > > A compliant TCP has no other chance but to go into go-back-N after a > spurious timeout, i.e., a spurious timeout forces TCP into the go-back-N. even with use of SACK and knowledge of the receiver window state? (Did I miss a timeout causing the SACK scoreboard to be discarded?) puzzled, L. PGP From owner-pilc@lerc.nasa.gov Tue Dec 5 20:06:11 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00166 for ; Tue, 5 Dec 2000 20:06:11 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25556 for pilc-outgoing; Tue, 5 Dec 2000 19:10:29 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25513 for ; Tue, 5 Dec 2000 19:10:24 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14543; Tue, 5 Dec 2000 19:10:23 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014420; Tue, 5 Dec 00 19:09:28 -0500 Received: (qmail 3912 invoked by uid 0); 6 Dec 2000 00:08:44 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:08:44 +0900 (JST) Received: (qmail 2331 invoked from network); 29 Nov 2000 00:07:49 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 29 Nov 2000 00:07:49 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA26279 for pilc-outgoing; Tue, 28 Nov 2000 16:24:55 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA26257 for ; Tue, 28 Nov 2000 16:24:53 -0500 (EST) From: afalk@PanAmSat.com Received: by seraph3.lerc.nasa.gov; id QAA07564; Tue, 28 Nov 2000 16:24:53 -0500 Received: from unknown(208.217.183.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma007510; Tue, 28 Nov 00 16:23:55 -0500 Received: by atlconn1.panamsat.com with Internet Mail Service (5.5.2650.10) id ; Tue, 28 Nov 2000 16:23:54 -0500 Message-ID: <0703A3E1D430D411866100508BDFCF33191907@CTOEXCH1> To: agenda@ietf.org, pilc@grc.nasa.gov Cc: mankin@east.isi.edu, spencer.dawkins@fnc.fujitsu.com Subject: PILC working group meeting agenda Date: Tue, 28 Nov 2000 16:22:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Here's the agenda for our meeting in San Diego. Note that we are scheduled to start at 9am on Friday, December 15th. See http://www.ietf.org/meetings/IETF-49.html for more information on the IETF meeting. Please read the updated drafts *before* you come to the meeting. Hope to see you all there. --aaron ---------------------------------------------------------------------------- ------------------------------------------------------------- Performance Implications of Link Characteristics (PILC) MEETING AGENDA - Agenda-bashing (Falk/Dawkins) - Working Group Status (Falk/Dawkins) - Update on TCP over Asymmetric Links (ASYM) (Falk) - Update on TCP over Wireless doc (Falk) - Update on Performance Enhancing Proxies (PEP) doc (Border/Kojo) - Update on Advice for Internet Subnetwork Designers (LINK) doc (Karn) - Discussion on Reliable Link Layer summary (Karn for Fairhurst) From owner-pilc@lerc.nasa.gov Tue Dec 5 20:06:28 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00212 for ; Tue, 5 Dec 2000 20:06:28 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25630 for pilc-outgoing; Tue, 5 Dec 2000 19:10:46 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25597 for ; Tue, 5 Dec 2000 19:10:43 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14625; Tue, 5 Dec 2000 19:10:41 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014497; Tue, 5 Dec 00 19:10:10 -0500 Received: (qmail 4417 invoked by uid 0); 6 Dec 2000 00:09:18 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:09:18 +0900 (JST) Received: (qmail 6483 invoked from network); 1 Dec 2000 13:35:57 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 1 Dec 2000 13:35:57 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA06165 for pilc-outgoing; Fri, 1 Dec 2000 06:33:57 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id GAA06145 for ; Fri, 1 Dec 2000 06:33:55 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA18564; Fri, 1 Dec 2000 06:33:54 -0500 Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.5) id xma018529; Fri, 1 Dec 00 06:33:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25827; Fri, 1 Dec 2000 06:33:03 -0500 (EST) Message-Id: <200012011133.GAA25827@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pilc@grc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pilc-slow-05.txt Date: Fri, 01 Dec 2000 06:33:02 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF. Title : End-to-end Performance Implications of Slow Links Author(s) : S. Dawkins, G. Montenegro, M. Kojo, V. Magret Filename : draft-ietf-pilc-slow-05.txt Pages : 16 Date : 30-Nov-00 This document makes performance-related recommendations for users of network paths that traverse 'very low bit-rate' links. 'Very low bit-rate' implies 'slower than we would like'. This recommendation may be useful in any network where hosts can saturate available bandwidth, but the design space for this recommendation explicitly includes connections that traverse 56 Kb/second modem links or 4.8 Kb/second wireless access links - both of which are widely deployed. This document discusses general-purpose mechanisms. Where application-specific mechanisms can outperform the relevant general-purpose mechanism, we point this out and explain why. This document has some recommendations in common with RFC 2689, 'Providing integrated services over low-bitrate links', especially in areas like header compression. This document focuses more on traditional data applications for which 'best-effort delivery' is appropriate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-slow-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pilc-slow-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-slow-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001130115230.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-slow-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-slow-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130115230.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Tue Dec 5 20:06:34 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00239 for ; Tue, 5 Dec 2000 20:06:33 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25563 for pilc-outgoing; Tue, 5 Dec 2000 19:10:30 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25515 for ; Tue, 5 Dec 2000 19:10:25 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14551; Tue, 5 Dec 2000 19:10:23 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014245; Tue, 5 Dec 00 19:08:13 -0500 Received: (qmail 3162 invoked by uid 0); 6 Dec 2000 00:07:57 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:07:57 +0900 (JST) Received: (qmail 6143 invoked from network); 23 Nov 2000 15:38:49 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 23 Nov 2000 15:38:49 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA03016 for pilc-outgoing; Thu, 23 Nov 2000 08:04:42 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id IAA03007 for ; Thu, 23 Nov 2000 08:04:40 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA02089; Thu, 23 Nov 2000 08:04:39 -0500 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002060; Thu, 23 Nov 00 08:04:29 -0500 Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 13yw38-0005sj-00; Thu, 23 Nov 2000 13:04:26 +0000 Date: Thu, 23 Nov 2000 13:04:25 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: karn@qualcomm.com cc: PILC mailing list Subject: Re: Comments to "Advice for Internet Subnetwork Designers" In-Reply-To: <200011230045.QAA17520@patty.ka9q.net> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Wed, 22 Nov 2000, Phil Karn wrote: > >(2) out-of-order delivery at the link layer that falsely triggers fast > >retransmit / fast recovery. > > I think this is not as significant a problem in practice, since most > link layers already enforce packet ordering. That's not what Bennett and Partridge observed in the backbone: J.C. Bennett, C. Partridge, and N. Schectman, Packet Reordering is Not Pathological Network Behaviour, IEEE/ACM Transactions on Networking, 7(6), pp. 789-798, 2000. > Transport protocols can compensate for many subnetwork and Internet > ills, including packet loss, duplication and reordering. But high > delay is one subnetwork ill that a transport protocol can *never* > overcome. That's why I think any low-level mechanism that > deliberately introduces delay should be viewed with great skepticism. ...including highly-persistent ARQ. > This also leads to the conclusion that if packet reordering spuriously > triggers TCP's dup ack mechanism, then this is really TCP's fault and > it should be fixed inside TCP. (I didn't say this would be easy, though.) Yes - and tweaking the dupack threshold is being examined by a few people. L. PGP From owner-pilc@lerc.nasa.gov Tue Dec 5 20:06:53 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00281 for ; Tue, 5 Dec 2000 20:06:52 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25553 for pilc-outgoing; Tue, 5 Dec 2000 19:10:29 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25512 for ; Tue, 5 Dec 2000 19:10:24 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14548; Tue, 5 Dec 2000 19:10:23 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014244; Tue, 5 Dec 00 19:08:13 -0500 Received: (qmail 3169 invoked by uid 0); 6 Dec 2000 00:07:57 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:07:57 +0900 (JST) Received: (qmail 6217 invoked from network); 23 Nov 2000 16:31:40 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 23 Nov 2000 16:31:40 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA04742 for pilc-outgoing; Thu, 23 Nov 2000 08:50:53 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id IAA04733 for ; Thu, 23 Nov 2000 08:50:52 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA05371; Thu, 23 Nov 2000 08:50:52 -0500 Received: from diesel.erg.abdn.ac.uk(139.133.204.76) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005342; Thu, 23 Nov 00 08:50:14 -0500 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.11.1/8.11.1) with ESMTP id eANDo4729249; Thu, 23 Nov 2000 13:50:04 GMT Message-ID: <3A1D208B.CD3E8FAA@erg.abdn.ac.uk> Date: Thu, 23 Nov 2000 13:50:05 +0000 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.73C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: karn@qualcomm.com CC: Reiner.Ludwig@ericsson.com, pilc@grc.nasa.gov Subject: Re: Comments to "Advice for Internet Subnetwork Designers" References: < <5E5172B4DE05D311B3AB0008C75DA941019EF683@edeacnt100.eed.ericsson.se> <5E5172B4DE05D311B3AB0008C75DA941019EF683@edeacnt100.eed.ericsson.se> <4.3.2.7.0.20000801115412.00b847e0@chapelle.ericsson.se> <200011230045.QAA17520@patty.ka9q.net> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit See also: draft-ietf-pilc-link-arq-issues-00.txt Phil Karn wrote: > Going back to some mail of yours from early August, I've been giving > your comments a lot of thought, and I have to admit I'm moving closer > to your point of view on some things. > > >>What you really want to avoid are the nasty interactions between TCP > >>and link/physical layer retransmissions that can occur in certain link > >>operating regions. > > >People often talk about those interactions as if there where so many of > >those. What are those interactions you are talking about? > > >I only know of two such interactions: > >(1) spurious timeouts that lead to a go-back-N retransmisison mode in TCP, and > > A compliant TCP never does go-back-N; it only retransmits the oldest > unacked segment. But even this could be a spurious retransmission if the earlier > delay was caused by a link layer retransmission. > > >(2) out-of-order delivery at the link layer that falsely triggers fast > >retransmit / fast recovery. > > I think this is not as significant a problem in practice, since most > link layers already enforce packet ordering. > > >Given that PILC recommends that link layers should avoid out-of-order > >delivery (also for the sake of not causing trouble for TCP/IP header > >compression) this leaves spurious timeouts as the cardinal problem. > > But now I'm no longer sure that ordered delivery at the link level is > even a good thing. > > The basic problem is that ordered delivery can only be done by > intentionally delaying any packets that would otherwise be delivered > out of order. This is harmless or even beneficial if the delayed > packets belong to the same TCP connection. But if they don't, then > you merely impair the performance of the other connection(s) with no > compensating benefit. I thought PILC recommended PER-FLOW ordering. This may in many protocols be implemented as PER-LINK or per-host-pair-of-IP-addresses, but these are design decisions taken during the link implementation. There are cases for out-of-order delivery between flows. Low persistency may also reduce the head-of-line link reciever blocking which you mention. > (True, the link *could* peek at the TCP and IP > headers and only enforce in-order delivery of packets belonging to the > same TCP connection, but that would be an egregious layer violation -- > i.e., it wouldn't work with IPSEC). > > I believe this is much the same reasoning that originally led to the > Internet architects to say that IP need not deliver packets in > sequence, that reordering is a transport layer responsibility. > > Transport protocols can compensate for many subnetwork and Internet > ills, including packet loss, duplication and reordering. But high > delay is one subnetwork ill that a transport protocol can *never* > overcome. That's why I think any low-level mechanism that > deliberately introduces delay should be viewed with great skepticism. > > This also leads to the conclusion that if packet reordering spuriously > triggers TCP's dup ack mechanism, then this is really TCP's fault and > it should be fixed inside TCP. (I didn't say this would be easy, though.) That is re-ordering within a flow - I think you mean. > > This leaves one remaining argument for ordered delivery on links: VJ > header compression. So we could simply say that in-order delivery is > important only if you plan to implement VJ header compression. V-J isn't recommended with lossey links.... There are more arguments for low link delay in: draft-ietf-pilc-link-arq-issues-00.txt > > Anyway, back to retransmission interactions. > > >>But whenever the link layer retransmits, the RTT spikes > >>and there's a spurious TCP retransmission. > > >This is a simply not true. You have to let things go really bad to force a > >spurious timeout in TCP. Depending on your path characteristics especially > > You say it's rare, but it is something I've seen quite often in TCP > traces. I think this difference is simply due to our having operated > over different environments. Our air links tend to have relatively > high latencies even without link level retransmissions, and more > significantly this latency tends to dominate that of the total > Internet path. So we probably see many more cases of spurious TCP > retransmissions being triggered by link retransmissions than you do. > > Also, our link protocols have historically been implemented in cell > phones with severely limited memory resources, and this has led us to > implement non-persistent link ARQ schemes that don't require a lot of > buffer memory. Of course, this problem is going away over time. > > But perhaps you're right that, overall, it's better to not limit the > persistence of the link layer ARQ scheme. Fair queuing might help > limit the effect of the spurious retransmissions on other competing > flows, for example. Also, having a highly persistent link layer ARQ > might be the best way to help TCP recover quickly from sustained link > outages. FQ helps at the input to the link-ARQ, it can't help if the link propagation delay is high and there are frames under-going error recovery. > > > Phil Gorry ------------------------------ http://www.erg.abdn.ac.uk/users/gorry From owner-pilc@lerc.nasa.gov Tue Dec 5 20:08:27 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00501 for ; Tue, 5 Dec 2000 20:08:26 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25358 for pilc-outgoing; Tue, 5 Dec 2000 19:09:24 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25312 for ; Tue, 5 Dec 2000 19:09:21 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14349; Tue, 5 Dec 2000 19:09:19 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014274; Tue, 5 Dec 00 19:08:50 -0500 Received: (qmail 3433 invoked by uid 0); 6 Dec 2000 00:08:15 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:08:15 +0900 (JST) Received: (qmail 7742 invoked from network); 24 Nov 2000 10:26:07 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 24 Nov 2000 10:26:07 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA00212 for pilc-outgoing; Fri, 24 Nov 2000 02:44:48 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id CAA00179 for ; Fri, 24 Nov 2000 02:44:44 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id CAA20218; Fri, 24 Nov 2000 02:44:44 -0500 Received: from 24-130-188-101.san.rr.com(24.130.188.101) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020180; Fri, 24 Nov 00 02:43:53 -0500 Received: (from karn@localhost) by homer.ka9q.net (8.9.3/8.9.3/Debian 8.9.3-21) id XAA19783; Thu, 23 Nov 2000 23:43:31 -0800 Date: Thu, 23 Nov 2000 23:43:31 -0800 Message-Id: <200011240743.XAA19783@homer.ka9q.net> From: Phil Karn To: L.Wood@eim.surrey.ac.uk CC: pilc@grc.nasa.gov In-reply-to: (message from Lloyd Wood on Thu, 23 Nov 2000 13:04:25 +0000 (GMT)) Subject: Re: Comments to "Advice for Internet Subnetwork Designers" Reply-to: karn@qualcomm.com References: Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >> I think this is not as significant a problem in practice, since most >> link layers already enforce packet ordering. >That's not what Bennett and Partridge observed in the backbone: Thanks for the pointer to that paper, as I wasn't aware of it. I just finished reading it. It's very good, and I recommend it to the group. I found this rather poor quality PDF copy: http://www.acm.org/pubs/articles/journals/ton/1999-7-6/p789-bennett/p789-bennett.pdf I should have been more clear in my choice of words. I was thinking of a single point-to-point link, not a collection of parallel links and/or reordering routers along a given Internet path. I think it's still correct to say that most physical links still enforce packet ordering, even if those links are frequently used in parallel and/or with switches and routers (like the DEC Gigaswitch discussed in that paper) that do frequently reorder packets. I generally agree with the paper's conclusions: reordering does happen in the real Internet and it does cause problems with TCP performance. TCP should be made more robust to reordering *and* the subnetworks should be designed to avoid it whenever possible. So how's this for a LINK recommendation: subnetworks should try to deliver packets in order when possible, but not if doing so impairs the subnetwork's capacity or increases its latency. Comments? Phil From owner-pilc@lerc.nasa.gov Tue Dec 5 20:12:38 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01016 for ; Tue, 5 Dec 2000 20:12:34 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25627 for pilc-outgoing; Tue, 5 Dec 2000 19:10:45 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25595 for ; Tue, 5 Dec 2000 19:10:42 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14619; Tue, 5 Dec 2000 19:10:40 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014495; Tue, 5 Dec 00 19:10:09 -0500 Received: (qmail 4408 invoked by uid 0); 6 Dec 2000 00:09:18 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:09:18 +0900 (JST) Received: (qmail 6464 invoked from network); 1 Dec 2000 13:32:00 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 1 Dec 2000 13:31:59 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA06162 for pilc-outgoing; Fri, 1 Dec 2000 06:33:57 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id GAA06144 for ; Fri, 1 Dec 2000 06:33:54 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA18561; Fri, 1 Dec 2000 06:33:53 -0500 Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.5) id xma018528; Fri, 1 Dec 00 06:33:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25881; Fri, 1 Dec 2000 06:33:08 -0500 (EST) Message-Id: <200012011133.GAA25881@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pilc@grc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pilc-pep-05.txt Date: Fri, 01 Dec 2000 06:33:07 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF. Title : Performance Enhancing Proxies Author(s) : J. Border, M. Kojo, J. Griner, G. Montenegro, Z. Shelby Filename : draft-ietf-pilc-pep-05.txt Pages : 45 Date : 30-Nov-00 This document provides a high level overview of Performance Enhancing Proxies. Different types of Performance Enhancing Proxies are described as well as the mechanisms used to improve performance. In addition, motivations for their development and use are described along with some the consequences of using them, especially in the context of the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-pep-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pilc-pep-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-pep-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001130115239.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-pep-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-pep-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130115239.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Tue Dec 5 20:13:41 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01139 for ; Tue, 5 Dec 2000 20:13:41 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25535 for pilc-outgoing; Tue, 5 Dec 2000 19:10:26 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25499 for ; Tue, 5 Dec 2000 19:10:23 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA14523; Tue, 5 Dec 2000 19:10:22 -0500 Received: from apc.allnet.ne.jp(210.228.3.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014248; Tue, 5 Dec 00 19:08:16 -0500 Received: (qmail 3229 invoked by uid 0); 6 Dec 2000 00:08:02 -0000 Delivered-To: yasuo@apc.gr.jp Received: from 210.228.3.3 [210.228.3.3] by localhost with POP3 (fetchmail-5.5.2) for root@localhost (single-drop); Wed, 06 Dec 2000 09:08:02 +0900 (JST) Received: (qmail 6580 invoked from network); 23 Nov 2000 17:27:12 -0000 Received: from lombok-fi.lerc.nasa.gov (139.88.112.33) by net.apc.gr.jp with SMTP; 23 Nov 2000 17:27:12 -0000 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA08232 for pilc-outgoing; Thu, 23 Nov 2000 10:17:34 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA08212 for ; Thu, 23 Nov 2000 10:17:32 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA11813; Thu, 23 Nov 2000 10:17:31 -0500 Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011789; Thu, 23 Nov 00 10:17:24 -0500 Received: from aachen.eed.ericsson.se (aachen.eed.ericsson.se [164.48.130.2]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eANFHM224564; Thu, 23 Nov 2000 16:17:22 +0100 (MET) Received: from e00d059101eba.Ericsson.com (dhcp4-117 [164.48.140.117]) by aachen.eed.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id QAA24232; Thu, 23 Nov 2000 16:17:20 +0100 (MET) Message-Id: <5.0.1.4.0.20001123152149.0244ab10@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 23 Nov 2000 16:17:19 +0100 To: karn@qualcomm.com From: Reiner Ludwig Subject: Re: Comments to "Advice for Internet Subnetwork Designers" Cc: pilc@grc.nasa.gov In-Reply-To: <200011230045.QAA17520@patty.ka9q.net> References: <4.3.2.7.0.20000801115412.00b847e0@chapelle.ericsson.se> < <5E5172B4DE05D311B3AB0008C75DA941019EF683@edeacnt100.eed.ericsson.se> <5E5172B4DE05D311B3AB0008C75DA941019EF683@edeacnt100.eed.ericsson.se> <4.3.2.7.0.20000801115412.00b847e0@chapelle.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 01:45 23.11.00, Phil Karn wrote: >Going back to some mail of yours from early August, I've been giving >your comments a lot of thought, and I have to admit I'm moving closer >to your point of view on some things. I'm glad to hear this. Ideally, we can get our views converged on this matter so that we can get this section "Reliability and Error Control" straight in the "Advice for Internet Subnetwork Designers". Maybe, we can make this a topic at the PILC meeting in San Diego. I would be happy to present my view ... if the WG chairs think that that's appropriate. > >>What you really want to avoid are the nasty interactions between TCP > >>and link/physical layer retransmissions that can occur in certain link > >>operating regions. > > >People often talk about those interactions as if there where so many of > >those. What are those interactions you are talking about? > > >I only know of two such interactions: > >(1) spurious timeouts that lead to a go-back-N retransmisison mode in > TCP, and > >A compliant TCP never does go-back-N; it only retransmits the oldest >unacked segment. But even this could be a spurious retransmission if the >earlier >delay was caused by a link layer retransmission. Please, check out section 3.1 in this paper: http://www.acm.org/sigcomm/ccr/archive/2000/jan00/ccr-200001-ludwig.html A compliant TCP has no other chance but to go into go-back-N after a spurious timeout, i.e., a spurious timeout forces TCP into the go-back-N. I have just submitted an Internet Draft to TSVWG on this matter: http://search.ietf.org/internet-drafts/draft-ludwig-tsvwg-tcp-eifel-alg-00.txt > >(2) out-of-order delivery at the link layer that falsely triggers fast > >retransmit / fast recovery. > >I think this is not as significant a problem in practice, since most >link layers already enforce packet ordering. I agree with respect to existing link layers. I'm not so sure, though, whether we should also recommend in-order delivery for future wireless links. > >Given that PILC recommends that link layers should avoid out-of-order > >delivery (also for the sake of not causing trouble for TCP/IP header > >compression) this leaves spurious timeouts as the cardinal problem. > >But now I'm no longer sure that ordered delivery at the link level is >even a good thing. > >The basic problem is that ordered delivery can only be done by >intentionally delaying any packets that would otherwise be delivered >out of order. This is harmless or even beneficial if the delayed >packets belong to the same TCP connection. But if they don't, then >you merely impair the performance of the other connection(s) with no >compensating benefit. (True, the link *could* peek at the TCP and IP >headers and only enforce in-order delivery of packets belonging to the >same TCP connection, but that would be an egregious layer violation -- >i.e., it wouldn't work with IPSEC). Again, I agree except to the layer violation concerns. I would also like to stronlgly promote clean designs, i.e., without layer violations. But to implement what I call inter-flow out-of-order delivery (as opposed to intra-flow out-of-order delivery, i.e., o-o-o delivery within a single flow), you do not need to have the link layer inspect IP headers. Instead, you could, e.g., run multiple logical link layers (one per flow) across a hop, and have IP distribute the packets onto those links based on port numbers. "one per flow" clearly does not scale, but for the first/last hop this shouldn't be a problem. Yes, as with so many things, this does not work with IPsec. >I believe this is much the same reasoning that originally led to the >Internet architects to say that IP need not deliver packets in >sequence, that reordering is a transport layer responsibility. > >Transport protocols can compensate for many subnetwork and Internet >ills, including packet loss, duplication and reordering. But high >delay is one subnetwork ill that a transport protocol can *never* >overcome. That's why I think any low-level mechanism that >deliberately introduces delay should be viewed with great skepticism. > >This also leads to the conclusion that if packet reordering spuriously >triggers TCP's dup ack mechanism, then this is really TCP's fault and >it should be fixed inside TCP. (I didn't say this would be easy, though.) The ID I mentioned above is such a fix (inside TCP). >This leaves one remaining argument for ordered delivery on links: VJ >header compression. So we could simply say that in-order delivery is >important only if you plan to implement VJ header compression. The evolved VJ header compression, RFC2507, optionally uses sequence numbers within the compressed headers to deal with links that re-order. So, this would eliminate the "one remaining argument". However, there would be no benefit in having the link layer do o-o-o delivery in this case, since now we have the header decompressor delaying the packets to bring them back into order. >Anyway, back to retransmission interactions. > > >>But whenever the link layer retransmits, the RTT spikes > >>and there's a spurious TCP retransmission. > > >This is a simply not true. You have to let things go really bad to force a > >spurious timeout in TCP. Depending on your path characteristics especially > >You say it's rare, but it is something I've seen quite often in TCP >traces. I think this difference is simply due to our having operated >over different environments. Plus, it very much depends on your TCP (timer granularity, restart of the timer after an ACK, ...). We see more spurious timeouts with LINUX for example. Still, with the current RTO calculation, spurious timeouts should be rare. >Our air links tend to have relatively >high latencies even without link level retransmissions, and more >significantly this latency tends to dominate that of the total >Internet path. So we probably see many more cases of spurious TCP >retransmissions being triggered by link retransmissions than you do. I don't know what you mean when you say "our air links", but I did quite a few measurements in GSM which certainly qualifies as high latency, and also it dominates the e2e RTT. Still, spurious timeouts were extremely rare (in BSD) and when they occured, then this was always in the beginning of the connection. This is since the RTO had not been given enough time to adapt. >Also, our link protocols have historically been implemented in cell >phones with severely limited memory resources, and this has led us to >implement non-persistent link ARQ schemes that don't require a lot of >buffer memory. Of course, this problem is going away over time. I see highly persistent LL ARQ as independent from buffer memory. When some people hear highly persistent LL ARQ, they often think that this equals "buffering for ever". *No, it does not!* The queues need to remain appropriately small also with highly persistent LL ARQ. >But perhaps you're right that, overall, it's better to not limit the >persistence of the link layer ARQ scheme. I think it should be limited to 64 seconds sicne this is TCP max. RTO. There is really no point in delaying a packet beyond that. In addition, should the system hosting the link layer get into memory problems, then this might also be a reason to drop (from front) packets before 64sec have passed. >Fair queuing might help >limit the effect of the spurious retransmissions on other competing >flows, for example. I agree, if you seperate flow classes (UDP vs. TCP) at the link layer, there needs to be some scheme in place that devides the link's bandwidth between those classes. E.g., 30% for elastic TCP traffic, the rest for delay-sensitive traffic. >Also, having a highly persistent link layer ARQ >might be the best way to help TCP recover quickly from sustained link >outages. Exactly. ///Reiner From owner-pilc@lerc.nasa.gov Sat Dec 9 14:26:50 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12639 for ; Sat, 9 Dec 2000 14:26:50 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA16874 for pilc-outgoing; Sat, 9 Dec 2000 12:58:14 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA16865 for ; Sat, 9 Dec 2000 12:58:08 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA01665; Sat, 9 Dec 2000 12:58:07 -0500 Message-Id: <200012091758.MAA01665@seraph3.lerc.nasa.gov> Received: from nt1.rocori.k12.mn.us(207.229.251.2) by seraph3.lerc.nasa.gov via smap (V5.5) id xma001631; Sat, 9 Dec 00 12:57:26 -0500 From: Mail Sender To: piewie@rocketmail.com CC: pilc@grc.nasa.gov, pim@catarina.usc.edu, pim-request@catarina.usc.edu, pindar@HK.Super.NET, Pine.GSO.3.96.971020155614.8935I-100000@cafe.berkeley.edu Subject: Russian Goods and Service from Moscow Reply-To: mailsender@mailsender.ru Date: 09.12.2000 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pilc@lerc.nasa.gov Precedence: bulk www.rusgoods.com www.rusgoods.ru ================================================================ We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes watches for the Russian Air Forces , Russian Naval Forces. All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any middlemans. The submarine "Kursk" had on board mechanical marine hronometr 6MX. =============================================================== The "table" of orders. Here you can to order, to find, to know almost everything, than the Russia is rich, everything that does not contradict Russian Federation laws. Here you can receive or order: The information about any enterprise, firm, organization, or person in Russia The production or any goods of Russian manufactories, and other things if it is possible. =============================================================== www.rusgoods.com www.rusgoods.ru From owner-pilc@lerc.nasa.gov Tue Dec 12 16:06:40 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10197 for ; Tue, 12 Dec 2000 16:06:40 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA14116 for pilc-outgoing; Tue, 12 Dec 2000 14:31:59 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA14089 for ; Tue, 12 Dec 2000 14:31:56 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA03718; Tue, 12 Dec 2000 14:31:55 -0500 Received: from diesel.erg.abdn.ac.uk(139.133.204.76) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003655; Tue, 12 Dec 00 14:31:43 -0500 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.11.1/8.11.1) with ESMTP id eBCJVPM29651 for ; Tue, 12 Dec 2000 19:31:29 GMT Message-ID: <3A367D0F.1D7F3D5D@erg.abdn.ac.uk> Date: Tue, 12 Dec 2000 19:31:25 +0000 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.73C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: pilc Subject: [Fwd: comments on draft-pilc-link-arq-issues-00 : MAC issues] Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id eBCJVPM29651 X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id OAA14104 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by lombok-fi.lerc.nasa.gov id OAA14116 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA10197 I enclose a mail thread originating from Gary Kenward which comments on the link-ARQ draft (Gary didn’t originally copy the list in on this, but has subsequently agreed to me sending it). The emails discus issues relating to the way in which persistency is used in the MAC world. At first glance, this may appear an orthogonal issue to link ARQ, but there is some interesting overlap of issues and jargon... ================================================================== Gary Kenward wrote: I have two comments on the draft draft-pilc-link-arq-issues-00: 1. Under Section 2, ARQ Persistence, the second paragraph attempts to define "retransmission persistence". There are many dimensions to persistence at the link layer, and I feel the current description is not clear enough. From an ARQ perspective, there is not only the duration of repeated attempts, but also the frequency and priority of the attempts. The reason I was initially confused by the text is that I am more familiar with the definition of persistence as used with stochastic contention resolution protocols such as CSMA; e.g. p-persistent CSMA refers to the probability that a retransmission will be attempted within a certain time period. Perhaps this is too much detail for a draft of this scope, however, given that the concept of persistence is used throughout the draft, it should be defined more crisply, and, the definition should be complete. 2. In the subsections 2.n, you characterize different types of persistence as a trade off between delay and reliability. Again, frequency and priority of repeats must be accounted for in your taxonomy. However, I also wanted to point out that the reason many protocols, including Ethernet, use a finite number of repeated transfer attempts (or retransmissions in Ethernet) is to ensure *stability* of the channel. An ARQ protocol with an infinite number of repeated attempts is generally unstable. A finite number of retransmissions does not necessarily ensure stability. I do not have the references at hand (I could probably find them if you are interested), but for a finite population size, stability bounds on the number of repeats have been derived for particular protocols (e.g. CSMA, ALOHA, S-CSMA, S-ALOHA). I hope these comments help. If I have missed something, I would happy to know it. Gary Kenward ================================================================== Gorry Fairhurst wrote: It is interesting that you raise the issue of persistence within MAC protocols as well as within link ARQ protocols. I guess this is a much more common usage of the word - but I'm not quite sure the two uses are exactly the same. In ARQ it describes the giving up of reliability (as a trade off with maximum delay) - at least that is how I believe we meant to use it in the document. In MAC protocols, the giving up may be for the same reason - because the end-point address simply doesn't exist (or may not be reached) - but also with back-off to control congestion within the MAC domain, as you describe. If you think there are common issues, I'd be interested in further email - or if you'd like to suggest a "tuned" definition which covers both (or a note to clarify things?) Gorry ================================================================== I understand you perspective better now. I do not want to suggest that MAC layer design issues be included into the document. It was my intent only to identify a need to clarify the language, for the reasons I outlined in my email. The first issue was whether, at the Link layer, the definition of persistency is sufficient. In re-reading the second paragraph of section 2, I realise that you have equated the retransmission timeout to be the expected round trip delay (packet transmission to ack/nack receipt delay). If this is the case, then the "persistence" as you describe it is given by either the maximum number of attempts allowed, or the total duration of all attempts. However, in many packet radio systems the delay between attempts is greater then the round trip delay, and frequently increasing in duration. This is done for reasons similar to having increasing backoffs in CSMA - to decrease the offered channel load in the presence of impairments to transmission that may persist for an extended duration. In CSMA the channel impairment is congestion that results in a high probability of collisions. In a wireless channel, for example, a mobile may be experiencing poor coverage due to fading, shadowing or interference: in this situation, it is wasteful to consume bandwidth by re-transmitting to the wireless terminal. One simple solution is to delay retransmissions in the hope that the channel conditions will improve. Thus, the "persistence" of the ARQ is characterized by the delay between attempts, as well as the number of attempts. If you agree to this generalization of the definition, then I will be happy to write up some text. Also, in paragraph 3, section 2, the reference to Ethernet introduces some confusion (for me, at least, this is where the confusion with persistent media access protocols was introduced). Clearly, Ethernet is both a MAC and Link protocol, but it is my understanding that the retransmission algorithm of Ethernet was defined to compensate for collisions on a CSMA channel. In the theoretical definition of CSMA, busy periods and channel collisions are treated as identical events, and both cause a retransmission to be scheduled; both are non-persistent. Regards, Gary ================================================================== Gary Kenward wrote: I *think* the issue can be kept general. We need an English language, IP centric description of an algorithm that makes repeated attempts to transfer a copy of a given IP packet while keep the actual link layer mechanisms abstract. The number of attempts and the delay between attempts I believe can be covered by expanding the description of "persistence" in your i-d. However, this expanded definition would have to be propagated into the subsequent sections where you describe the various trade offs. The use of p-persistence, adaptive FEC (e.g. hybrid ARQ), power control, etc. etc. at the MAC layer might be abstracted as the "tenacity" of each transfer attempt (or maybe I go to far with the anthropomorphism). To be more specific then this would probably go to far into link layer technology, and it would be a huge effort to attempt to describe the trade-offs. So perhaps an abstract definition with a few examples will have to suffice. Are there any more attributes of ARQ protocols that might be described? Nothing comes to mind at the moment. Gary ======== Gary W. Kenward gkenward@nortelnetworks.com Advisor, Wireless Architecture (613) 765-1437 Advanced Technology Labs Wireless Solutions FAX: (613) 763-2686 Nortel Networks From owner-pilc@lerc.nasa.gov Wed Dec 13 12:39:11 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18255 for ; Wed, 13 Dec 2000 12:39:11 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA19732 for pilc-outgoing; Wed, 13 Dec 2000 11:07:08 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA19627 for ; Wed, 13 Dec 2000 11:07:06 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA21792; Wed, 13 Dec 2000 11:06:57 -0500 Received: from smtp2.cluster.oleane.net(195.25.12.17) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021581; Wed, 13 Dec 00 11:06:31 -0500 Received: from oleane (dyn-1-1-140.Vin.dialup.oleane.fr [195.25.4.140]) by smtp2.cluster.oleane.net with SMTP id eBDG66M22147 for ; Wed, 13 Dec 2000 17:06:06 +0100 (CET) Message-ID: <00ab01c0651e$e4e040a0$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: IPCn 2001: Call for proposals Date: Wed, 13 Dec 2000 17:08:12 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A8_01C06527.462602C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00A8_01C06527.462602C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 Building and designing IP cellular networks is still a challenge and = drain a lot of research and developpement activities by industry and = academic research laboratories. The IP-Based Cellular Networks = conference (IPCN 2001) will provide a state of the art of the current = research and developpement progress and will present an overview of the = current IETF and 3GPP activities in this area.=20 A call for proposals is online at: http://www.upperside.fr/baipcn2001.htm ------=_NextPart_000_00A8_01C06527.462602C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
Building and designing IP = cellular=20 networks is still a challenge and drain a lot of research and=20 developpement activities by industry and academic research laboratories. = The=20 IP-Based Cellular Networks conference (IPCN 2001) will = provide=20 a state of the art of the current research and developpement progress = and will=20 present an overview of the current IETF and 3GPP = activities in=20 this area.

A call for proposals is online at:
http://www.upperside.fr/b= aipcn2001.htm
 
------=_NextPart_000_00A8_01C06527.462602C0-- From owner-pilc@lerc.nasa.gov Tue Dec 19 16:58:01 2000 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25980 for ; Tue, 19 Dec 2000 16:58:01 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA10771 for pilc-outgoing; Tue, 19 Dec 2000 15:28:59 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA10742 for ; Tue, 19 Dec 2000 15:28:56 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA18029; Tue, 19 Dec 2000 15:28:55 -0500 Received: from 24-130-188-101.san.rr.com(24.130.188.101) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017969; Tue, 19 Dec 00 15:28:39 -0500 Received: (from karn@localhost) by homer.ka9q.net (8.11.1/8.11.1/ka9q 8.11.1) id eBJKSaQ16463; Tue, 19 Dec 2000 12:28:36 -0800 Date: Tue, 19 Dec 2000 12:28:36 -0800 Message-Id: <200012192028.eBJKSaQ16463@homer.ka9q.net> From: Phil Karn To: nichols@packetdesign.com CC: pilc@grc.nasa.gov In-reply-to: <3A3FC2C4.717006CC@packetdesign.com> (message from Kathleen Nichols on Tue, 19 Dec 2000 12:19:16 -0800) Subject: Re: TOS byte definition is not "unclear" Reply-to: karn@qualcomm.com References: <3A3FC2C4.717006CC@packetdesign.com> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Thanks. I'll make the appropriate changes. Phil From owner-pilc@lerc.nasa.gov Tue Dec 19 16:58:08 2000 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25991 for ; Tue, 19 Dec 2000 16:58:07 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA09083 for pilc-outgoing; Tue, 19 Dec 2000 15:19:29 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA09026 for ; Tue, 19 Dec 2000 15:19:22 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA16574; Tue, 19 Dec 2000 15:19:21 -0500 Received: from dns.packetdesign.net(216.15.46.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016449; Tue, 19 Dec 00 15:19:08 -0500 Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id eBJKJ5Q30609; Tue, 19 Dec 2000 12:19:05 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A3FC2C4.717006CC@packetdesign.com> Date: Tue, 19 Dec 2000 12:19:16 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: pilc@grc.nasa.gov, karn@ka9q.net Subject: TOS byte definition is not "unclear" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit As I said in the IETF meeting last week, the current status of the TOS byte is not at all unclear. RFC 2780 quotes RFC 2474 and notes: "4.2 IPv4 Type of Service field The Type of Service field described in [V4] has been superseded[DIFF] by the 6-bit Differentiated Services (DS) field and a 2-bit field which is currently reserved. The IANA allocates values in the DS field following the IANA Considerations section in [DIFF]. [ECN] describes an experimental use of the 2-bit "currently unused" field. Other experimental uses of this field may be assigned after IESG Approval processes. Permanent values in this field are allocated following a Standards Action process." My understanding is that the 2-bit CU field is possibly being assigned to ECN. I would suggest checking with the transport ADs. There certainly ARE open questions in building services in a diffserv architecture, though there are also some clear uses of diffserv currently. In addition, the flexibility of the "EXP/LU" codepoints in the DS field allow for a range of uses. Kathie From owner-pilc@lerc.nasa.gov Tue Dec 19 17:20:03 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26265 for ; Tue, 19 Dec 2000 17:20:02 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA17954 for pilc-outgoing; Tue, 19 Dec 2000 16:15:41 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA17928 for ; Tue, 19 Dec 2000 16:15:38 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA24828; Tue, 19 Dec 2000 16:15:37 -0500 Received: from motgate2.mot.com(136.182.1.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024763; Tue, 19 Dec 00 16:15:12 -0500 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA23473 for ; Tue, 19 Dec 2000 14:15:10 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id OAA11795 for ; Tue, 19 Dec 2000 14:12:02 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id QAA04475; Tue, 19 Dec 2000 16:15:08 -0500 (EST) Message-Id: <200012192115.QAA04475@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Kathleen Nichols cc: pilc@grc.nasa.gov, karn@ka9q.net Subject: Re: TOS byte definition is not "unclear" In-reply-to: Your message of "Tue, 19 Dec 2000 12:19:16 EST." <3A3FC2C4.717006CC@packetdesign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Dec 2000 16:15:04 -0500 From: Dan Grossman Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > > As I said in the IETF meeting last week, the current status of > the TOS byte is not at all unclear. RFC 2780 quotes RFC 2474 and notes: > > "4.2 IPv4 Type of Service field > > The Type of Service field described in [V4] has been superseded[DIFF] > by the 6-bit Differentiated Services (DS) field and a 2-bit field > which is currently reserved. The IANA allocates values in the DS > field following the IANA Considerations section in [DIFF]. [ECN] > describes an experimental use of the 2-bit "currently unused" field. > Other experimental uses of this field may be assigned after IESG > Approval processes. Permanent values in this field are allocated > following a Standards Action process." > > My understanding is that the 2-bit CU field is possibly being assigned > to ECN. I would suggest checking with the transport ADs. There was concensus in the transport area meeting to progress ECN to "Proposed". > > There certainly ARE open questions in building services in a diffserv > architecture, though there are also some clear uses of diffserv > currently. In addition, the flexibility of the "EXP/LU" codepoints > in the DS field allow for a range of uses. Which is of marginal relevance to PILC. I think that I was given an assignment to re-do this section (again). The points to be made were: - that QoS for IP is not mature; ref. RFC 2990. - we have two architectures, Intserv (ref RFC 1633) and Diffserv (ref RFC 2475). A few words about each, and also mention that RFC2990 envisions intserv over diffserv as a possible unified approach - however we get there, L2 forwarding needs to be able to be "clued" by the L3 service (in case of Intserv) or PHB (in case of Diffserv). Now, if the group wants, the text I will draft could talk more about mechanisms, including the DS field. But if I do that, it will also have to get into MF classifiers, BA classifiers, RSVP, flowspecs, policy, traffic conditioning, scheduling, discarding and queueing. It would very specifically have to say that the DSField is usable by PILC ONLY when the link is inside a DS-domain (either in an interior node or inside the classifier block of a DS-ingress node) and ONLY to the extent that the link behavior contributes to the defined per-hop behavior associated with the DSCP. With emphasis that a PHB is **NOT!*** an end-to-end service. And that outside a DS-domain, an equivalent of MF classification serves to map flows to L2 forwarding behavior. But in any event, the existing text is not only wrong, but also a non-sequitir. > > Kathie Dan From owner-pilc@lerc.nasa.gov Thu Dec 21 06:59:19 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15323 for ; Thu, 21 Dec 2000 06:59:18 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA08345 for pilc-outgoing; Thu, 21 Dec 2000 05:54:13 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id FAA08315 for ; Thu, 21 Dec 2000 05:54:11 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id FAA08367; Thu, 21 Dec 2000 05:54:10 -0500 Received: from porsta.cs.helsinki.fi(128.214.48.124) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008300; Thu, 21 Dec 00 05:53:40 -0500 Received: from localhost (root@porsta.cs.Helsinki.FI [128.214.48.124]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with ESMTP id MAA16633; Thu, 21 Dec 2000 12:53:38 +0200 Date: Thu, 21 Dec 2000 12:53:38 +0200 (EET) From: Andrei Gurtov To: pilc@grc.nasa.gov, tsvwg@ietf.org Subject: yet another TCP thesis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Hello! Reiner and others have pointed out that slow wireless links are often heavily overbuffered, but not so much work have been done to determine an optimal buffer size and/or determine appropriate parameters for RED in the last-hop buffer. Matthew have mentioned the problem of the slow-start overshot in the FACK paper and suggested the overdumping algorithm to prevent it. There can be other ways also. BSD-clone OSes have been a long time a de-facto standard for TCP research. However, currently also the upcoming Linux kernel 2.4 can be used for serious TCP research. BSD has somewhat deteriorated from past "high-conformance" standards: for example FreeBSD-latest have no slow start in the same subnetwork that doesn't look very nice over a dial-up PPP link. A master thesis "TCP performance at the presence of congestion and corruption losses" available at http://www.cs.Helsinki.FI/research/iwtcp/papers/ addresses these issues and evaluation of the effect of the increased initial window, reduced receiver window, new reno and sack on TCP over an emulated wireless link. Comments? Andrei From owner-pilc@lerc.nasa.gov Fri Dec 22 11:41:48 2000 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06908 for ; Fri, 22 Dec 2000 11:41:47 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA26617 for pilc-outgoing; Fri, 22 Dec 2000 10:27:12 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA26572 for ; Fri, 22 Dec 2000 10:27:10 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA00607; Fri, 22 Dec 2000 10:27:08 -0500 Received: from e1.ny.us.ibm.com(32.97.182.101) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000531; Fri, 22 Dec 00 10:26:37 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA26804 for ; Fri, 22 Dec 2000 10:25:43 -0500 Received: from d01ml233.pok.ibm.com (d01ml233.pok.ibm.com [9.117.200.63]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id KAA35104 for ; Fri, 22 Dec 2000 10:24:18 -0500 Importance: Normal Subject: CFP - ACM MobiHoc 2001 To: end2end-interest@ISI.EDU X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Young-bae Ko" Date: Fri, 22 Dec 2000 10:26:25 -0500 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.6 |December 14, 2000) at 12/22/2000 10:26:26 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Call for Papers MobiHoc 2001 ============ The ACM Symposium on Mobile Ad Hoc Networking & Computing October 4-5, 2001, Long Beach, California, USA http://www.cs.ucla.edu/mobihoc/ sponsored by ACM SIGMOBILE MobiHoc 2001 will serve as a forum for addressing various issues related to mobile ad hoc networks. Following the success of MobiHoc 2000, MobiHoc 2001 has been expanded to a 2-day symposium, to provide more opportunities for participation by the ad hoc networking community. Technical papers describing original, previously unpublished research, not currently under review by another conference or journal, are solicited. Topics of interest include but are not limited to - * Routing protocols (unicast, multicast, geocast, content-based, etc.) for ad hoc networks * Media access techniques * Transport layer issues for ad hoc networks * Mobile ad hoc computing platforms and testbeds * Applications for ad hoc networks * Low power and energy-efficient designs * Quality-of-service issues * Security and fault-tolerance issues for ad hoc networks * Self-configuration in ad hoc networks * Sensor and data fusion * Ad hoc networking over Bluetooth * Distributed algorithms for ad hoc networks (e.g., leader election, group management, etc.) * Biologically-inspired mechanisms for ad hoc networks Please consult the program co-chairs, M. Scott Corson (corson@flarion.com), and Samir Das (samir.das@uc.edu) if you are uncertain whether your paper falls within the scope of the symposium. ----------------------------------------------------------- SUBMISSIONS Authors should prepare a postscript or portable document format (PDF) version of their papers. Papers should not exceed 20 double-spaced pages (including text, figures and references). Paper submissions will be handled electronically and exact submission instructions will appear in the symposium web site in due time. All papers will be reviewed for technical merit. Accepted papers will be published in the symposium proceedings. Important Dates - Paper Submissions Due: May 15, 2001 - Notification of Acceptance: July 15, 2001 - Camera-ready Version Due: August 1, 2001 ----------------------------------------------------------- ORGANIZING COMMITTEE * General Chair: Nitin H. Vaidya (Texas A&M University) * Technical Program Co-Chairs: M. Scott Corson (Flarion Technologies) Samir R. Das (University of Cincinnati) * European Liaison: Jean-Pierre Hubaux (Swiss Federal Inst. of Tech.) * Local Arrangements Chair: Srikanth Krishnamurthy (UC-Riverside) * Finance Co-Chairs: Stefano Basagni (UT-Dallas) Violet R. Syrotiuk (UT-Dallas) * Publicity Co-Chairs: Young-Bae Ko (IBM T.J. Watson Research) Songwu Lu (UC-Los Angeles) * Publication Chair: Sung-Ju Lee (Hewlett-Packard Labs) * Registration Chair: John Heidemann (ISI-USC) Katia Obraczka (ISI-USC) * Steering Committee: Andrew Campbell (Columbia University) J.J. Garcia-Luna-Aceves (UC-Santa Cruz) Mario Gerla (UC-Los Angeles) Joseph P. Macker (NRL) Charles E. Perkins (Nokia Research) Ram Ramanathan (BBN Tech.) Martha Steenstrup (BBN Tech.) C-K. Toh (Georgia Tech.) Nitin H. Vaidya (Texas A&M University) * Technical Program Committee: Dennis Baker (NRL) Pravin Bhagwat (AT&T Research) Andrew Campbell (Columbia University) Anthony Ephremides (University of Maryland) J.J. Garcia-Luna-Aceves (UC-Santa Cruz) Ramesh Govindan (USC/ISI) Phillippe Jacquet (INRIA) David B. Johnson (Rice University) Tony Larsson (Ericsson Research) Joe Macker (NRL) David Maltz (CMU) Gyorgy Miklos (Ericsson Research) Richard Ogier (SRI) Vincent Park (NRL) Charles E. Perkins (Nokia Research) Amir Qayyum (INRIA) Ram Ramanathan (BBN Tech.) Andras Racz (Ericsson Research) Jason Redi (BBN Tech.) Elizabeth Royer (UC-Santa Barbara) Martha Steenstrup (BBN Tech.) Leandros Tassiulas (University of Maryland) Fred Templin (SRI) ------------------------------------------------------------ From owner-pilc@lerc.nasa.gov Fri Dec 22 15:21:27 2000 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13298 for ; Fri, 22 Dec 2000 15:21:27 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA21045 for pilc-outgoing; Fri, 22 Dec 2000 13:35:15 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA21025 for ; Fri, 22 Dec 2000 13:35:13 -0500 (EST) From: Marie-Jose.Montpetit@nokia.com Received: by seraph3.lerc.nasa.gov; id NAA25498; Fri, 22 Dec 2000 13:35:12 -0500 Received: from mgw-dax2.ext.nokia.com(63.78.179.217) by seraph3.lerc.nasa.gov via smap (V5.5) id xma025477; Fri, 22 Dec 00 13:35:06 -0500 Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eBMIZs606281 for ; Fri, 22 Dec 2000 12:35:54 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 22 Dec 2000 12:35:04 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Fri, 22 Dec 2000 12:30:26 -0600 Message-ID: To: pilc@grc.nasa.gov Subject: CFP - Baltzer/ACM Journal of Mobile Networks and Applications Date: Fri, 22 Dec 2000 12:26:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id NAA21030 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by lombok-fi.lerc.nasa.gov id NAA21045 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA13298 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ************************************************************** CALL FOR PAPERS ************************************************************** Baltzer/ACM Journal of Mobile Networks and Applications (MONET) Special Issue on "QUALITY OF SERVICE IN HETEROGENEOUS WIRELESS NETWORKS" "Anywhere, anytime, anymedia" has typically been the utopian objective for networking researchers in the past. While, the significant advances in current day communication technologies are transforming that utopia into a reality, some challenges still remain. Supporting efficient Quality of Service (QoS) in wireless networks is one of them. Wireless networks span a wide variety of systems ranging from wireless LANs, and PCS systems, to satellite networks, ad hoc networks, and 3G and 4G wireless networks. Supporting QoS in such heterogeneous environments turns out to be a challenging task because of the unique characteristics of wireless networks, including user mobility, dynamic topologies, unreliability of wireless links, and scarcity of resources. This special issue focuses on new research contributions in the area of quality of service in heterogeneous wireless networks. We solicit papers with original solutions enabling QoS in wireless networks. Topics of interest include (but are not limited to) the following areas in the context of wireless networks: o Medium Access Control Protocols. o Error Control Protocols. o QoS Routing. o Fault Tolerant Routing. o Dynamic Network Infrastructures. o QoS and Power Efficiency. o QoS in Mobile IP. o Transport Protocols. o Middleware Solutions for QoS. o Network Architectures. o Mobility Management. o Performance Analysis Tools. Manuscript Submission Date: June 1, 2001 Acceptance Notification: October 5, 2001 Final Manuscript Due: December 7, 2001 Publication Date: I Quarter 2002. Please submit ONLY ON-LINE VERSION (PostScript or PDF or DOC) of the complete manuscript, not to exceed 25 pages, to one of the guest editors by June 1, 2001. Dr, Giacomo Morabito Broadband and Wireless Networking Laboratory School of Electrical and Computer Engineering Georgia Institute of Technology Atlanta, GA 30332-0280 Tel: +1 404 894 6616 Fax: +1 404 894 7883 E-Mail: giacomo@ece.gatech.edu Prof. Raghupathy Sivakumar School of Electrical and Computer Engineering Georgia Institute of Technology Atlanta, GA 30332-0280 Tel: +1 404 385 2257 Fax: +1 404 894 8363 E-Mail: siva@ece.gatech.edu Dr. Marie-José Montpetit, Ph.D., Architect Nokia Home Communications 5 Wayside Road Burlington, MA 01803, USA Tel: +1 781 993 4628 Fax: +1 781 993 1936 E-mail: marie-jose.montpetit@nokia.com