From owner-pilc@lerc.nasa.gov Tue Jul 4 09:59:43 2000 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27984 for ; Tue, 4 Jul 2000 09:59:43 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA08342 for pilc-outgoing; Tue, 4 Jul 2000 08:56:06 -0400 (EDT) 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 IAA08338 for ; Tue, 4 Jul 2000 08:56:05 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id IAA19586; Tue, 4 Jul 2000 08:56:05 -0400 Received: from pimout7-ext.prodigy.net(207.115.63.106) by seraph3.lerc.nasa.gov via smap (V5.5) id xma019545; Tue, 4 Jul 00 08:55:08 -0400 Received: from prodigy.net (CMB2A020-0433.splitrock.net [64.197.134.253]) by pimout7-int.prodigy.net (8.8.5/8.8.5) with ESMTP id IAA109388 for ; Tue, 4 Jul 2000 08:55:06 -0400 Message-ID: <3961DE9B.1A01E34B@prodigy.net> Date: Tue, 04 Jul 2000 08:54:51 -0400 From: Marie-Jose Montpetit Reply-To: marie@mjmontpetit.com X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: pilc@grc.nasa.gov Subject: New area for the group? Content-Type: multipart/mixed; boundary="------------DE98CDF9323109B8EF540C8B" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. --------------DE98CDF9323109B8EF540C8B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I guess with the IETF coming the traffic on the list will grow soon. I would like to submit a few discussion topics that are closely related to IP performance over links that exhibit special characteristics. I have the impression that our focus up to now has been mostly on the WAN. How about now looking at the Home Networks, the so called HANs (Home Area Networks)? While I do believe that what the group has done in the current drafts applies to the home ethernets and even the wireless LANs (802.11 and Bluetooth) I think we may want to put our brains together to make sure it does. I also think that the use of power lines provided new challenges. While the current implementations are pretty low bit rate the next generation (read this fall) is moving to the megabits per second. The way I understand them the link layer of these networks is the use of error protection mechanisms (FEC and what I would classify as "fade protection" potentially variable rates) to ensure some performance in spite of air conditioners or hair dryers and in general a pretty noisy environment. These mechanisms will have impacts on TCP as we well know. Do we want to add something in the LINK draft to cover those or do we believe we have enough right now? There is probably other issues in the HAN that may need our attention but may also be covered by other groups. Anyway my views. Happy 4th of July! Marie-Jose Marie-Jose Montpetit Nokia Venture Organization marie-jose.montpetit@nokia.com/marie@mjmontpetit.com --------------DE98CDF9323109B8EF540C8B Content-Type: text/x-vcard; charset=us-ascii; name="mariejose.montpetit.vcf" Content-Description: Card for Marie-Jose Montpetit Content-Disposition: attachment; filename="mariejose.montpetit.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Montpetit;Marie-Jose tel;cell:206-295-9059 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:marie@mjmontpetit.com fn:Marie-Jose Montpetit end:vcard --------------DE98CDF9323109B8EF540C8B-- From owner-pilc@lerc.nasa.gov Tue Jul 4 10:26: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 ESMTP id KAA28174 for ; Tue, 4 Jul 2000 10:26:44 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA09418 for pilc-outgoing; Tue, 4 Jul 2000 09:33:09 -0400 (EDT) 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 JAA09407 for ; Tue, 4 Jul 2000 09:33:08 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA21746; Tue, 4 Jul 2000 09:33:06 -0400 Received: from unknown(208.217.183.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021721; Tue, 4 Jul 00 09:33:01 -0400 Received: by atlconn1.panamsat.com with Internet Mail Service (5.5.2650.10) id ; Tue, 4 Jul 2000 09:33:00 -0400 Message-ID: <8046A317B5F4D21186610008C7EBB696020FCDF5@grnexch1.panamsat.com> From: "Falk, Aaron" Reply-To: marie@mjmontpetit.com To: "'Marie-Jose Montpetit '" , "'pilc@grc.nasa.gov '" Subject: RE: New area for the group? Date: Tue, 4 Jul 2000 09:27:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="windows-1252" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Marie-Jose- Well, in the satellite industry we sometimes talk about 'backhoe fades' to refer to fiber cable breaks but I've never heard of 'hairdryer fades' before. :^) On a more serious note, PILC has made a consistant effort to abstract specific link technologies (wireless, satellite, cable-modem, etc) into their performance-affecting characteristics (low bit rate, high errors, etc) rather than focus on the technologies themselves. This allows us to understand better the performance problems that might be already solved by other communities versus areas that might deserve more attention. This also enables us to focus on addressing the performance problems in the most general fashion. If you could describe the link characteristics of HANs and any performance issues they've created (in an email or I-D), this would make it easier for us to evaluate whether the issues merit working group cycles. Thanks, --aaron -----Original Message----- From: Marie-Jose Montpetit To: pilc@grc.nasa.gov Sent: 7/4/00 8:54 AM Subject: New area for the group? I guess with the IETF coming the traffic on the list will grow soon. I would like to submit a few discussion topics that are closely related to IP performance over links that exhibit special characteristics. I have the impression that our focus up to now has been mostly on the WAN. How about now looking at the Home Networks, the so called HANs (Home Area Networks)? While I do believe that what the group has done in the current drafts applies to the home ethernets and even the wireless LANs (802.11 and Bluetooth) I think we may want to put our brains together to make sure it does. I also think that the use of power lines provided new challenges. While the current implementations are pretty low bit rate the next generation (read this fall) is moving to the megabits per second. The way I understand them the link layer of these networks is the use of error protection mechanisms (FEC and what I would classify as "fade protection" potentially variable rates) to ensure some performance in spite of air conditioners or hair dryers and in general a pretty noisy environment. These mechanisms will have impacts on TCP as we well know. Do we want to add something in the LINK draft to cover those or do we believe we have enough right now? There is probably other issues in the HAN that may need our attention but may also be covered by other groups. Anyway my views. Happy 4th of July! Marie-Jose Marie-Jose Montpetit Nokia Venture Organization marie-jose.montpetit@nokia.com/marie@mjmontpetit.com <> From owner-pilc@lerc.nasa.gov Tue Jul 4 12:17: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 ESMTP id MAA28751 for ; Tue, 4 Jul 2000 12:17:44 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA12985 for pilc-outgoing; Tue, 4 Jul 2000 11:24:11 -0400 (EDT) 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 LAA12980 for ; Tue, 4 Jul 2000 11:24:10 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA28634; Tue, 4 Jul 2000 11:24:09 -0400 Received: from melanieb.vtt.fi(130.188.1.12) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028593; Tue, 4 Jul 00 11:23:22 -0400 Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi (8.9.3/8.9.3) with ESMTP id SAA21105 for ; Tue, 4 Jul 2000 18:23:12 +0300 (EET DST) Received: from tko103.vttele (tko103 [130.188.92.203]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with ESMTP id SAA04756 for ; Tue, 4 Jul 2000 18:23:11 +0300 (EET DST) Date: Tue, 4 Jul 2000 18:12:23 +0300 From: Zach Shelby X-Mailer: The Bat! (v1.38e) UNREG / CD5BF9353B3B7091 Reply-To: Zach Shelby Organization: VTT Electronics, Finland X-Priority: 3 (Normal) Message-ID: <16758.000704@vtt.fi> To: pilc@grc.nasa.gov Subject: Small wireless networks covered well... In-reply-To: <8046A317B5F4D21186610008C7EBB696020FCDF5@grnexch1.panamsat.com> References: <8046A317B5F4D21186610008C7EBB696020FCDF5@grnexch1.panamsat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by melanieb.vtt.fi id SAA21105 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id LAA12982 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit I agree with the previous point that this working group has kept it's link characteristic analysis general enough to apply to wireless links. We do research on these HAN wireless technologies in our group. This includes IEEE 802.11, Bluetooth, HomeRF, and Hiperlan (although expensive for home!!). These technologies are used in homes and other small ad-hoc networks. The PILC documents on links with errors, and slow links cover all the aspects involved with these technologies quite well. They also correspond with the scientific literature in this area. The PEP draft goes further to look at techniques which can be used to improve performance of these wireless networks as well. This draft did need some improvement in regard to small wireless networks, but I have already posted comments. (I can resend to anyone who didn't receive). If there are more areas missed by these drafts it's best to make comments on the mailing list? Regards, Zach Shelby ---------------------------------------------------------------------- Zach Shelby - Researcher Zach.Shelby@vtt.fi VTT Elektronics Phone +358 8 551 2164 (Office) Kaitoväylä 1, PL 1100 Fax +358 8 551 2320 90571 Oulu, Finland Mobile +358 40 7796297 ---------------------------------------------------------------------- http://paula.oulu.fi/~zdshelby Home: Yliopistokatu 14-707 90570 Oulu, Finland From owner-pilc@lerc.nasa.gov Fri Jul 7 08:00:51 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 ESMTP id IAA22273 for ; Fri, 7 Jul 2000 08:00:51 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA01637 for pilc-outgoing; Fri, 7 Jul 2000 06:58:41 -0400 (EDT) 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 GAA01633 for ; Fri, 7 Jul 2000 06:58:38 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id GAA10177; Fri, 7 Jul 2000 06:58:37 -0400 Received: from imc01.ex.nus.edu.sg(137.132.14.60) by seraph3.lerc.nasa.gov via smap (V5.5) id xma010166; Fri, 7 Jul 00 06:58:24 -0400 Received: by imc01.ex.nus.edu.sg with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jul 2000 18:57:12 +0800 Message-ID: From: Jong Hui Sian To: "'rap@iphighway.com'" Subject: 8th IEEE International Conference on Networks 2000 Date: Fri, 7 Jul 2000 18:57:04 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Dear Sir/Madam Kindly ignore this if you have already registered to participatee in ICON 2000. CALL FOR PARTICIPATION * 8th IEEE International Conference on Networks 2000 * 5 - 8 September 2000 Please visit : http:\\www.comp.nus.edu.sg\~icon We are pleased to invite you to attend the 8th IEEE International Conference On Networks 2000 (ICON 2000) which will be held from September 5- 8, 2000 in Singapore. It is organized by the IEEE Singapore Computer Chapter and the Professional Activities Center, Faculty of Engineering, National University of Singapore with co-operation from the Nanyang Technological University. Two days of tutorials and two days of technical presentations are planned for this conference. The conference will also include invited speakers, exhibitions and special panel discussion sessions. The aim of the conference is to provide an international forum for experts to promote, share and discuss various issues and developments in the broad field of computer and communication networks. * * * ICON' 2000 will provide a forum to discuss recent advances in computer networks and communications. Contributions describing original research, surveys and applications including, but not restricted to, the following areas are solicited * Active/intelligent networks * BISDN and ATM * Congestion/admission control * Data traffic engineering and management * High speed network protocols * Internet services/applications * Multicast/broadcast protocols * Multimedia protocols and networking * Multiple access technology * Network architecture and protocol performance * Network management and control * Network monitoring * Converged data and telecom networks * Network security and privacy * Network signaling and connection management * Optical communication networks * Personal communication services * Quality of service * Routing and routing protocols * Storage area networks * Testbeds and measurements * Voice over internet * Virtual private networks * Wireless/mobile/satellite networks and protocols * Pervasive networks * Distributed storage * * * More details of the conference including the Advance Program and registration form may be found at our web site http:\\www.comp.nus.edu.sg\~icon . Please do not hesitate to contact us should you need further information. Thank you and looking forward to your attendance to IEEE ICON 2000. Yours sincerely IEEE ICON 2000 Secretariat Tel : (65) 874 5113 Fax : (65) 874 5097 E-mail : engicon@nus.edu.sg From owner-pilc@lerc.nasa.gov Thu Jul 13 23:55:09 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 ESMTP id XAA02402 for ; Thu, 13 Jul 2000 23:55:09 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA12085 for pilc-outgoing; Thu, 13 Jul 2000 22:48:20 -0400 (EDT) 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 WAA12075 for ; Thu, 13 Jul 2000 22:48:13 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id WAA13266; Thu, 13 Jul 2000 22:48:11 -0400 Received: from breeze-fddi.research.telcordia.com(192.4.5.9) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013217; Thu, 13 Jul 00 22:47:29 -0400 Received: from research.telcordia.com (localhost [127.0.0.1]) by breeze.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6E2lPJ17075 for ; Thu, 13 Jul 2000 22:47:27 -0400 (EDT) Message-Id: <200007140247.e6E2lPJ17075@breeze.research.telcordia.com> To: pilc@grc.nasa.gov Subject: "MobiCom 2000: Discounted registration ends on July 15" Date: Thu, 13 Jul 2000 22:47:25 -0400 From: Ashutosh Dutta Sender: owner-pilc@lerc.nasa.gov Precedence: bulk (Our apologies for duplicate transmission) ANNOUNCEMENT AND CALL FOR PARTICIPATION MobiCom 2000 The Sixth Annual International Conference on Mobile Computing and Networking August 6 - 11, 2000 Seaport Hotel at World Trade Center Boston Boston, Massachusetts, USA THE COMPLETE ADVANCE PROGRAM AND REGISTRATION INFORMATION ARE AVAILABLE AT ---------------------------------------------- http://www.research.telcordia.com/mobicom2000/ ---------------------------------------------- Sponsored by ACM SIGMOBILE In cooperation with ACM SIGCOMM and SIGMETRICS; IEEE Communications Society; the USENIX Association; the IEE (UK); the IEICE and IPSJ (Japan); the KICS (Korea); and the IFIP WG 6.3 With support from: IBM Research, HP Laboratories, Compaq,Nokia, TRW, AT&T Laboratories Cambridge, Xerox PARC, 3Com, BBN/GTE, Aether Systems, Nortel Networks, Metricom, Boston Communications Group, Toshiba America Research,ThinAirApps CONFERENCE HIGHLIGHTS --------------------- o Keynote Address: "Sentient Computing: The Interface is Everywhere," by Andy Hopper, Professor, University of Cambridge, and Managing Director, AT&T Laboratories Cambridge. o Technical Sessions: Twenty-eight technical papers will be presented describing previously unpublished research on a wide variety of topics in mobile computing and wireless networking, including prototype systems and networks, location support and data dissemination, packet scheduling and channel allocation, mobile internetworking, data management in mobile systems, and routing for ad hoc networks. Papers in a special session will challenge the community with new technologies and visionary applications. This year's conference received the largest number of paper submissions ever, resulting in a highly selective technical program. o Panels: We have organized two panels on timely issues with panelists who are passionate about these topics. P1: Comm'n Sense: Wireless Sensor Networks (Moderator: Deborah Estrin, UCLA and USC/ISI) P2: The Future Wireless Internet: Gazing Into the Crystal Ball (Moderator: Armando Fox, Stanford University) o Tutorials: There will be eight tutorials on cutting-edge topics: T1: Mobile IP for Current and Future Internet (David B. Johnson, CMU and Rice University) T2: Database Management Systems and Mobile Computing (Wang-Chien Lee, GTE Labs, Sandeep K.S. Gupta and Pradeep Srimani, Colorado State University) T3: Personal Area Networking Over Bluetooth (Pravin Bhagwat, AT&T Labs Research) T4: Service Discovery and Device Cooperation (Golden Richard III, University of New Orleans) T5: Energy Efficiency in Mobile Computing and Networking (Mani Srivastava, UCLA) T6: Mobile Voice over IP (Prathima Agrawal, Telcordia, Parmesh Ramanathan, University of Wisconsin, and Cormac J. Sreenan, University College Cork) T7: Mobile Ad Hoc Networks: Routing, MAC and Transport Issues (Nitin Vaidya, Texas A&M University) T8: Shaping the User Experience for Handheld Computing (Phillip B. Shoemaker, Palm Inc.) o Research Demos and Exhibits: The conference will also feature research demos from academic and industry research groups as well as the newest cutting edge products and services from a wealth of companies. o Workshops: Tackling the dominant issues of the day, the following workshops will allow extended considerations of particular topics. - Dial-M: Discrete Algorithms and Methods for Mobile Computing and Communications - WoWMoM: Wireless Mobile Multimedia - MSWiM: Modeling Analysis and Simulation of Wireless and Mobile Systems - MobiHOC: Mobile Ad Hoc Networking and Computing REGISTRATION ------------ The MobiCom 2000 web pages have all the conference registration and hotel reservation specific information: http://www.research.telcordia.com/mobicom2000/ Important Dates: July 7, 2000 -- Discounted hotel reservation deadline. July 15, 2000 -- Early conference registration deadline. Don't delay -- register today for MobiCom 2000. Come, celebrate the wireless revolution and its convergence with the Internet, on Boston's historic waterfront. It is THE conference to attend. We look forward to seeing you in Boston. From owner-pilc@lerc.nasa.gov Mon Jul 17 08:08:56 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 ESMTP id IAA22107 for ; Mon, 17 Jul 2000 08:08:55 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA00055 for pilc-outgoing; Mon, 17 Jul 2000 06:39:35 -0400 (EDT) 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 GAA00048 for ; Mon, 17 Jul 2000 06:39:33 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id GAA12123; Mon, 17 Jul 2000 06:39:32 -0400 Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012109; Mon, 17 Jul 00 06:39:25 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24708; Mon, 17 Jul 2000 06:39:22 -0400 (EDT) Message-Id: <200007171039.GAA24708@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-inamura-docomo-00.txt Date: Mon, 17 Jul 2000 06:39:22 -0400 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A TCP profile for W-CDMA: 3G wireless packet service. Author(s) : H. Inamura, T. Ishikawa Filename : draft-inamura-docomo-00.txt Pages : 9 Date : 14-Jul-00 The third generation, 3G, wireless networks that enable high-speed data transfer are now being introduced. Internet access is one of the most important applications of such networks. TCP is one of the key technologies that enable Internet applications for such networks. A number of TCP optimization techniques have been studied to enhance the performance of TCP transmission for various wireless environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-inamura-docomo-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-inamura-docomo-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-inamura-docomo-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: <20000714142615.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-inamura-docomo-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-inamura-docomo-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000714142615.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Wed Jul 19 07:36: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 ESMTP id HAA15953 for ; Wed, 19 Jul 2000 07:36:53 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA11383 for pilc-outgoing; Wed, 19 Jul 2000 06:35:38 -0400 (EDT) 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 GAA11377 for ; Wed, 19 Jul 2000 06:35:37 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id GAA28451; Wed, 19 Jul 2000 06:35:36 -0400 Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028441; Wed, 19 Jul 00 06:35:32 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21471; Wed, 19 Jul 2000 06:35:31 -0400 (EDT) Message-Id: <200007191035.GAA21471@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-03.txt Date: Wed, 19 Jul 2000 06:35:30 -0400 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) : J. Touch, M. Montpetit, J. Mahdavi, G. Montenegro, D. Grossman, G. Fairhurst Filename : draft-ietf-pilc-link-design-03.txt Pages : 21 Date : 18-Jul-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-03.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-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-link-design-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000718140646.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-link-design-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-link-design-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000718140646.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Wed Jul 19 12:04:42 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 ESMTP id MAA03024 for ; Wed, 19 Jul 2000 12:04:41 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA23029 for pilc-outgoing; Wed, 19 Jul 2000 10:55:30 -0400 (EDT) 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 KAA22983 for ; Wed, 19 Jul 2000 10:55:27 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA25749; Wed, 19 Jul 2000 10:55:25 -0400 Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma025681; Wed, 19 Jul 00 10:54:59 -0400 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6JEsnM08225 for ; Wed, 19 Jul 2000 16:54:53 +0200 (MEST) Received: from E00D05905E94A.eed.ericsson.se (dhcp4-86 [164.48.140.86]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id QAA07235 for ; Wed, 19 Jul 2000 16:54:47 +0200 (MET DST) Message-Id: <4.3.2.7.0.20000719150341.00b3bef0@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Jul 2000 16:52:33 +0200 To: pilc@grc.nasa.gov From: Reiner Ludwig Subject: Comments to "Advice for Internet Subnetwork Designers" In-Reply-To: <200007191035.GAA21471@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk thanks to the authors for the well written draft! Some comments below. ///Reiner 1. The subnetwork's retransmission persistency: A subnetwork's retransmission persistency, i.e., for how long should a link layer delay (e.g., in terms of milliseconds) an IP packet in an attempt to transmit it over the link before it discards the packet, is an important issue for subnetwork designers. However, I feel that the draft is too fague on this matter: "It is important to recognize that a subnetwork can go too far in attempting to provide error recovery services in the Internet environment. Subnet reliability should be "lightweight", i.e., it only has to be "good enough", *not* perfect." A more concrete alternative would be to say something along the following lines: Subnets that do not distinguish between delay sensitive (e.g., real-time or streaming multimedia) and reliable flows (e.g., TCP, Reliable Multicast) should implement a low retransmission persistency (on the order of a few 10 milliseconds) [IS95] [GSM]. This is necessary to not interfere with the delay requirements of delay sensitive flows. On the other hand, subnetworks that are capable of separating reliable flows should implement a high retransmission persistency for such flows. However, a single IP packet may never be delayed by more than the Maximum Segment Lifetime (MSL) of 240 seconds defined for TCP [RFC1122]. 2. Minor detail in the section on "How TCP Works": There is says: "Queues provide output-buffering on links that are momentarily oversubscribed." However, queues also provide input-buffering on links and in fact packets can get dropped there, too, when the host/router is at high processor load. 3. Recovery from Subnetwork Outages: To the sentence: "If it cannot do this, then the subnetwork should hold onto at least some of the packets it accepts during an outage and attempt to deliver them when the subnetwork comes back up.", I propose to add the following sentence: However, none of such packet may be held for more than the Maximum Segment Lifetime (MSL) of 240 seconds defined for TCP [RFC1122]. Instead of the sentence: " Note that it is *not* necessary to avoid any and all packet drops during an outage.", I propose the following refinement: As long as the queue management policy allows (never queue packets without reasonable bounds, e.g., not more than a common bandwidth*delay product) the subnetwork should avoid dropping any packets. Beyond that it should start dropping from front to give an early congestion signal to the TCP sender. 4. The "Quality of Service, ..." section Although, I very much like the section and wish we could really implement it that way, I don't understand the discussion about the TOS field [RFC1349]. The definitions of the TOS field are obsolete and have been replaced by the definition of the differentiated service field [RFC2474 (proposed standard)] :-( From owner-pilc@lerc.nasa.gov Wed Jul 19 13:04:16 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 ESMTP id NAA28877 for ; Wed, 19 Jul 2000 13:04:15 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA08123 for pilc-outgoing; Wed, 19 Jul 2000 12:09:52 -0400 (EDT) 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 MAA08088 for ; Wed, 19 Jul 2000 12:09:49 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA05657; Wed, 19 Jul 2000 12:09:47 -0400 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005590; Wed, 19 Jul 00 12:09:05 -0400 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13EwOv-0007HH-00; Wed, 19 Jul 2000 17:08:49 +0100 Date: Wed, 19 Jul 2000 17:08:37 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.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: <4.3.2.7.0.20000719150341.00b3bef0@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 Wed, 19 Jul 2000, Reiner Ludwig wrote: > 1. The subnetwork's retransmission persistency: > > A subnetwork's retransmission persistency, i.e., for how long should a link > layer delay (e.g., in terms of milliseconds) an IP packet in an attempt to > transmit it over the link before it discards the packet, is an important > issue for subnetwork designers. link != subnetwork... > However, I feel that the draft is too fague > on this matter: > "It is important to recognize that a > subnetwork can go too far in attempting to provide error recovery > services in the Internet environment. Subnet reliability should be > "lightweight", i.e., it only has to be "good enough", *not* perfect." > > A more concrete alternative would be to say something along the following > lines: > > Subnets that do not distinguish between delay sensitive (e.g., real-time or > streaming multimedia) and reliable flows (e.g., TCP, Reliable Multicast) how would you recommend that such subnetworks distinguish between these two reliably? Aren't 'delay-sensitive' and 'reliable' entirely orthogonal criteria? (this leads into a discussion of how e.g. diffserv specifications of same could be interpreted by the subnet - arguably out of scope, but see discussion of QoS below.) > should implement a low retransmission persistency (on the order of a few 10 > milliseconds) [IS95] [GSM]. This is necessary to not interfere with the > delay requirements of delay sensitive flows. On the other hand, subnetworks > that are capable of separating reliable flows should implement a high > retransmission persistency for such flows. hey, that would really kill TCP over satellite's performance; RTT estimates would be thrown right off. Practically, you're getting in the way of the ramifications of the end-to-end argument; a lot more careful text would be needed here. Or, if we can't come up with text that is careful enough (discussing subnet error rates and contrasting those with the high reliability expected by IP-based transports in the light of delay overhead tradeoffs incurred by the subnet), we opt for saying as little as possible, above. (there's some relevant text at the end of the 'Analysis of Link Layer Effects on TCP Performance' section that could IMO do with moving here.) > 4. The "Quality of Service, ..." section > > Although, I very much like the section and wish we could really implement > it that way, I don't understand the discussion about the TOS field [RFC1349]. > > The definitions of the TOS field are obsolete and have been replaced by the > definition of the differentiated service field [RFC2474 (proposed standard)] :-( This was discussed on the mailing list some time back; did the material get lost in editing? dan's on the author list... See the thread starting http://pilc.grc.nasa.gov/pilc/list/archive/0774.html and in particular Dan Grossman's text http://pilc.grc.nasa.gov/pilc/list/archive/0803.html (which probably needs updating/trimming, the way diffserv terminology is going...) Other stuff: Referencing/discussing ramifications of Bennett's ToN paper in the packet reordering section seems like a good idea. 'Packet Reordering is not Pathological Network Behavior' Bennett, Partridge, Sheetman, IEEE/ACM Transactions on Networking, December 1999, (7):6, pp. 789-798 Examples of such subnetworks include ATM, with a single frame size of 48 bytes plus a 5-byte header, having already referenced AAL encapsulation etc, this example sits oddly - especially since you're talking about AAL5 several paras later. TCP-friendly needs a reference discussing throughput considerations when first mentioned, and explicitly relating to the 1/sqrt(p) eqn. Since ACKs are generally smaller than data segments, TCP can tolerate some asymmetry, but as a general rule designers of subnetworks should avoid large differences in the incoming and outgoing bandwidth. This only becomes a problem when the forward sending: backchannel acks capacity ratio exceeds 50:1 [*], but it's worth pointing out that assumptions about which way TCP is flowing are often invalidated by pesky users. (Hence ADSL networks banning webservers, napster serving etc.) [*] R. C. Durst, G. J. Miller, E. J. Travis 'TCP extensions for space communications', Mobicom '96, Nov '96 - yesyes, conference papers are not easily obtainable and not much point in referencing in an RFC - that goes for the MONET paper too. Using the delayed acknowledgment mechanism {Bra89], which reduces the number of ACKs transmitted by the receiver by roughly half, can also improve performance by reducing the congestion on the ACK channel. These mechanisms should be employed in asymmetric networks. Actually, delacks are recommended use anyway; not much point in giving endhost hints to subnetwork designers who can't control their endhosts. The other *criterion* for native multicast *is* a link-layer filter, References of the form RFCnnnn are Internet Request for Comments (RFC) documents available online at www.rfc-editor.org. little point in saying this _in_ an RFC. "Here's how to get this document you're already reading". [APS99] should be [RFC2581] 'Security' section is before references, 'Security Considerations' is after. odd. cheers, L. PGP From owner-pilc@lerc.nasa.gov Thu Jul 20 09:53:58 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 ESMTP id JAA20243 for ; Thu, 20 Jul 2000 09:53:57 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA17107 for pilc-outgoing; Thu, 20 Jul 2000 08:33:43 -0400 (EDT) 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 IAA17074 for ; Thu, 20 Jul 2000 08:33:40 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id IAA24190; Thu, 20 Jul 2000 08:33:39 -0400 Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024161; Thu, 20 Jul 00 08:33:37 -0400 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6KCXYQ11300; Thu, 20 Jul 2000 14:33:34 +0200 (MEST) Received: from E00D05905E94A.eed.ericsson.se (dhcp4-86 [164.48.140.86]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id OAA17871; Thu, 20 Jul 2000 14:33:32 +0200 (MET DST) Message-Id: <4.3.2.7.0.20000720140709.00b6cb60@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 14:32:21 +0200 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: <4.3.2.7.0.20000719150341.00b3bef0@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:08 19.07.00 +0100, Lloyd Wood wrote: > > Subnets that do not distinguish between delay sensitive (e.g., > real-time or > > streaming multimedia) and reliable flows (e.g., TCP, Reliable Multicast) > >how would you recommend that such subnetworks distinguish between >these two reliably? Good question. The protocol-ID field in the IP header can be used as an approximation to at least separate TCP flows from the rest. However, this has some problems: - IPsec overwrites the proto-ID field, and - other reliable flows (NFS, Reliable Multicast) run on top of UDP and can thus not be identified as reliable flows. It would be so much better to have the old TOS definitions deployed ... which unfortunately is not the case. >Aren't 'delay-sensitive' and 'reliable' entirely >orthogonal criteria? Not when it comes to the question about how persistent link layer ARQ should be. > > should implement a low retransmission persistency (on the order of a > few 10 > > milliseconds) [IS95] [GSM]. This is necessary to not interfere with the > > delay requirements of delay sensitive flows. On the other hand, > subnetworks > > that are capable of separating reliable flows should implement a high > > retransmission persistency for such flows. > >hey, that would really kill TCP over satellite's performance; I don't believe that. Has it ever been shown? >RTT >estimates would be thrown right off. Clearly, the measured RTT may vary more than without link layer ARQ. But that's what it should do for such a path because it only reflects the true RTT for sending packets reliably e2e. It will lead to a more conservative RTO which is exactly what should happen on such a path. Also, note that the RTO will drop quite sharply back closer to the "real RTT" after a sudden RTT spike so it's not a real problem. BTW, the draft's proposal to counter link outages (holding on to packets until after the outage and then to forward them) is basically the same thing as highly persistent link layer ARQ. That mechanism will also cause considerable RTT spikes. I don't see a problem with that. It merely reflects the path's properties. ///Reiner From owner-pilc@lerc.nasa.gov Thu Jul 20 09:58: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 ESMTP id JAA22880 for ; Thu, 20 Jul 2000 09:58:14 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA22027 for pilc-outgoing; Thu, 20 Jul 2000 09:01:48 -0400 (EDT) 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 JAA21997 for ; Thu, 20 Jul 2000 09:01:46 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA27498; Thu, 20 Jul 2000 09:01:44 -0400 Received: from percy.erg.abdn.ac.uk(139.133.204.86) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027470; Thu, 20 Jul 00 09:01:25 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e6KD1LC12169; Thu, 20 Jul 2000 14:01:21 +0100 (BST) Message-ID: <39770629.AFFEEB7E@erg.abdn.ac.uk> Date: Thu, 20 Jul 2000 14:01:13 +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: L.Wood@eim.surrey.ac.uk, pilc@grc.nasa.gov Subject: Re: Comments to "Advice for Internet Subnetwork Designers" References: 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 Lloyd Wood wrote: > On Wed, 19 Jul 2000, Reiner Ludwig wrote: > > > 1. The subnetwork's retransmission persistency: > > > > A subnetwork's retransmission persistency, i.e., for how long should a link > > layer delay (e.g., in terms of milliseconds) an IP packet in an attempt to > > transmit it over the link before it discards the packet, is an important > > issue for subnetwork designers. > > link != subnetwork... > > > However, I feel that the draft is too fague > > on this matter: > > "It is important to recognize that a > > subnetwork can go too far in attempting to provide error recovery > > services in the Internet environment. Subnet reliability should be > > "lightweight", i.e., it only has to be "good enough", *not* perfect." > > > > A more concrete alternative would be to say something along the following > > lines: > > > > Subnets that do not distinguish between delay sensitive (e.g., real-time or > > streaming multimedia) and reliable flows (e.g., TCP, Reliable Multicast) > > how would you recommend that such subnetworks distinguish between > these two reliably? Aren't 'delay-sensitive' and 'reliable' entirely > orthogonal criteria? (this leads into a discussion of how e.g. > diffserv specifications of same could be interpreted by the subnet - > arguably out of scope, but see discussion of QoS below.) > > > should implement a low retransmission persistency (on the order of a few 10 > > milliseconds) [IS95] [GSM]. This is necessary to not interfere with the > > delay requirements of delay sensitive flows. On the other hand, subnetworks > > that are capable of separating reliable flows should implement a high > > retransmission persistency for such flows. --- or should we say "better" reliability scheme (a higher persistence is one option, BUT too high is still dangerous - additional FEC is another option, hybrid ARQ/FEC schemes are also suitable in some environments, ...). > > hey, that would really kill TCP over satellite's performance; RTT > estimates would be thrown right off. Practically, you're getting in > the way of the ramifications of the end-to-end argument; a lot more > careful text would be needed here. > > Or, if we can't come up with text that is careful enough (discussing > subnet error rates and contrasting those with the high reliability > expected by IP-based transports in the light of delay overhead > tradeoffs incurred by the subnet), we opt for saying as little as > possible, above. It may be difficult to convince me that this document should start proposing specific solutions, if we do that we run the danger of giving the wrong advice. At the moment we have advice based on many years of people researching AND implementing these schemes. If we move towards what is currently good research, then we stand the risk of having to be very specific about the types of links we are considering. I suggest we don't do that - perhaps we should once we have this draft finished? > > (there's some relevant text at the end of the > 'Analysis of Link Layer Effects on TCP Performance' > section that could IMO do with moving here.) > > > 4. The "Quality of Service, ..." section > > > > Although, I very much like the section and wish we could really implement > > it that way, I don't understand the discussion about the TOS field [RFC1349]. > > > > The definitions of the TOS field are obsolete and have been replaced by the > > definition of the differentiated service field [RFC2474 (proposed standard)] :-( > > This was discussed on the mailing list some time back; did > the material get lost in editing? dan's on the author list... > > See the thread starting > http://pilc.grc.nasa.gov/pilc/list/archive/0774.html > and in particular Dan Grossman's text > http://pilc.grc.nasa.gov/pilc/list/archive/0803.html > (which probably needs updating/trimming, the way diffserv terminology > is going...) > > Other stuff: > > Referencing/discussing ramifications of Bennett's ToN paper in the > packet reordering section seems like a good idea. > 'Packet Reordering is not Pathological Network Behavior' Bennett, > Partridge, Sheetman, IEEE/ACM Transactions on Networking, > December 1999, (7):6, pp. 789-798 Excellent idea - this paper at least identifies order/delay are variable quantities in today's deployed Internet. Perhaps something derived from:: IP networks are allowed to reorder packets. Most link protocols provide in sequence delivery when used over a single physical link, which guarantees order. Subnets with alternate paths do not necessarily provide ordering [Benett]., neither does IP-forwarding when parallel processing is used [Benett]. My feeling was still that ordering was DESIRABLE, in most cases (for performance, and expected behaviour of transport protocols). But not required in ANY. You may disagree :-) > > > Examples of such subnetworks include > ATM, with a single frame size of 48 bytes plus a 5-byte header, > > having already referenced AAL encapsulation etc, this example sits > oddly - especially since you're talking about AAL5 several paras > later. > > TCP-friendly needs a reference discussing throughput considerations > when first mentioned, and explicitly relating to the 1/sqrt(p) eqn. > > Since ACKs are generally smaller than data > segments, TCP can tolerate some asymmetry, but as a general rule > designers of subnetworks should avoid large differences in the > incoming and outgoing bandwidth. > > This only becomes a problem when the forward sending: backchannel acks > capacity ratio exceeds 50:1 [*], but it's worth pointing out that > assumptions about which way TCP is flowing are often invalidated by > pesky users. (Hence ADSL networks banning webservers, napster serving > etc.) > > [*] R. C. Durst, G. J. Miller, E. J. Travis 'TCP extensions for space > communications', Mobicom '96, Nov '96 - yesyes, conference > papers are not easily obtainable and not much point in referencing > in an RFC - that goes for the MONET paper too. > > Using the delayed acknowledgment mechanism {Bra89], which reduces > the number of ACKs transmitted by the receiver by roughly half, can > also improve performance by reducing the congestion on the ACK > channel. These mechanisms should be employed in asymmetric > networks. > > Actually, delacks are recommended use anyway; not much point in giving > endhost hints to subnetwork designers who can't control their > endhosts. This could be addressed in a revised asymmetry document? > > > The other *criterion* for native multicast *is* a link-layer > filter, > I don't agree, because many of the links I have worked with have been single-hop, and that doesn't imply you have do anything at the link layer except broadcast the multicast packet - IP-layer filtering would work fine (if it could be done efficiently). I may be out-voted though :-) See my suggestions for a revised multicast section.... (see mail to this list on : Mon, 08 May 2000 15:05:14 +0100 Perhaps it will stimulate wider discussion? > > References of the form RFCnnnn are Internet Request for Comments > (RFC) documents available online at www.rfc-editor.org. > > little point in saying this _in_ an RFC. "Here's how to get this > document you're already reading". > > [APS99] should be [RFC2581] > > 'Security' section is before references, 'Security Considerations' is > after. odd. > > cheers, > > L. > > PGP -- ------------------------------ http://www.erg.abdn.ac.uk/users/gorry From owner-pilc@lerc.nasa.gov Thu Jul 20 11:09:13 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 ESMTP id LAA01586 for ; Thu, 20 Jul 2000 11:09:12 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA05353 for pilc-outgoing; Thu, 20 Jul 2000 10:21:09 -0400 (EDT) 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 KAA05336 for ; Thu, 20 Jul 2000 10:21:05 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA07363; Thu, 20 Jul 2000 10:21:04 -0400 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma007328; Thu, 20 Jul 00 10:20:56 -0400 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13FHC1-00011U-00; Thu, 20 Jul 2000 15:20:53 +0100 Date: Thu, 20 Jul 2000 15:20:50 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.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: <4.3.2.7.0.20000720140709.00b6cb60@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, 20 Jul 2000, Reiner Ludwig wrote: > >hey, that would really kill TCP over satellite's performance; > > I don't believe that. Has it ever been shown? > > >RTT estimates would be thrown right off. > > Clearly, the measured RTT may vary more than without link layer ARQ. But > that's what it should do for such a path because it only reflects the true > RTT for sending packets reliably e2e. It will lead to a more conservative > RTO which is exactly what should happen on such a path. The TCP flow taking that path will compete with other flows of varying length on the (congested) terrestrial part of the internetwork. Given TCP's bias against connections with long RTTs (e.g., see http://www.cs.berkeley.edu/~tomh/papers/globecom98_abstract.html) this is often a problem for bulk data transfers. If the RTTs of flows across your subnetwork are already extremely long relative to the majority of other flows in the internetwork, you should think twice before making them any longer imo. > BTW, the draft's proposal to counter link outages (holding on to packets > until after the outage and then to forward them) is basically the same > thing as highly persistent link layer ARQ. That mechanism will also cause > considerable RTT spikes. I don't see a problem with that. A lot depends on the link delay: outage delay ratio. L. PGP From owner-pilc@lerc.nasa.gov Thu Jul 20 14:06:01 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 ESMTP id OAA02721 for ; Thu, 20 Jul 2000 14:06:00 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA00614 for pilc-outgoing; Thu, 20 Jul 2000 13:02:03 -0400 (EDT) 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 NAA00553 for ; Thu, 20 Jul 2000 13:02:00 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA27617; Thu, 20 Jul 2000 13:01:58 -0400 Received: from c017-h015.c017.sfo.cp.net(209.228.12.229) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027563; Thu, 20 Jul 00 13:01:43 -0400 Received: (cpmta 29816 invoked from network); 20 Jul 2000 10:01:41 -0700 Received: from dnai-216-15-46-10.cust.dnai.com (HELO packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 20 Jul 2000 10:01:41 -0700 X-Sent: 20 Jul 2000 17:01:41 GMT Message-ID: <39773137.6805B2D2@packetdesign.com> Date: Thu, 20 Jul 2000 10:04:55 -0700 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: Reiner Ludwig CC: pilc@grc.nasa.gov Subject: Re: Comments to "Advice for Internet Subnetwork Designers" References: <4.3.2.7.0.20000719150341.00b3bef0@chapelle.ericsson.se> <4.3.2.7.0.20000720140709.00b6cb60@chapelle.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Reiner Ludwig wrote: > ... > > It would be so much better to have the old TOS definitions deployed ... > which unfortunately is not the case. > A nice thing about the redefinition of the TOS octet is that it is certainly possible to encode whatever you want in the DSCP. It's more "economical" in use of bit-patterns than the old definition. I believe that RFC 2474 gives you enough rope to go do whatever you'd like. Kathie From owner-pilc@lerc.nasa.gov Thu Jul 20 15:32:29 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 ESMTP id PAA15555 for ; Thu, 20 Jul 2000 15:32:28 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA14893 for pilc-outgoing; Thu, 20 Jul 2000 14:34:29 -0400 (EDT) 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 OAA14842 for ; Thu, 20 Jul 2000 14:34:27 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA09805; Thu, 20 Jul 2000 14:34:26 -0400 Received: from dirty.research.bell-labs.com(204.178.16.6) by seraph3.lerc.nasa.gov via smap (V5.5) id xma009751; Thu, 20 Jul 00 14:34:03 -0400 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Jul 20 14:32:44 EDT 2000 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA17759; Thu, 20 Jul 2000 14:33:36 -0400 (EDT) Message-ID: <397746B8.22A7B6B9@dnrc.bell-labs.com> Date: Thu, 20 Jul 2000 11:36:40 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Reiner Ludwig CC: pilc@grc.nasa.gov Subject: Re: Comments to "Advice for Internet Subnetwork Designers" References: <4.3.2.7.0.20000719150341.00b3bef0@chapelle.ericsson.se> <4.3.2.7.0.20000720140709.00b6cb60@chapelle.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Reiner Ludwig wrote: [..] > It would be so much better to have the old TOS definitions deployed ... > which unfortunately is not the case. Elaborating on Kathie's comment, although the DSCP doesn't have predefined QoS semantics like the old ToS byte, this isn't such a limitation. Consider a link interface/driver that peaks into the DSCP as an IP-aware entity. Therefore if it is part of a Diffserv domain, it ought to be configured for Diffserv QOS just like the diffserv routers and hosts that surround it. So the advice to subnetwork designers is "Allow your drivers to map from DSCPs into 'delay sensitive', etc, classes using operator configured mappings." (Clearly serious word mangling is required here, but hopefully the intent is clear...) cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-pilc@lerc.nasa.gov Fri Jul 21 03:20:58 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 ESMTP id DAA09147 for ; Fri, 21 Jul 2000 03:20:58 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA07555 for pilc-outgoing; Fri, 21 Jul 2000 02:34:14 -0400 (EDT) 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 CAA07551 for ; Fri, 21 Jul 2000 02:34:13 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id CAA16975; Fri, 21 Jul 2000 02:34:12 -0400 Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016939; Fri, 21 Jul 00 02:33:29 -0400 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6L6XRQ05353; Fri, 21 Jul 2000 08:33:27 +0200 (MEST) Received: from E00D05905E94A.eed.ericsson.se (dhcp4-86 [164.48.140.86]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id IAA25015; Fri, 21 Jul 2000 08:33:26 +0200 (MET DST) Message-Id: <4.3.2.7.0.20000721082651.00d15630@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 08:32:14 +0200 To: Kathleen Nichols From: Reiner Ludwig Subject: Re: Comments to "Advice for Internet Subnetwork Designers" Cc: Reiner Ludwig , pilc@grc.nasa.gov In-Reply-To: <39773137.6805B2D2@packetdesign.com> References: <4.3.2.7.0.20000719150341.00b3bef0@chapelle.ericsson.se> <4.3.2.7.0.20000720140709.00b6cb60@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 10:04 20.07.00 -0700, Kathleen Nichols wrote: >A nice thing about the redefinition of the TOS octet is >that it is certainly possible to encode whatever you >want in the DSCP. It's more "economical" in use of >bit-patterns than the old definition. I believe that >RFC 2474 gives you enough rope to go do whatever you'd >like. The problem I see with the DS field is that every border router is free to re-write it. This might make it difficult to mark my IPsec-encoded TCP-flow with the QoS requirement "maximize reliability" e2e over the entire path. ///Reiner From owner-pilc@lerc.nasa.gov Fri Jul 21 03:21: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 ESMTP id DAA09208 for ; Fri, 21 Jul 2000 03:21:03 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA07272 for pilc-outgoing; Fri, 21 Jul 2000 02:28:15 -0400 (EDT) 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 CAA07254 for ; Fri, 21 Jul 2000 02:28:13 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id CAA16563; Fri, 21 Jul 2000 02:28:12 -0400 Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016540; Fri, 21 Jul 00 02:28:04 -0400 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6L6RwQ02613; Fri, 21 Jul 2000 08:28:02 +0200 (MEST) Received: from E00D05905E94A.eed.ericsson.se (dhcp4-86 [164.48.140.86]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id IAA24172; Fri, 21 Jul 2000 08:27:56 +0200 (MET DST) Message-Id: <4.3.2.7.0.20000721081744.00d1c780@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 08:26:45 +0200 To: Grenville Armitage , nichols@imr1.ericy.com From: Reiner Ludwig Subject: Re: Comments to "Advice for Internet Subnetwork Designers" Cc: Reiner Ludwig , pilc@grc.nasa.gov In-Reply-To: <397746B8.22A7B6B9@dnrc.bell-labs.com> References: <4.3.2.7.0.20000719150341.00b3bef0@chapelle.ericsson.se> <4.3.2.7.0.20000720140709.00b6cb60@chapelle.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk on this topic, I would like to draw your attention to section 4.1 ("Extending the Differentiated Service Framework") of my dissertation which you can fetch here http://iceberg.cs.berkeley.edu/papers/Ludwig-Diss00/index.html. It discusses pretty much what you describe, Grenville. BTW, section 4.1.4 shows measured traces of how "holding on to packets during link outages" works so much better than "dropping packets during link outages". ///Reiner At 11:36 20.07.00 -0700, Grenville Armitage wrote: >Reiner Ludwig wrote: > [..] > > It would be so much better to have the old TOS definitions deployed ... > > which unfortunately is not the case. > >Elaborating on Kathie's comment, although the DSCP doesn't have >predefined QoS semantics like the old ToS byte, this isn't such a >limitation. Consider a link interface/driver that peaks into the >DSCP as an IP-aware entity. Therefore if it is part of a Diffserv >domain, it ought to be configured for Diffserv QOS just like the >diffserv routers and hosts that surround it. So the advice >to subnetwork designers is "Allow your drivers to map from DSCPs >into 'delay sensitive', etc, classes using operator configured >mappings." (Clearly serious word mangling is required here, but >hopefully the intent is clear...) > >cheers, >gja >________________________________________________________________________ >Grenville Armitage http://members.home.net/garmitage/ >Bell Labs Research Silicon Valley From owner-pilc@lerc.nasa.gov Fri Jul 21 04:27: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 ESMTP id EAA17574 for ; Fri, 21 Jul 2000 04:27:33 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA12639 for pilc-outgoing; Fri, 21 Jul 2000 03:38:24 -0400 (EDT) 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 DAA12626 for ; Fri, 21 Jul 2000 03:38:22 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id DAA21475; Fri, 21 Jul 2000 03:38:21 -0400 Received: from dirty.research.bell-labs.com(204.178.16.6) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021452; Fri, 21 Jul 00 03:38:03 -0400 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Jul 21 03:37:53 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn65.pa.bell-labs.com [135.250.1.65]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id DAA22939; Fri, 21 Jul 2000 03:38:46 -0400 (EDT) Message-ID: <3977FEDC.E5C4B3FE@dnrc.bell-labs.com> Date: Fri, 21 Jul 2000 00:42:20 -0700 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Reiner Ludwig CC: pilc@grc.nasa.gov Subject: Re: Comments to "Advice for Internet Subnetwork Designers" References: <4.3.2.7.0.20000719150341.00b3bef0@chapelle.ericsson.se> <4.3.2.7.0.20000720140709.00b6cb60@chapelle.ericsson.se> <4.3.2.7.0.20000721081744.00d1c780@chapelle.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Reiner Ludwig wrote: > > on this topic, I would like to draw your attention to section 4.1 > ("Extending the Differentiated Service Framework") of my dissertation which > you can fetch here > http://iceberg.cs.berkeley.edu/papers/Ludwig-Diss00/index.html. > > It discusses pretty much what you describe, Grenville. Then I am confused, since it was you who wrote: > > > It would be so much better to have the old TOS definitions deployed ... > > > which unfortunately is not the case. To which Kathie and I have observed it is infact better now, since the DSCP is more flexible. So which situation do you really believe in - that its good we have the DSCP, or we ought to return to the ToS semantics? Also, scanning your chapter 4 there's an odd statement on p.71 where you suggest adding four *new* DS Field values to represent four service classes. This is not at all what I was talking about. The service classes you discuss can be adequately supported using the existing PHBs (and indeed, Diffserv has always clearly stated that PHBs/DSCPs do not represent e2e service classes as classically understood). My previous email outlined that one can make a configured or signalled association between particular (pre-existing )DSCPs and the 'service class' that happens to be being mapped onto said DSCPs on a case by case (and reconfigurable) basis. cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-pilc@lerc.nasa.gov Fri Jul 21 04:43:54 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 ESMTP id EAA27178 for ; Fri, 21 Jul 2000 04:43:53 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA13526 for pilc-outgoing; Fri, 21 Jul 2000 03:50:26 -0400 (EDT) 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 DAA13516 for ; Fri, 21 Jul 2000 03:50:24 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id DAA22309; Fri, 21 Jul 2000 03:50:23 -0400 Received: from dirty.research.bell-labs.com(204.178.16.6) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022291; Fri, 21 Jul 00 03:50:01 -0400 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Jul 21 03:48:54 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn65.pa.bell-labs.com [135.250.1.65]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id DAA22985; Fri, 21 Jul 2000 03:49:46 -0400 (EDT) Message-ID: <39780170.46873DF3@dnrc.bell-labs.com> Date: Fri, 21 Jul 2000 00:53:20 -0700 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Reiner Ludwig CC: pilc@grc.nasa.gov Subject: Re: Comments to "Advice for Internet Subnetwork Designers" References: <4.3.2.7.0.20000719150341.00b3bef0@chapelle.ericsson.se> <4.3.2.7.0.20000720140709.00b6cb60@chapelle.ericsson.se> <4.3.2.7.0.20000721082651.00d15630@chapelle.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Reiner Ludwig wrote: [..] > The problem I see with the DS field is that every border router is free to > re-write it. This might make it difficult to mark my IPsec-encoded TCP-flow > with the QoS requirement "maximize reliability" e2e over the entire path. The DS field (DSCP) doesn't have e2e service class semantics. Expecting it to do so in a standardized manner suggests a misunderstanding of Diffserv. However, clearly a network operator might 'know' that they are using certain PHBs across a certain path to support application flows having sensitivity to latency, or loss, or whatever. Armed with this knowledge, the operator then configures certain link drivers to lookup the DSCP and infer desirable link characteristics. But that's not the same as formally defining new DSCPs to have service class semantics. DSCPs defined PHBs - scheduling and drop precedence semantics. cheers, gja From owner-pilc@lerc.nasa.gov Fri Jul 21 09:32:49 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 ESMTP id JAA12273 for ; Fri, 21 Jul 2000 09:32:48 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA07445 for pilc-outgoing; Fri, 21 Jul 2000 07:46:43 -0400 (EDT) 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 HAA07420 for ; Fri, 21 Jul 2000 07:46:41 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id HAA09112; Fri, 21 Jul 2000 07:46:39 -0400 Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma009059; Fri, 21 Jul 00 07:45:42 -0400 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6LBjdQ01555; Fri, 21 Jul 2000 13:45:40 +0200 (MEST) Received: from E00D05905E94A.eed.ericsson.se (dhcp4-86 [164.48.140.86]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id NAA00388; Fri, 21 Jul 2000 13:45:31 +0200 (MET DST) Message-Id: <4.3.2.7.0.20000721112423.00af8af0@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 13:44:16 +0200 To: Grenville Armitage From: Reiner Ludwig Subject: Re: Comments to "Advice for Internet Subnetwork Designers" Cc: pilc@grc.nasa.gov In-Reply-To: <3977FEDC.E5C4B3FE@dnrc.bell-labs.com> References: <4.3.2.7.0.20000719150341.00b3bef0@chapelle.ericsson.se> <4.3.2.7.0.20000720140709.00b6cb60@chapelle.ericsson.se> <4.3.2.7.0.20000721081744.00d1c780@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 00:42 21.07.00 -0700, Grenville Armitage wrote: >Reiner Ludwig wrote: > > > > on this topic, I would like to draw your attention to section 4.1 > > ("Extending the Differentiated Service Framework") of my dissertation which > > you can fetch here > > http://iceberg.cs.berkeley.edu/papers/Ludwig-Diss00/index.html. > > > > It discusses pretty much what you describe, Grenville. > >Then I am confused, since it was you who wrote: > > > > > It would be so much better to have the old TOS definitions deployed ... > > > > which unfortunately is not the case. > >To which Kathie and I have observed it is infact better now, since >the DSCP is more flexible. So which situation do you really believe >in - that its good we have the DSCP, or we ought to return to the >ToS semantics? What I believe in is that it would be very beneficial for "IP over wireless" if we could associate the TOS semantics ("minimize delay", "maximize throughput", "maximize reliability", etc.) or more specific semantics with certain DSCPs on an e2e basis. I'm aware of the fact that the DS field (DSCP) as opposed to the TOS byte does *not* have e2e service class semantics. This is what I pointed out in my reply to Kathie. I (as a link layer designer) would like to use a flow's DSCP *not only* to control scheduling and/or queue management algorithms at the network layer, but *also* to control link layer error control algorithms. E.g., in 3G systems a link layer can dynamically configure many parameters (e.g., for FEC, spreading factor, bit rate, ARQ persistency, etc., etc.) on a per packet, per flow, or at least on a per flow-class basis. I.e., the link layer has means to greatly influence: throughput, delay, reliablity. For that purpose, it would be extremely helpful if the IP layer (based on the DS field) could tell the link layer whether a particular packet/flow/flow-class is, e.g., delay sensitive or whether it is TCP-based bulk data. For the latter, delay is less important but throughput and reliability are important QoS requirements. >Also, scanning your chapter 4 there's an odd statement on p.71 where >you suggest adding four *new* DS Field values to represent >four service classes. I didn't write that they were "*new* DS Field values". I explicitly wrote that I borrowed from RFC1349 (Type of Service). >This is not at all what I was talking about. >The service classes you discuss can be adequately supported using >the existing PHBs Maybe I missed something. How can you specify with the existing DSCPs/PHBs that a flow (more precisely the application on top) is best served with max throughput and max reliability? >(and indeed, Diffserv has always clearly stated that >PHBs/DSCPs do not represent e2e service classes as classically >understood). I didn't say anything else. I only said that I wished that such e2e service classes could be defined. As it was possible with the TOS byte. ///Reiner From owner-pilc@lerc.nasa.gov Fri Jul 21 13:08: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 ESMTP id NAA10890 for ; Fri, 21 Jul 2000 13:08:44 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA15852 for pilc-outgoing; Fri, 21 Jul 2000 11:56:19 -0400 (EDT) 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 LAA15839 for ; Fri, 21 Jul 2000 11:56:18 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA08420; Fri, 21 Jul 2000 11:56:18 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008369; Fri, 21 Jul 00 11:55:30 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/calcite) id e6LFtSi06443 for pilc@grc.nasa.gov env-from ; Fri, 21 Jul 2000 09:55:28 -0600 (MDT) Date: Fri, 21 Jul 2000 09:55:28 -0600 (MDT) From: Vernon Schryver Message-Id: <200007211555.e6LFtSi06443@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: Comments to "Advice for Internet Subnetwork Designers" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Reiner Ludwig > ... > I didn't write that they were "*new* DS Field values". I explicitly wrote > that I borrowed from RFC1349 (Type of Service). > > >This is not at all what I was talking about. > >The service classes you discuss can be adequately supported using > >the existing PHBs > > Maybe I missed something. > > How can you specify with the existing DSCPs/PHBs that a flow (more > precisely the application on top) is best served with max throughput and > max reliability? As you wireless people keep pointing out, you can't maximize both simultaneously without failing to maximize one or the other. Do you mean to maximize throughput or queue position compared to competing traffic but to not turn off link layer forward error correction or error detection and retransmission? > >(and indeed, Diffserv has always clearly stated that > >PHBs/DSCPs do not represent e2e service classes as classically > >understood). > > I didn't say anything else. I only said that I wished that such e2e service > classes could be defined. As it was possible with the TOS byte. If the people running the edges where the new DS bits are changed do stupid things, then bad things will happen to the applications that rely on the new DS bits, or at least they not use the new DS bits. And in turn, that make make people working on modern wirelss links do as others did, those who worked on links with bit error rates as bad as modern wireless links but with speeds 10 times slower than modern wireless links. 1200 bit/sec modems were slow, and they had lots of bit errors. In not so ancient days, many people turned of v.42 over v.32 modems. Those old techniques, besides honoring the IP TOS byte, included assuming that small packets need lower latency and peeking at UDP and TCP port numbers. I've personally written, used, and caused to be shipped users of a what was once a major UNIX vendorcode that does all three. I think Van Jacobson's port snooping queuing is in a vast number of installations. Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Fri Jul 21 13:30: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 ESMTP id NAA24597 for ; Fri, 21 Jul 2000 13:30:25 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA20507 for pilc-outgoing; Fri, 21 Jul 2000 12:34:43 -0400 (EDT) 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 MAA20479 for ; Fri, 21 Jul 2000 12:34:40 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA12961; Fri, 21 Jul 2000 12:34:38 -0400 Received: from crufty.research.bell-labs.com(204.178.16.49) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012916; Fri, 21 Jul 00 12:34:02 -0400 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Fri Jul 21 12:32:01 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn69.pa.bell-labs.com [135.250.1.69]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA27076; Fri, 21 Jul 2000 12:32:53 -0400 (EDT) Message-ID: <39787C0A.E1E40B24@dnrc.bell-labs.com> Date: Fri, 21 Jul 2000 09:36:26 -0700 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Reiner Ludwig CC: pilc@grc.nasa.gov Subject: Re: Comments to "Advice for Internet Subnetwork Designers" References: <4.3.2.7.0.20000719150341.00b3bef0@chapelle.ericsson.se> <4.3.2.7.0.20000720140709.00b6cb60@chapelle.ericsson.se> <4.3.2.7.0.20000721081744.00d1c780@chapelle.ericsson.se> <4.3.2.7.0.20000721112423.00af8af0@chapelle.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Reiner Ludwig wrote: [..] > I (as a link layer designer) would like to use a flow's DSCP *not only* to > control scheduling and/or queue management algorithms at the network layer, > but *also* to control link layer error control algorithms. That's quite independent of statically assigning e2e service class semantics to DSCPs (new or otherwise). Here's a different way of stating my suggestion: the link driver can be configured/signalled to know, on a case by case basis, by the network operator, the service class(es) of the traffic being mapped into a particular DSCP (AFxy, EF, CSn...), and thereby infer the desired link error control algorithms. No new DSCPs (or even old ones) need additional, *statically* standardized e2e service semantics. IMHO. (e.g. in one person's network AF1y might be supporting loss tolerant traffic, in another person's network AF1y is supporting delay tolerant traffic, etc, etc.... and this is 'known' as part of the operator's overall Diffserv network provisioning/configuration process.) [..] > >Also, scanning your chapter 4 there's an odd statement on p.71 where > >you suggest adding four *new* DS Field values to represent > >four service classes. > > I didn't write that they were "*new* DS Field values". I explicitly wrote > that I borrowed from RFC1349 (Type of Service). http://iceberg.cs.berkeley.edu/papers/Ludwig-Diss00/chapter4_flow_adaptive.pdf First line of p.71, you write: "Below, we propose four new DS Field values that allow a differentiation between four different service classes, ..." Perhaps I'm reading the wrong chapter 4. cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-pilc@lerc.nasa.gov Fri Jul 21 14:38: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 ESMTP id OAA17996 for ; Fri, 21 Jul 2000 14:38:53 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA00473 for pilc-outgoing; Fri, 21 Jul 2000 13:48:07 -0400 (EDT) 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 NAA00424 for ; Fri, 21 Jul 2000 13:48:03 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA21235; Fri, 21 Jul 2000 13:47:59 -0400 Received: from popcorn.cisco.com(171.69.18.32) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021185; Fri, 21 Jul 00 13:47:13 -0400 Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id KAA15068; Fri, 21 Jul 2000 10:46:22 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <3977FEDC.E5C4B3FE@dnrc.bell-labs.com> References: <4.3.2.7.0.20000719150341.00b3bef0@chapelle.ericsson.se> <4.3.2.7.0.20000720140709.00b6cb60@chapelle.ericsson.se> <4.3.2.7.0.20000721081744.00d1c780@chapelle.ericsson.se> <3977FEDC.E5C4B3FE@dnrc.bell-labs.com> Date: Fri, 21 Jul 2000 10:48:26 -0700 To: Grenville Armitage From: Steve Deering Subject: Re: Comments to "Advice for Internet Subnetwork Designers" Cc: Reiner Ludwig , pilc@grc.nasa.gov Content-Type: text/plain; charset="us-ascii" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 12:42 AM -0700 7/21/00, Grenville Armitage wrote: >Reiner Ludwig wrote: > > > > It would be so much better to have the old TOS definitions deployed ... > > > > which unfortunately is not the case. > >To which Kathie and I have observed it is infact better now, since >the DSCP is more flexible. In communication protocols, "more flexible" usually means worse, not better, e.g., more complex, more need for configuration, more ways to screw up, more ways to be incompatible, etc. I'm with Reiner on this one. Steve From owner-pilc@lerc.nasa.gov Fri Jul 21 17:34: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 ESMTP id RAA10359 for ; Fri, 21 Jul 2000 17:34:33 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA25633 for pilc-outgoing; Fri, 21 Jul 2000 16:37:34 -0400 (EDT) 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 QAA25607 for ; Fri, 21 Jul 2000 16:37:31 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA12094; Fri, 21 Jul 2000 16:37:29 -0400 Received: from c017-h015.c017.sfo.cp.net(209.228.12.229) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012036; Fri, 21 Jul 00 16:36:34 -0400 Received: (cpmta 5373 invoked from network); 21 Jul 2000 13:36:32 -0700 Received: from dnai-216-15-46-10.cust.dnai.com (HELO packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 21 Jul 2000 13:36:32 -0700 X-Sent: 21 Jul 2000 20:36:32 GMT Message-ID: <3978B51C.8EC76F0C@packetdesign.com> Date: Fri, 21 Jul 2000 13:39:56 -0700 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: Steve Deering CC: Grenville Armitage , Reiner Ludwig , pilc@grc.nasa.gov Subject: Re: Comments to "Advice for Internet Subnetwork Designers" References: <4.3.2.7.0.20000719150341.00b3bef0@chapelle.ericsson.se> <4.3.2.7.0.20000720140709.00b6cb60@chapelle.ericsson.se> <4.3.2.7.0.20000721081744.00d1c780@chapelle.ericsson.se> <3977FEDC.E5C4B3FE@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Steve Deering wrote: > > At 12:42 AM -0700 7/21/00, Grenville Armitage wrote: > >Reiner Ludwig wrote: > > > > > It would be so much better to have the old TOS definitions deployed ... > > > > > which unfortunately is not the case. > > > >To which Kathie and I have observed it is infact better now, since > >the DSCP is more flexible. > > In communication protocols, "more flexible" usually means worse, not > better, e.g., more complex, more need for configuration, more ways to > screw up, more ways to be incompatible, etc. > > I'm with Reiner on this one. > > Steve And that's why the old TOS definitions were so successful... From owner-pilc@lerc.nasa.gov Fri Jul 21 22:04:58 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 ESMTP id WAA14423 for ; Fri, 21 Jul 2000 22:04:58 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA12583 for pilc-outgoing; Fri, 21 Jul 2000 21:17:26 -0400 (EDT) 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 VAA12565 for ; Fri, 21 Jul 2000 21:17:24 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id VAA05461; Fri, 21 Jul 2000 21:17:23 -0400 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005399; Fri, 21 Jul 00 21:16:51 -0400 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13Fntz-00000B-00 for pilc@grc.nasa.gov; Sat, 22 Jul 2000 02:16:27 +0100 Date: Sat, 22 Jul 2000 02:16:24 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: PILC mailing list Subject: Re: Comments to "Advice for Internet Subnetwork Designers" In-Reply-To: <3978B51C.8EC76F0C@packetdesign.com> 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 Steve Deering wrote: > In communication protocols, "more flexible" usually means worse, not > better, e.g., more complex, more need for configuration, more ways to > screw up, more ways to be incompatible, etc. the bitter lessons of multicast? L. PGP From owner-pilc@lerc.nasa.gov Mon Jul 24 07:18: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 ESMTP id HAA21308 for ; Mon, 24 Jul 2000 07:18:20 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA07605 for pilc-outgoing; Mon, 24 Jul 2000 06:08:43 -0400 (EDT) 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 GAA07598 for ; Mon, 24 Jul 2000 06:08:42 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id GAA27680; Mon, 24 Jul 2000 06:08:40 -0400 Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027670; Mon, 24 Jul 00 06:08:39 -0400 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6OA8aQ15127; Mon, 24 Jul 2000 12:08:36 +0200 (MEST) Received: from E00D05905E94A.eed.ericsson.se (dhcp4-86 [164.48.140.86]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id MAA26024; Mon, 24 Jul 2000 12:08:34 +0200 (MET DST) Message-Id: <4.3.2.7.0.20000724115341.00b1d4e0@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jul 2000 12:06:41 +0200 To: Kathleen Nichols From: Reiner Ludwig Subject: Re: Comments to "Advice for Internet Subnetwork Designers" Cc: Steve Deering , Grenville Armitage , pilc@grc.nasa.gov In-Reply-To: <3978B51C.8EC76F0C@packetdesign.com> References: <4.3.2.7.0.20000719150341.00b3bef0@chapelle.ericsson.se> <4.3.2.7.0.20000720140709.00b6cb60@chapelle.ericsson.se> <4.3.2.7.0.20000721081744.00d1c780@chapelle.ericsson.se> <3977FEDC.E5C4B3FE@dnrc.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 13:39 21.07.00 -0700, Kathleen Nichols wrote: >Steve Deering wrote: > > > > At 12:42 AM -0700 7/21/00, Grenville Armitage wrote: > > >Reiner Ludwig wrote: > > > > > > It would be so much better to have the old TOS definitions > deployed ... > > > > > > which unfortunately is not the case. > > > > > >To which Kathie and I have observed it is infact better now, since > > >the DSCP is more flexible. > > > > In communication protocols, "more flexible" usually means worse, not > > better, e.g., more complex, more need for configuration, more ways to > > screw up, more ways to be incompatible, etc. > > > > [...] > >And that's why the old TOS definitions were so successful... One reason for why TOS was never successful might be that in the past there was maybe not strong enough a need for it. Today, I think this is very different. The designers of wireless link layers could make transmission across the air much more efficient if they knew what kind of flow they were dealing with, i.e., which QoS requirements the application on top has. Unfortunately, many wireless link layers today are one-size-fits-all and that can be very inefficient, causing reduced e2e performance and waste of radio resources (spectrum, battery power). The only escape from that - given that we cannot use the TOS byte - are the tricks that Vernon pointed out: port number sniffing, small packets = need for low latency, ... but sniffing tricks won't work with IPsec :-( ///Reiner From owner-pilc@lerc.nasa.gov Mon Jul 24 07:18:58 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 ESMTP id HAA21524 for ; Mon, 24 Jul 2000 07:18:57 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA07948 for pilc-outgoing; Mon, 24 Jul 2000 06:18:43 -0400 (EDT) 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 GAA07942 for ; Mon, 24 Jul 2000 06:18:41 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id GAA28305; Mon, 24 Jul 2000 06:18:40 -0400 Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028291; Mon, 24 Jul 00 06:18:32 -0400 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6OAIUQ20619; Mon, 24 Jul 2000 12:18:30 +0200 (MEST) Received: from E00D05905E94A.eed.ericsson.se (dhcp4-86 [164.48.140.86]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id MAA28163; Mon, 24 Jul 2000 12:18:29 +0200 (MET DST) Message-Id: <4.3.2.7.0.20000724120716.00d2b900@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jul 2000 12:16:36 +0200 To: Vernon Schryver From: Reiner Ludwig Subject: Re: Comments to "Advice for Internet Subnetwork Designers" Cc: pilc@grc.nasa.gov In-Reply-To: <200007211555.e6LFtSi06443@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 09:55 21.07.00 -0600, Vernon Schryver wrote: > > How can you specify with the existing DSCPs/PHBs that a flow (more > > precisely the application on top) is best served with max throughput and > > max reliability? > >As you wireless people keep pointing out, you can't maximize both >simultaneously without failing to maximize one or the other. Don't agree with you here. >Do you mean >to maximize throughput or queue position compared to competing traffic >but to not turn off link layer forward error correction or error detection >and retransmission? Nothing about qeue position and nothing about competing traffic, i.e., nothing about scheduling. But, I can run my wireless link with maximum error recovery persistency (i.e., max reliablity) but with FEC A for telnet to minimize delay and FEC B for ftp to maximize throughput. > > >(and indeed, Diffserv has always clearly stated that > > >PHBs/DSCPs do not represent e2e service classes as classically > > >understood). > > > > I didn't say anything else. I only said that I wished that such e2e > service > > classes could be defined. As it was possible with the TOS byte. > > >If the people running the edges where the new DS bits are changed >do stupid things, then bad things will happen to the applications that >rely on the new DS bits, or at least they not use the new DS bits. Exactly, and that's the problem I see. Again, I wish we could have DSCPs with e2e semantics. >Those old techniques, besides honoring the IP TOS byte, included assuming >that small packets need lower latency and peeking at UDP and TCP port >numbers. I've personally written, used, and caused to be shipped users >of a what was once a major UNIX vendorcode that does all three. I think >Van Jacobson's port snooping queuing is in a vast number of installations. True many SLIP and PPP implementations play these tricks. As I said in an earlier mail, the problem with sniffing tricks is IPsec which is important for many wireless users/operators. Such users easily trade security for performance. Too bad because we could have both if we did it right. ///Reiner From owner-pilc@lerc.nasa.gov Mon Jul 24 07:42: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 ESMTP id HAA21306 for ; Mon, 24 Jul 2000 07:18:20 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA07149 for pilc-outgoing; Mon, 24 Jul 2000 05:55:41 -0400 (EDT) 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 FAA07141 for ; Mon, 24 Jul 2000 05:55:39 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id FAA26854; Mon, 24 Jul 2000 05:55:38 -0400 Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma026837; Mon, 24 Jul 00 05:55:26 -0400 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6O9tNQ05745; Mon, 24 Jul 2000 11:55:24 +0200 (MEST) Received: from E00D05905E94A.eed.ericsson.se (dhcp4-86 [164.48.140.86]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id LAA23926; Mon, 24 Jul 2000 11:55:21 +0200 (MET DST) Message-Id: <4.3.2.7.0.20000724111258.00ae4210@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jul 2000 11:53:29 +0200 To: Grenville Armitage From: Reiner Ludwig Subject: Re: Comments to "Advice for Internet Subnetwork Designers" Cc: pilc@grc.nasa.gov In-Reply-To: <39787C0A.E1E40B24@dnrc.bell-labs.com> References: <4.3.2.7.0.20000719150341.00b3bef0@chapelle.ericsson.se> <4.3.2.7.0.20000720140709.00b6cb60@chapelle.ericsson.se> <4.3.2.7.0.20000721081744.00d1c780@chapelle.ericsson.se> <4.3.2.7.0.20000721112423.00af8af0@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 09:36 21.07.00 -0700, Grenville Armitage wrote: >Reiner Ludwig wrote: > [..] > > I (as a link layer designer) would like to use a flow's DSCP *not only* to > > control scheduling and/or queue management algorithms at the network layer, > > but *also* to control link layer error control algorithms. > >That's quite independent of statically assigning e2e service class >semantics to DSCPs (new or otherwise). Here's a different way of stating >my suggestion: the link driver can be configured/signalled to know, >on a case by case basis, by the network operator, the service class(es) >of the traffic being mapped into a particular DSCP (AFxy, EF, CSn...), >and thereby infer the desired link error control algorithms. No new >DSCPs (or even old ones) need additional, *statically* standardized >e2e service semantics. IMHO. > >(e.g. in one person's network AF1y might be supporting loss tolerant >traffic, in another person's network AF1y is supporting delay tolerant >traffic, etc, etc.... and this is 'known' as part of the operator's >overall Diffserv network provisioning/configuration process.) I do not see how that could work. Consider this case: I use my wireless PDA to download some streaming media from some server in the Internet. How can the operator of the streaming server make sure that the DSCP of the streaming media flow has the right value when the flow "arrives" at the wireless access network? The "right value" should be one that the operator of the wireless access network understands as something like "this flow is delay sensitive" or even something that is more precise. Even if the DSCP would not change in transit (which of course it could), according to your proposal every operator of a wireless access network could have its own definition of which DSCP stands for "this flow is delay sensitive". Thus, even if the DSCP would not change in transit, it would at least be very difficult for the operator of the streaming server to set the right DSCP given that there is more than one wireless access network operator in the world. The problem is that the DS philosophy is not intended for such a scenario. The DS framework is intended for 2 bordering domains to agree on what kind of traffic each domain accepts to carry from the other. For that purpose bilateral agreements can be made including how the DS field should be (re-)set at the border routers. This is fine for ensuring QoS across domains. I believe this is a great idea and I think that the DS framework is a great concept, for the problem it tries to solve. Still, I believe that the e2e semantics of the TOS byte have quite some value, e.g., to solve the problem outline in the example given above. I.e., I still see the need for *statically* standardized DSCPs with e2e service semantics. ///Reiner From owner-pilc@lerc.nasa.gov Mon Jul 24 08:07: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 ESMTP id IAA06118 for ; Mon, 24 Jul 2000 08:07:50 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA10580 for pilc-outgoing; Mon, 24 Jul 2000 07:08:58 -0400 (EDT) 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 HAA10566 for ; Mon, 24 Jul 2000 07:08:56 -0400 (EDT) From: conf@colmar.uha.fr Received: by seraph3.lerc.nasa.gov; id HAA02107; Mon, 24 Jul 2000 07:08:55 -0400 Received: from nscolmar.colmar.uha.fr(194.167.108.34) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002085; Mon, 24 Jul 00 07:08:40 -0400 Received: from colmar.colmar.uha.fr (colmar.colmar.uha.fr [194.167.107.31]) by nscolmar.colmar.uha.fr (8.9.3/8.9.3) with ESMTP id MAA18280; Mon, 24 Jul 2000 12:29:03 +0200 Received: from gtrpc13 (gtrpc13.colmar.uha.fr [192.168.12.51]) by colmar.colmar.uha.fr (8.8.8/8.8.8) with SMTP id MAA07734; Mon, 24 Jul 2000 12:47:52 +0100 (WET DST) Message-Id: <3.0.1.32.20000724135349.0090d940@colmar.colmar.uha.fr> X-Sender: conf@colmar.colmar.uha.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Mon, 24 Jul 2000 13:53:49 +0200 To: conf@colmar.colmar.uha.fr Subject: Call for papers of ICN'01 & Final program of ECUMN'00 Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: quoted-printable Please feel free to circulate this following : - call for papers of ICN'01 (see 0000,0000,fefehttp://iutsun1.colmar.uha.fr/= ICN01.html ) AND=20 - final program of ECUMN'00 (see= 0000,0000,fefehttp://iutsun1.colmar.uha.fr= /ECUMN2000.html ) to interested colleagues. Accept our sincere apologies if you receive multiple copies. ----------------------------------------------------------------------------= ---
CALL FOR PAPERS=20 IEEE International Conference on Networking=20 ICN'01=20 July 11-13, 2001 - CREF, Colmar, France=20
GENERAL INFORMATION=20 The 2001 International Conference on Networking (ICN'01) is sponsored by= IEEE/Comsoc, IEEE/Computer, by IEE, by SEE and by WSES. ICN'01 is organized= by academic, research and industrial societies will be held at the= Technical Institute, Colmar, part of the University of Haute Alsace,= France, from Wednesday July 11, 2001 to Friday July 13, 2001. The city of= Colmar is ideally situated in the eastern part of France, near the German= and Swiss borders. The city of Colmar has been working on its own= Metropolitan Area Network (MAN) project, called OASICE, including LAN= interconnection, PBX interconnection and interactive video. An exhibition= illustrating these topics will be organized for industrial companies and= development research institutes.=20 In order to encourage closer interaction between academic and industrial ATM= research communities, we solicit both academic research papers and= industrial contributions.=20 TOPICS OF SPECIAL INTEREST=20 Topics of interest include, but are not limited to the following:=20 =20 Communications switching and routing =20 Communications modeling =20 Communications security =20 Computer communications =20 Multimedia and multicast communications =20 Internet environment =20 Network Management and control =20 Quality of Service (IntServ, DiffServ, =85) =20 Wireless Communications (Satellite, WLL, 3G) =20 Voice over IP =20 Java, Tina, Corba architectures Network signaling =20 ATM networks =20 ATM/IP integration =20 Integrated services =20 Traffic engineering =20 Telecommunication networks architectures =20 Performance evaluation, simulation =20 Mobile agents, active and intelligent networks =20 Applications and case studies =20 Protocol design and evaluation =20 MPLS=20 These topics can be discussed in term of concepts, state of the art,= standards, implementations, running experiments and applications.=20 INSTRUCTIONS FOR AUTHORS=20 Mail four papers or E-mail preferably in Word 6 format, or alternately a= postscript version of a 2000-word extended abstract summarizing an original= work. All the manuscripts must be written in English. The top of the first= page of each paper should include the title of the paper, authors' name,= position, address, telephone and fax numbers, e-mail of the author= responsible for correspondence and a list of four keywords. The deadline= for submission of all extended abstracts is December 10, 2000 with= notification of acceptance by February 20, 2001. Submission of camera-ready= paper is by March 30, 2001.=20 Authors of accepted papers will be invited to submit full-length manuscripts= for inclusion in the proceedings with ISBN.=20 All submitted papers should be sent to the following address:=20 Pascal LORENZ=20 University of Haute Alsace=20 IUT - Department GTR=20 34 rue du Grillenbreit=20 68008 Colmar, France=20 Phone: 33 (0)389202366 Fax: 33 (0)389202359 Mobile: 33 (0)603658042=20 E-mail: lorenz@colmar.uha.fr=20 Check our Web page at= 0000,0000,fefehttp://iutsun1.colmar.uha.fr= /ICN01.html for the latest information concerning the= conference.=20 Best papers will be forwarded for consideration in a special issue of a= journal.=20 TUTORIALS AND WORKSHOPS=20 Tutorials and workshops provide overviews of current high interest topics.= Proposals for half of full day tutorials are due by December 10, 2000.=20 INTERNATIONAL ADVISORY COMMITTEE=20 R. Addie (Australia) - University of Southern Queensland=20 K. Begain (Jordan) - Mu'tah University=20 A. Benslimane (France) - University of Belfort-Montbeliard=20 B. Bing (Singapore) - Ngee Ann Polytechnic=20 D. Bonjour (France) - CNET=20 A. Brandwajn (USA) - University of California Santa Cruz=20 J.P. Coudreuse (France) =96 Mitsubishi=20 J. Crowcroft (UK) =96 University College London=20 S. Fdida (France) =96 LIP6=20 B. Gavish (USA) - Vanderbilt University=20 H. Guyennet (France) - University of Franche-Comte=20 J. Halpern (USA) =96 Newbridge=20 Z. Hulicki (Poland) =96 University of Cracow=20 R. Israel (France) - IEEE=20 A. Jajszczyk (Poland) - University of Mining & Metallurgy=20 A. Jamalipour (Australia) - University of Sydney=20 S. Kota (USA) - Lockeed Martin=20 D. Kouvatsos (UK) - University of Bradford=20 S. Kumar (USA) =96 Ericsson=20 G.S. Kuo (Taiwan) =96 National Central University=20 F. Le Faucheur (France) - Cisco=20 M. Lee (Korea) =96 Dongshin University=20 P. Lorenz (France) - University of Haute Alsace=20 H.. Mouftah (Canada) - Queen's University=20 G. Omidyar (USA) - Computer Sciences Corp.=20 J.J. Pansiot (France) - University of Strasbourg=20 M. Potts (Switzerland) - Martel=20 Z. Mammeri (France) - University of Toulouse=20 N. Mastorakis (Greece) - Military Institutions of University Education=20 S. Moyer (USA) - Bellcore=20 R. Muraine (France) - Newbridge=20 G. Pujolle (France) - University of Versailles-Saint-Quentin=20 S. Rao (Switzerland) - Ascom=20 A. Reid (UK) - British Telecom=20 S. Ritzenthaler (France) - Newbridge=20 P. Rolin (France) - ENST Bretagne=20 R. Saracco (Italy) - CSELT=20 G. Swallow (USA) - Cisco=20 H. Tobiet (France) =96 Clemessy=20 M. Trehel (France) =96 University of Franche-Comte=20 V.A. Villagra (Spain) =96 University of Madrid=20 E. Vazquez Gallo (Spain) =96 University of Madrid=20 O. Yang (Canada) - University of Ottawa=20 IMPORTANT DATES=20 Extended Abstract due: December 10, 2000=20 Notification of acceptance: February 20, 2001=20 Deadline for full-length camera-ready manuscript: March 30, 2001=20 ---------------------------------------------------------------------------
1st IEEE European Conference on Universal Multiservice= Networks ECUMN'2000 October 2-4, 2000 - CREF, Colmar, France FINAL PROGRAM
=20 08:30 - 18:30 Conference Registration Monday October 2, 2000 09:00 - 09:20 Opening Address=20 09:20 - 10:30 Tutorial Session 1 Internet Services over Mobile and Wireless Networks: Architectures and= Protocols G. Omidyar, Computer Sciences Corp., USA ; M.J. Montpetit, Teledesic LLC,= USA 10:30 - 11:00 Coffee Break 11:00 - 12:15 Network Architecture and Convergence Chair: S. Ritzenthaler, Newbridge, France MPLS and Next Generation Access Network A. Kankkunen, Integral Access Inc, USA Deutsche Telekom's View on Network Convergence L. Falkenhagen Deutsche Telekom AG, Germany A Functional Architecture for End-to-end Quality-of-Service in a= Multi-domain Network E. Pagani, G.P. Rossi, University of Milano, Italy 12:15 - 13:00 Panel Discussion 1 - Network Evolution and Convergence 13:00 - 14:30 Lunch 14:30 - 16:15 Traffic=20 Chair: M. Villen, Telefonica I+D, Spain The Relevance of the Bufferless Analysis for Traffic Management in= Telecommunication Networks G. Hasslinger, F. Hartleb, Telekom Innovations-GmbH, Germany ; M. Fiedler,= University of Karlskrona/Ronneby, Sweden Mapping of Loss and Delay Between IntServ and DiffServ T. Chahed, G. H=E9buterne, C. Fayet, National Institute of= Telecommunications, France Resource Demand of Aggregated Resource Reservations J. Ehrensberger, Swiss Federal Institute of Technology, Switzerland Characterization of the MPEG-2 Video Traffic Generated by DVD Applications A. Chodorek, Kielce University of Technology, Poland ; R. Chodorek,= University of Mining and Metallurgy, Poland 14:30 - 16:15 Interworking between narrow band and broadband networks Chair: S. Chakraborty, Technical University of Helsinki, Finland Integrating Euro-ISDN with ATM Technology: Interworking Mechanisms and= Services Support L. Mandalos, K. Leonidou, C. Andreopoulos, J. Drakos, S. Koubias, G.= Papadopoulos, University of Patras, Greece Extending the Internet with the Intelligent Network Capabilities B. El Ouahidi, M. Bouhdadi, University of Rabat, Morocco ; D. Bourget, ENST,= France A Suitable Service Discipline for ATM-Ethernet Interconnection J.M. Arco, D. Meziat, B. Alarcos, University of Alcala, Spain Interoperability of ATM-Ethernet Interworking System: Design and Congestion= Control R. Ouni, A. Soudani, S. Nasri, M. Abid, R. Tourki, University of Monastir,= Tinisia ; K. Torki, INPG, France 16:15 - 16:45 Coffee Break 16:45 - 18:30 Routing Chair: P. Chemouil, France Telecom R&D, France Adaptive Routing and Load Balancing of Ephemeral Connections M. Heusse, ENST de Bretagne, France A new Multi-Services Rerouting Algorithm A. Gueroui, University of Versailles, France ; L. Mokdad University of= Dauphine, France ; J. Ben-Othman University of Paris 6, France Extending Mobile IP-v6 with Multicast to Support Mobile Networks in IPv6 T. Ernst, C. Castelluccia, INRIA Rh=F4ne-Alpes, France ; H.Y. Lach, Motorola= Labs, France 16:45 - 18:30 Interworking between IP and ATM Chair: M. Potts, Martel, Switzerland Topology Optimization of IP over ATM L. Frelechou, M. Osborne, R. Haas, IBM Research, Switzerland Resource Reservation with Boomerang via Open Interfaces M. Maliosz, Budapest University of Technology and Economics, Hungary Efficient Translation of Network Performance Parameters for Transport of IP= Packets over Cell-Switched Subnetworks J. Schmitt, M. Karsten, R. Steinmetz, Darmstadt University of Technology,= Germany Design of Adaptive Access Network and Control Protocol H. Nakagawa, I. Kazunari, N. Ohta, NTT Information Sharing Platform= Laboratories, Japan 19:15 Reception - Town Hall Tuesday October 3, 2000 09:00 - 10:45 End to end traffic Control (1) Chair: U. Krieger, Deutsche Telecom, Germany Guaranteed QoS for TCP flows in ATM-based DiffServ Networks T. M=FCller, Dresden University of Technology, Germany Virtual Buffering Strategy for GFR Services in IP/ATM Internetworks S.C. Hu, Ming Shin Institute of Technology, Taiwan ; P.C. Wang, Y.C. Chen,= National Chiao Tung University, Taiwan ; C.T. Chan, Chunghwa Telecom,= Taiwan An Efficient Weight Assignment Process for GPS Servers G. Urvoy, PRISM, France ; G. Hebuterne, Institut National des= T=E9l=E9communications, France Some Aspects of RTP - TCP Coexistence in Universal Multiservice Networks R. Chodorek, University of Mining and Metallurgy, Poland 09:00 - 10:45 Mobile Networks and Mobile Services Chair: G. Omidyar, Computer Sciences Corp, USA Voice Enabled Request and Response for Mobile Devices Supporting WAP= Protocol: the Constraints A. Mohan, Himachal Futuristic Communications, India ; A. Mohan, Indian= Institute of Technology, India IP based enhanced Data Casting Services over Radio Broadcast Networks W. Kellerer, P. Sties, J. Ebersp=E4cher, Munich University of Technology,= Germany Location-Dependant and Value Added Services (VAS) for Mobile Communications P. Lorenz, University of Haute Alsace, France ; H. Tobiet, NMG, France=20 The IP Revolution and Potential gains for ISP/Mobile/Fixed Telephony= Operators in the Liberalization of Telecommunications D. Vergados, D. Drakoulis, E. Vayias, J. Soldatos, N. Mitrou, National= Technical University of Athens, Greece 10:45 - 11:15 Coffee Break 11:15 - 13:00 Multicast Chair: G. Girardi, CSELT, Italy A Scalable Fault Tolerant Approach to Core Election in an Inter-Domain= Multicast Routing Environment M.D.Ech-Cherif El Kettani, ENSIAS, Morocco; Y. Souissi, EMI, Morocco A New Routing Algorithm for Delay-Constrained Dynamic Multicast T. Asaka, NTT Service Integration Laboratories, Japan ; T. Miyoshi, Y.= Tanaka, Waseda University, Japan Remote Time-Alignment of Interactive Services through Efficient Multicast= Algorithms A. Borella, G. Cancellieri, University of Ancona, Italy Key Establishment for IGMP Authentication in IP Multicast T. Hardjono, B. Cain, Nortel Networks, USA 11:15 - 13:00 IP Test-beds Chair: H. Tobiet, NMG, France Real-Time Multimedia Services over Internet A. Benslimane, Technical University of Belfort-Montb=E9liard, France Telephony over IP: Theoretical Modelling and Lab Experiments P. Senesi, P. Ferrabone, G. Gritella, R. Rinaldi, M. Siviero, CSELT, Italy User-domain Multiservice Architecture for Wired and Wireless IP Networks L. Cheng, I. Marsic, The State University of New Jersey, USA A Testbed Environment for the Performance Evaluation of Modular Network= Architectures D. Maggiorini, E. Pagani, G.P. Rossi, University of Milano, Italy 13:00 - 14:30 Lunch 14:30 - 16:15 Modeling Chair: G. H=E9buterne, INT, France Estimation of the Renewal Function by Empiral Data - A Bayesian Approach N.M. Markovitch, Russian Academy of Sciences, Russia ; U.R. Krieger, T-Nova= Deutsche Telekom, Germany Modeling Access Networks for Quality of Service F. Duran, T. Lizambri, S. Wakid, National Institute of Standards and= Technology, USA ; D.R. Vaman, Megaxess, USA Managing Wireless Internet Information of Electronic Advertising E. Rashid, Y. Yoshioka, Hirosaki University, Japan ; Y. Nemoto, T. Nakamura,= Tohoku University, Japan Performance Evaluation of a full Memory Multidestination Protocol for= Satellite Based Reliable Multicast with and without Local Recovery H. Jianhua, K.R. Subramanian, Y. ZongKai, H. Ping, Nanyang Technological= University, Singapore 14:30 - 16:15 Tariffs and Bandwidth Allocation Chair: P. Lorenz, University of Haute Alsace, France INEDAC Project: A Tool to Calculate Interconnection Tariff based on a= Bottom-up Method J.A. Portilla, K.D. Hackbarth, A.E. Garcia, University of Cantabria, Spain ;= R. W=F6hrl, F. Gonzalez, Institut f=FCr Kommunikationsdienste GmbH, Germany Auction Method and its Performance in a Dynamic Bandwidth Allocation Service E. Takahashi, Y. Tanaka, Waseda Universiy, Japan Multivariable Feedforward Plus Feedback Control for Adapting MPEG Video= Streams to Variable Channel Bandwidth H.F. Raynaud, M. Luong, University of Paris Nord, France Robust Topology for Enterprise Networks against Diverse Tariff Structures T. Miyoshi, K. Mouri, Y. Tanaka, Waseda University, Japan ; T. Asaka, NTT= Service Integration Laboratories, Japan 16:15 - 16:45 Coffee Break 16:45 - 18:30 End to end Traffic Control (2) Chair: G. H=E9buterne, INT, France An Architecture of QoS Services for a Core Internet Network over DTM C.J. Barenco, Polytechnic University of Madrid, Spain ; A.A. Salona, J.I.= Moreno, University Carlos III of Madrid, Spain Congestion Avoidance for Unicast and Multicast Traffic A. Dracinschi, S. Fdida, University Pierre et Marie Curie, France MPOA and QoS Support in LIS Internetworking Environments I. Erturk, Kocaeli University, UK ; E. Stipidis, University of Sussex, UK A Method for Increasing Throughput based on Packet Striping F. Jacquet, M. Misson, IUT of Clermont-Ferrand, France 16:45 - 18:30 Advanced Networking Chair: G.V. Morson, Cambridge Network, England A New Network Service Environment using Active Network K. Widoyo, T. Aoki, H. Yasuda, University of Tokyo, Japan Adaptive Applications over Active Networks: Case Study on Layered Multicast L. Yamamoto, G. Leduc, University of Li=E8ge, Belgium Integrated Performance Monitoring of Client/Server Software C. Steigner, J. Wilke, I. Wulff, University of Koblenz-Landau, Germany Who needs Addresses ? V. Guruprasad, IBM, USA 20:00 Gala Dinner - Restaurant Meistermann Wednesday October 4, 2000 09:00 - 10:00 Tutorial Session 2 Chair: P. Rolin, France Telecom R&D, France Active Networks and its Management M. Brunner, NEC Europe Ltd, Germany 10:00- 10:30 Coffee Break 10:30 - 11:45 New Architectures for New Services Chair: A. Gravey, ENST-Bretagne, France A Novel Architecture for Efficient Protocol Processing in High Speed= Communication Environments G. Konstantoulakis, V. Nellas, C. Georgopoulos, T. Orphanoudakis, N. Zervos,= Ellemedia Technologies, Greece ; M. Steck, Hyperstone electronics GmbH,= Germany; D. Verkest, Interuniversity Microelectronics Centre (IMEC),= Belgium; G. Doumenis, D.Reisis, University of Athens, Greece; N. Nikolaou,= J.A. Sanchez, Lucent Technologies, The Netherlands Using T=E9l=E9domotis Interface for a new Multiservice Network applied to= Monitoring the Elderly T. Val, E. Campo, IUT of Blagnac, France ; P. Kauffmann, M. Misson,= University of Clermont II, France ; P.Y. Danet, France T=E9l=E9com R&D,= France Video and Interactive Internet access in a DVB Network R. Jaeger, BetaResearch, Germany 11:45 - 13:00 Panel Discussion 2 - New Architectures for New Services 13:00 - 14:30 Lunch 14:30 Visit of Vialis From owner-pilc@lerc.nasa.gov Mon Jul 24 10:56:15 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 ESMTP id KAA12440 for ; Mon, 24 Jul 2000 10:56:15 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA02833 for pilc-outgoing; Mon, 24 Jul 2000 09:53:54 -0400 (EDT) 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 JAA02792 for ; Mon, 24 Jul 2000 09:53:50 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA17027; Mon, 24 Jul 2000 09:53:47 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016961; Mon, 24 Jul 00 09:53:42 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/calcite) id e6ODren08535 for pilc@grc.nasa.gov env-from ; Mon, 24 Jul 2000 07:53:40 -0600 (MDT) Date: Mon, 24 Jul 2000 07:53:40 -0600 (MDT) From: Vernon Schryver Message-Id: <200007241353.e6ODren08535@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: Comments to "Advice for Internet Subnetwork Designers" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Reiner Ludwig > ... > > > How can you specify with the existing DSCPs/PHBs that a flow (more > > > precisely the application on top) is best served with max throughput and > > > max reliability? > > > >As you wireless people keep pointing out, you can't maximize both > >simultaneously without failing to maximize one or the other. > ... > But, I can run my wireless link with maximum error recovery persistency > (i.e., max reliablity) but with FEC A for telnet to minimize delay and FEC > B for ftp to maximize throughput. But you are not maximizing throughput and reliability. As some of the wireless people tirelessly point out (especially some with addresses at Ericsson.com), you could get more throughput by not using any FEC, not to mention the retransmissions. I assume you mean by "error recovery persistency." > ... > >If the people running the edges where the new DS bits are changed > >do stupid things, then bad things will happen to the applications that > >rely on the new DS bits, or at least they not use the new DS bits. > > Exactly, and that's the problem I see. Again, I wish we could have DSCPs > with e2e semantics. You can't pass laws or standards that keep people from doing stupid things. In other words, why not continue to mark your FTP/TCP/IP packets with 0x08 and their telnet packets with 0x10? (I trust you know that if you use BSD UNIX systems, you're already doing that.) Yes, some people operating routers will configure them to do stypid things with those values, and some vendors will build routers that do only stupid things with those values, but more will do far worse things, such hijacking all of your HTTP, SMTP, or FTP packets and sending them to redirection proxies in the name of protecting you from spam or optimizing your WWW experience. Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Mon Jul 24 11:06: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 ESMTP id LAA15984 for ; Mon, 24 Jul 2000 11:06:27 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA04353 for pilc-outgoing; Mon, 24 Jul 2000 10:02:02 -0400 (EDT) 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 KAA04320 for ; Mon, 24 Jul 2000 10:01:59 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA18001; Mon, 24 Jul 2000 10:01:57 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017927; Mon, 24 Jul 00 10:01:50 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/calcite) id e6OE1nr08870 for pilc@grc.nasa.gov env-from ; Mon, 24 Jul 2000 08:01:49 -0600 (MDT) Date: Mon, 24 Jul 2000 08:01:49 -0600 (MDT) From: Vernon Schryver Message-Id: <200007241401.e6OE1nr08870@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: Comments to "Advice for Internet Subnetwork Designers" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Reiner Ludwig > ... > The designers of wireless link layers could make transmission across the > air much more efficient if they knew what kind of flow they were dealing > with, i.e., which QoS requirements the application on top has. > > Unfortunately, many wireless link layers today are one-size-fits-all and > that can be very inefficient, causing reduced e2e performance and waste of > radio resources (spectrum, battery power). The only escape from that - > given that we cannot use the TOS byte -... Why can't wireless links use the RFC 1349 values? Aren't those 4 values supposed to be grandfathered? Why can't you trust that people who aren't stupid will configure their routers to translate the DS values they use inside their networks to mean low-delay or high throughput back to 0x10 and 0x08 as packets leave their networks? Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Tue Jul 25 03:19:01 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 ESMTP id DAA08351 for ; Tue, 25 Jul 2000 03:19:01 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA14154 for pilc-outgoing; Tue, 25 Jul 2000 02:21:53 -0400 (EDT) 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 CAA14138 for ; Tue, 25 Jul 2000 02:21:50 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id CAA25304; Tue, 25 Jul 2000 02:21:50 -0400 Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma025256; Tue, 25 Jul 00 02:20:53 -0400 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6P6KpQ29182; Tue, 25 Jul 2000 08:20:51 +0200 (MEST) Received: from E00D05905E94A.eed.ericsson.se (dhcp4-86 [164.48.140.86]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id IAA02861; Tue, 25 Jul 2000 08:20:49 +0200 (MET DST) Message-Id: <4.3.2.7.0.20000725080715.00ac1cc0@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Jul 2000 08:19:36 +0200 To: Vernon Schryver From: Reiner Ludwig Subject: Re: Comments to "Advice for Internet Subnetwork Designers" Cc: pilc@grc.nasa.gov In-Reply-To: <200007241401.e6OE1nr08870@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 08:01 24.07.00 -0600, Vernon Schryver wrote: >Why can't wireless links use the RFC 1349 values? Aren't those >4 values supposed to be grandfathered? As mentioned a number of times before: RFC1349 is obsoleted by RFC2474, even if BSD still uses it. >Why can't you trust that people who aren't stupid will configure their >routers to translate the DS values they use inside their networks to mean >low-delay or high throughput back to 0x10 and 0x08 as packets leave their >networks? Somebody with a "gold card subscription" from her/his ISP will have the same DSCP on all of her/his flows independent of whether its ftp, telnet, or streaming media. So the last-hop router at the wireless link would have a hard time figuring out the right TOS values. I assume that DSCPs will often have little to do with application layer QoS requirements but much more with how much you are willing to pay for your traffic. ///Reiner From owner-pilc@lerc.nasa.gov Tue Jul 25 09:05: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 ESMTP id JAA08153 for ; Tue, 25 Jul 2000 09:05:34 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA26590 for pilc-outgoing; Tue, 25 Jul 2000 06:38:14 -0400 (EDT) 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 GAA26572 for ; Tue, 25 Jul 2000 06:38:08 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id GAA13514; Tue, 25 Jul 2000 06:38:07 -0400 Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013491; Tue, 25 Jul 00 06:38:03 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24567; Tue, 25 Jul 2000 06:38:00 -0400 (EDT) Message-Id: <200007251038.GAA24567@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-03.txt Date: Tue, 25 Jul 2000 06:38:00 -0400 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 Filename : draft-ietf-pilc-pep-03.txt Pages : 40 Date : 24-Jul-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-03.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-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-pep-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000724142555.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-pep-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-pep-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000724142555.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Tue Jul 25 09:21:55 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 ESMTP id JAA13404 for ; Tue, 25 Jul 2000 09:21:54 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA26589 for pilc-outgoing; Tue, 25 Jul 2000 06:38:14 -0400 (EDT) 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 GAA26570 for ; Tue, 25 Jul 2000 06:38:08 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id GAA13504; Tue, 25 Jul 2000 06:38:06 -0400 Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013472; Tue, 25 Jul 00 06:37:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24509; Tue, 25 Jul 2000 06:37:55 -0400 (EDT) Message-Id: <200007251037.GAA24509@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-04.txt Date: Tue, 25 Jul 2000 06:37:55 -0400 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-04.txt Pages : 15 Date : 24-Jul-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-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-slow-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-slow-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: <20000724142546.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-slow-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-slow-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000724142546.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Tue Jul 25 09:24:25 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 ESMTP id JAA14047 for ; Tue, 25 Jul 2000 09:24:25 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA26591 for pilc-outgoing; Tue, 25 Jul 2000 06:38:14 -0400 (EDT) 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 GAA26568 for ; Tue, 25 Jul 2000 06:38:07 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id GAA13498; Tue, 25 Jul 2000 06:38:06 -0400 Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013468; Tue, 25 Jul 00 06:37:51 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24469; Tue, 25 Jul 2000 06:37:49 -0400 (EDT) Message-Id: <200007251037.GAA24469@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-error-04.txt Date: Tue, 25 Jul 2000 06:37:48 -0400 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 Links with Errors Author(s) : S. Dawkins, G. Montenegro, M. Kojo, V. Magret, N. Vaidya Filename : draft-ietf-pilc-error-04.txt Pages : 18 Date : 24-Jul-00 The rapidly-growing Internet is being accessed by an increasingly wide range of devices over an increasingly wide variety of links. At least some of these links do not provide the reliability that hosts expect, and this expansion into unreliable links causes some Internet protocols, especially TCP [RFC793], to perform poorly. Specifically, TCP congestion avoidance procedures [RFC2561], while appropriate for connections that lose traffic primarily because of congestion and buffer exhaustion, interact badly with connections that traverse links with high uncorrected error rates. The result is that senders may spend an excessive amount of time waiting on acknowledgements that aren't coming, whether these losses are due to data losses in the forward path or acknowledgement losses in the return path, and then, although these losses are not due to congestion-related buffer exhaustion, the sending TCP then transmits at substantially reduced traffic levels as it probes the network to determine A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-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-error-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-error-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: <20000724142537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-error-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-error-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000724142537.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Wed Jul 26 19:31: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 ESMTP id TAA25108 for ; Wed, 26 Jul 2000 19:31:33 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA06945 for pilc-outgoing; Wed, 26 Jul 2000 18:23:49 -0400 (EDT) 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 SAA06925 for ; Wed, 26 Jul 2000 18:23:47 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA26127; Wed, 26 Jul 2000 18:23:46 -0400 Received: from mail.ececs.uc.edu(129.137.8.2) by seraph3.lerc.nasa.gov via smap (V5.5) id xma026093; Wed, 26 Jul 00 18:23:29 -0400 Received: from wayward.ececs.uc.edu (wayward.ececs.uc.edu [129.137.9.117]) by babbage.ececs.uc.edu (8.10.2/8.10.2) with ESMTP id e6QMNPL16675 for ; Wed, 26 Jul 2000 18:23:26 -0400 (EDT) From: Samir Das Received: (from sdas@localhost) by wayward.ececs.uc.edu (8.9.3+Sun/8.9.1) id SAA25732 for pilc@grc.nasa.gov; Wed, 26 Jul 2000 18:22:45 -0400 (EDT) Message-Id: <200007262222.SAA25732@wayward.ececs.uc.edu> Subject: Final Call for Participation: MobiCom 2000, Aug 6-11, Boston To: pilc@grc.nasa.gov Date: Wed, 26 Jul 2000 18:22:45 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Final Call for Participation MobiCom 2000 The Sixth Annual International Conference on Mobile Computing and Networking August 6 - 11, 2000 Seaport Hotel at World Trade Center Boston Boston, Massachusetts, USA The complete program for paper, panel and tutorial sessions, as well as registration and hotel information are available at the conference web site below. http://www.research.telcordia.com/mobicom2000/ Come, celebrate the wireless revolution and its convergence with the Internet, on Boston's historic waterfront. We look forward to seeing you in MobiCom 2000. Registration by mail or fax will be accepted until July 31. Registrations beyond this date will be accepted on site only. From owner-pilc@lerc.nasa.gov Sat Jul 29 14:19:18 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 ESMTP id OAA29182 for ; Sat, 29 Jul 2000 14:19:18 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA19336 for pilc-outgoing; Sat, 29 Jul 2000 13:03:53 -0400 (EDT) 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 MAA18625; Sat, 29 Jul 2000 12:43:03 -0400 (EDT) From: callback123@altavistausa.com Received: by seraph3.lerc.nasa.gov; id MAA05372; Sat, 29 Jul 2000 12:43:02 -0400 Received: from max1-3.newyork.corecomm.net(209.81.238.131) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005322; Sat, 29 Jul 00 12:42:27 -0400 Subject: Re: From Lorraine,as promised,I can lower your bill Date: Sat, 29 Jul 2000 13:38:49 Message-Id: <775.204003.395214@altavistausa.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Apparently-To: Apparently-To: Apparently-To: Apparently-To: Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Untitled Document


Today, everyone knows the impact of the Internet.
But not everyone nows how to cut their phone bill in 1/2. Just a Few examples!!!!

Uk $.04     France $.06    UAE  $.31    Saudi Arabia $.59     Denmark $.04      Sweden $.05

Click Here Now.

If you do not have flash please go to
www.macromedia.com
to download it.

From owner-pilc@lerc.nasa.gov Sun Jul 30 21:38:09 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 ESMTP id VAA28454 for ; Sun, 30 Jul 2000 21:38:09 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA29011 for pilc-outgoing; Sun, 30 Jul 2000 20:13:01 -0400 (EDT) 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 UAA28999 for ; Sun, 30 Jul 2000 20:12:54 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA22214; Sun, 30 Jul 2000 20:12:53 -0400 Received: from wired-129-113.ietf.marconi.com(147.73.129.113) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022186; Sun, 30 Jul 00 20:12:14 -0400 Received: from karn by patty.ka9q.ampr.org with local (Exim 3.12 #1 (Debian)) id 13IxA0-0000eY-00; Sun, 30 Jul 2000 10:46:00 -0700 From: Phil Karn To: Reiner.Ludwig@ericsson.com CC: gja@dnrc.bell-labs.com, pilc@grc.nasa.gov, karn@ka9q.ampr.org In-reply-to: <4.3.2.7.0.20000721112423.00af8af0@chapelle.ericsson.se> (message from Reiner Ludwig on Fri, 21 Jul 2000 13:44:16 +0200) Subject: Re: Comments to "Advice for Internet Subnetwork Designers" References: <4.3.2.7.0.20000719150341.00b3bef0@chapelle.ericsson.se> <4.3.2.7.0.20000720140709.00b6cb60@chapelle.ericsson.se> <4.3.2.7.0.20000721081744.00d1c780@chapelle.ericsson.se> <4.3.2.7.0.20000721112423.00af8af0@chapelle.ericsson.se> Reply-To: karn@qualcomm.com Message-Id: Date: Sun, 30 Jul 2000 10:46:00 -0700 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >I (as a link layer designer) would like to use a flow's DSCP *not only* to >control scheduling and/or queue management algorithms at the network layer, >but *also* to control link layer error control algorithms. Exactly. Information theory says there are fundamental tradeoffs between delay and throughput, and it would be nice for the link layer to have some guidance in making these tradeoffs. The main parameter is the FEC interleaver blocksize. Larger blocksizes yield better performance, especially over fading channels, but they increase delay. So something that can tell the physical layer what size FEC block to use would be very helpful. [The idea that larger blocks perform better over noisy channels may seem strange to those unfamiliar with coding theory. If you think that larger blocks would have a larger probability of at least one error, you're right. That's why, on *uncoded* channels, high error rates dictate smaller blocks. But with interleaved FEC, it's not whether there are *any* errors in the block, but whether their number exceeds some correction limit. With uncorrelated channel errors, the number of errors in any given block follows a binomial distribution; as blocksize is increased, this becomes a gaussian distribution. Thanks to the law of large numbers, the standard deviation of this distribution increases only as the square root of the blocksize. So the probability that the code will fail, i.e., be overwhelmed by errors, goes to zero as the blocksize approaches infinity *provided* that the expected number of errors in a block is within the code's error correction capability.] This has gotten me thinking about how TOS should really work in a wireless link. When you think about it, the old-style qualitative TOS bits that meant "low delay" "high throughput" or "high reliability" are really not that orthogonal. Ultimately the *only* link/subnet characteristic that ever really matters is LATENCY. "High throughput" is important only insofar as it reduces latency due to queuing delay, and "high reliability" is important only as it decreases (or avoids) the latency of an end-to-end retransmission scheme. In every situation, the goal is the same: to complete a "transaction" as quickly as possible. This suggests that all the link layer ever *really* wants to know is the application transaction size. Two examples: A bulk file transfer is a single "large" transaction, i.e., one that will take many packets to complete. We assume that just having part of the file is useless, so we want to finish the whole thing as quickly as possible. And we assume the file to be much larger than the bandwidth*delay product of the available network path, so propagation delays have a small effect on the transaction latency. Here the link can be allowed to operate on the data in large chunks, e.g, by using large FEC code blocks that could possibly span many IP packets. This will increase throughput on a noisy channel and allow the transaction to complete more quickly -- thus reducing "latency" by this particular application's definition. At the other extreme, an interactive session is really a series of "small" transactions. Each transaction typically fits into a single IP packet and must be delivered before the other end can continue. The transactions may also be small relative to the bandwidth*delay product of the available network paths. In this case, reducing "latency" implies getting each packet out as quickly as possible, even if it means having to use a less efficient FEC, i.e., one with a smaller blocksize and more overhead to keep an acceptable probability of loss. So what about a "TOS" field that simply indicates how many IP packets make up this application's transaction size? While the analogy isn't perfect, think of it as a distant cousin of the TCP "push" bit, which was originally defined to permit implementations to gain efficiency by aggregating data when immediate delivery wasn't necessary. I know that redefining the IP TOS fields may be beyond the scope of our charter, but I've been mulling it over for quite some time and I wanted to get this idea out there to stimulate some discussion because it does connect directly to our discussion of what performance-tuning "knobs" a link/subnetwork should provide to IP and how applications could use them. Phil From owner-pilc@lerc.nasa.gov Mon Jul 31 09:50: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 ESMTP id JAA08334 for ; Mon, 31 Jul 2000 09:50:03 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA07815 for pilc-outgoing; Mon, 31 Jul 2000 08:43:31 -0400 (EDT) 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 IAA07790 for ; Mon, 31 Jul 2000 08:43:28 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id IAA12609; Mon, 31 Jul 2000 08:43:27 -0400 Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012545; Mon, 31 Jul 00 08:42:32 -0400 Received: from esealnt406.al.sw.ericsson.se (esealnt406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6VCgUQ12988 for ; Mon, 31 Jul 2000 14:42:30 +0200 (MEST) Received: from SMTP ([153.88.251.29]) by esealnt406.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Mon, 31 Jul 2000 14:42:29 +0200 Received: from esealnt743.al.sw.ericsson.se ([153.88.251.13]) by 153.88.251.29 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 31 Jul 2000 12:42:29 0000 (GMT) Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Mon, 31 Jul 2000 14:41:14 +0200 Message-ID: <5E5172B4DE05D311B3AB0008C75DA941019EF683@edeacnt100.eed.ericsson.se> From: "Michael Meyer (EED)" To: "'karn@qualcomm.com'" Cc: pilc@grc.nasa.gov Subject: RE: Comments to "Advice for Internet Subnetwork Designers" Date: Mon, 31 Jul 2000 14:42:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 31 Jul 2000 12:42:29.0939 (UTC) FILETIME=[CA16F030:01BFFAEC] Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Hi Phil, In general I like your proposal to provide more information to the link layer. > >>I (as a link layer designer) would like to use a flow's DSCP >*not only* to >>control scheduling and/or queue management algorithms at the >network layer, >>but *also* to control link layer error control algorithms. > >Exactly. Information theory says there are fundamental tradeoffs >between delay and throughput, and it would be nice for the link layer >to have some guidance in making these tradeoffs. > >The main parameter is the FEC interleaver blocksize. Larger blocksizes >yield better performance, especially over fading channels, but they >increase delay. So something that can tell the physical layer what >size FEC block to use would be very helpful. > There are some more parameters like e.g. FEC code rate and transmission power. >[The idea that larger blocks perform better over noisy channels may >seem strange to those unfamiliar with coding theory. If you think that >larger blocks would have a larger probability of at least one error, >you're right. That's why, on *uncoded* channels, high error rates >dictate smaller blocks. But with interleaved FEC, it's not whether >there are *any* errors in the block, but whether their number exceeds >some correction limit. With uncorrelated channel errors, the number of >errors in any given block follows a binomial distribution; as >blocksize is increased, this becomes a gaussian distribution. Thanks >to the law of large numbers, the standard deviation of this >distribution increases only as the square root of the blocksize. So >the probability that the code will fail, i.e., be overwhelmed by >errors, goes to zero as the blocksize approaches infinity *provided* >that the expected number of errors in a block is within the code's >error correction capability.] I think that your explanation regarding the coding theory might lead some into the wrong direction. What you describe in your "tutorial" is an ideal scenario. The mobile radio channel is different and therefore infinite blocks lenghts are far from ideal. The mobile radio channel can be described by a so-called coherence time, which is a measure for the duration during which the channel is correlated. Interleaving is trying to move coded bits describing the same info bit further apart than the coherence time. If that is achieved there is no further gain by increasing the interleaving. Interleaving does help to reduce the bit error rate for a channel, but for a given bit error rate, the block error rate is increasing with increasing block length. Thus, there exists an optimal block size. It has to be large enough for efficient interleaving, but small enough for a low block error rate. > >This has gotten me thinking about how TOS should really work in a >wireless link. When you think about it, the old-style qualitative TOS >bits that meant "low delay" "high throughput" or "high reliability" >are really not that orthogonal. Ultimately the *only* link/subnet >characteristic that ever really matters is LATENCY. "High throughput" >is important only insofar as it reduces latency due to queuing delay, >and "high reliability" is important only as it decreases (or avoids) >the latency of an end-to-end retransmission scheme. In every >situation, the goal is the same: to complete a "transaction" as >quickly as possible. > >This suggests that all the link layer ever *really* wants to know is >the application transaction size. Two examples: > >A bulk file transfer is a single "large" transaction, i.e., one that >will take many packets to complete. We assume that just having part >of the file is useless, so we want to finish the whole thing as >quickly as possible. And we assume the file to be much larger than the >bandwidth*delay product of the available network path, so propagation >delays have a small effect on the transaction latency. > >Here the link can be allowed to operate on the data in large chunks, >e.g, by using large FEC code blocks that could possibly span many IP >packets. This will increase throughput on a noisy channel and allow >the transaction to complete more quickly -- thus reducing "latency" by >this particular application's definition. Besides the negative impacts of increased delays for TCP slow start, increasing the interleaving delay might be harmful, because TCP has this bias for connections with a large RTT. This is for me another reason for not having large interleaving blocks. I don't see big advantages of having many IP packets in one FEC code block for the reasons I explained above. But I do completely agree that the link layer needs more information to perform its job in the best possible way. /Michael ****************** Michael Meyer Ericsson Research From owner-pilc@lerc.nasa.gov Mon Jul 31 12:05:13 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 ESMTP id MAA01355 for ; Mon, 31 Jul 2000 12:05:10 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA02716 for pilc-outgoing; Mon, 31 Jul 2000 10:55:51 -0400 (EDT) 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 KAA02691 for ; Mon, 31 Jul 2000 10:55:48 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA28036; Mon, 31 Jul 2000 10:55:47 -0400 Received: from wireless-132-254.ietf.marconi.com(147.73.132.254) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027971; Mon, 31 Jul 00 10:54:56 -0400 Received: (from karn@localhost) by patty.ka9q.ampr.org (8.9.3/8.9.3/Debian 8.9.3-21) id HAA01073; Mon, 31 Jul 2000 07:54:32 -0700 Date: Mon, 31 Jul 2000 07:54:32 -0700 Message-Id: <200007311454.HAA01073@patty.ka9q.ampr.org> From: Phil Karn To: Michael.Meyer@eed.ericsson.se Reply-To: karn@qualcomm.com CC: pilc@grc.nasa.gov In-reply-to: <5E5172B4DE05D311B3AB0008C75DA941019EF683@edeacnt100.eed.ericsson.se> (Michael.Meyer@eed.ericsson.se) Subject: Re: Comments to "Advice for Internet Subnetwork Designers" References: <5E5172B4DE05D311B3AB0008C75DA941019EF683@edeacnt100.eed.ericsson.se> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >There are some more parameters like e.g. FEC code rate and transmission power. Correct. I was assuming these were held constant. >The mobile radio channel can be described by a so-called coherence >time, which is a measure for the duration during which the channel is >correlated. Interleaving is trying to move coded bits describing the >same info bit further apart than the coherence time. If that is >achieved there is no further gain by increasing the interleaving. You got me -- I was oversimplifying too much. I should have said "channel code block size" rather than "interleaving block size". The channel code can be a layered combination of one or more FEC code elements and interleaving. The interleaving may be 1) explicit, 2) an internal element of a particular code (e.g., a turbo code), or 3) an implicit property of a large block code, e.g., Reed-Solomon. All that matters is that the user data bits are effectively "spread" over the entire channel code block to effectively deal with channel burst errors. So assuming that the parameters of each element making up the channel code are optimally chosen, you can always do better with a larger channel code block size. Yes, you do reach a point of diminishing returns with increasing channel block size, both against Gaussian noise and against fading. But the improvement is always monotonically increasing with block size. The diminishing returns point usually occurs first against Gaussian noise. For modern codes, this is on the order of one or more kilobits. (The turbo code in the Qualcomm HDR forward link uses a 128 byte block size). This leaves channel fading. Here the point of diminishing returns depends heavily on the channel, specifically the coherence time just as you say. The usual rule of thumb is that you want a code block transmission time that is at least 10x the coherence time. This can be a *very* large number when you're transmitting at high speed on a slowly fading channel. At some point, it's more practical to layer ARQ above the FEC and just keep trying until the channel fade ends and the FEC can again deal with it. The FEC/ARQ tradeoff point depends on factors like the round trip delay of the channel and the per-packet ARQ overhead. The larger the FEC channel block size, the lower the overhead of the ARQ header. Also, if a larger FEC block size can reduce the ARQ retransmission rate, the higher layer protocols reap the benefit of decreased delay variance. What I'm saying is that it would be nice to at least give the physical layer the opportunity to aggregate relatively large chunks of user data, possibly comprising several IP packets, if the physical layer decides that would improve performance over a slow fading channel, and if the application can deal with the increased short-term latency. >Besides the negative impacts of increased delays for TCP slow start, >increasing the interleaving delay might be harmful, because TCP has >this bias for connections with a large RTT. This is for me another >reason for not having large interleaving blocks. I don't quite understand this. My experience is that TCP adapts quite well to large RTTs, especially if the RTTs are stable and the packet loss rate is low. TCP window scaling is now pretty widely deployed, although it may have to be enabled. 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. Consider a physical layer with a long latency and link layer ARQ. Most packets go through without link level ARQ, so most of the time the RTT is consistent and TCP shrinks its RTO to just above the RTT. But whenever the link layer retransmits, the RTT spikes and there's a spurious TCP retransmission. If link level retransmissions are rare, then spurious TCP retransmissions are also rare and their effect on performance is minimal. If link level retransmissions are very frequent, TCP sees a high RTT variance and sets an RTO that is well above the average value. Again, spurious TCP retransmissions are rare. But things can degrade badly in the intermediate region, say, every 10th packet. Just when TCP has dropped its RTO to just above the average RTT, another link level retransmission occurs and causes TCP to spuriously retransmit. Perhaps we could build a better (higher order) RTT model into TCP, or tune its existing parameters better. But I think it would be better to fix the physical layers to work better with TCP as it currently stands. Phil From owner-pilc@lerc.nasa.gov Mon Jul 31 12:19:08 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 ESMTP id MAA04506 for ; Mon, 31 Jul 2000 12:19:05 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA04997 for pilc-outgoing; Mon, 31 Jul 2000 11:06:06 -0400 (EDT) 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 LAA04943 for ; Mon, 31 Jul 2000 11:06:01 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA29193; Mon, 31 Jul 2000 11:06:01 -0400 Received: from c017-h015.c017.sfo.cp.net(209.228.12.229) by seraph3.lerc.nasa.gov via smap (V5.5) id xma029146; Mon, 31 Jul 00 11:05:16 -0400 Received: (cpmta 13198 invoked from network); 31 Jul 2000 08:02:10 -0700 Received: from dns.packetdesign.net (HELO mailman.packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 31 Jul 2000 08:02:10 -0700 X-Sent: 31 Jul 2000 15:02:10 GMT Received: from packetdesign.com ([192.168.0.254]) by mailman.packetdesign.com (8.9.3/8.9.3) with ESMTP id IAA19221; Mon, 31 Jul 2000 08:01:47 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <398598BE.1162C4D1@packetdesign.com> Date: Mon, 31 Jul 2000 08:18:22 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: karn@qualcomm.com CC: pilc@grc.nasa.gov, karn@ka9q.ampr.org Subject: Re: Comments to "Advice for Internet Subnetwork Designers" References: <4.3.2.7.0.20000719150341.00b3bef0@chapelle.ericsson.se> <4.3.2.7.0.20000720140709.00b6cb60@chapelle.ericsson.se> <4.3.2.7.0.20000721081744.00d1c780@chapelle.ericsson.se> <4.3.2.7.0.20000721112423.00af8af0@chapelle.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Phil Karn wrote: > ... > So what about a "TOS" field that simply indicates how many IP packets > make up this application's transaction size? While the analogy isn't > perfect, think of it as a distant cousin of the TCP "push" bit, which > was originally defined to permit implementations to gain efficiency by > aggregating data when immediate delivery wasn't necessary. > > I know that redefining the IP TOS fields may be beyond the scope of > our charter, but I've been mulling it over for quite some time and I > wanted to get this idea out there to stimulate some discussion because > it does connect directly to our discussion of what performance-tuning > "knobs" a link/subnetwork should provide to IP and how applications > could use them. > Phil, Since the diffserv effort has only recently redefined the IP TOS fields and was (and is) chartered to do so, I suspect that you are quite right that it is out of charter for PILC. On the other hand, it may be quite resonable to define a PHB Group in PILC. Perhaps you should first determine that what you want to do is impossible in that framework before rechartering PILC and deep-sixing RFCs2474/5, RFCx2597/8? regards, Kathie From owner-pilc@lerc.nasa.gov Mon Jul 31 12:41:49 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 ESMTP id MAA08041 for ; Mon, 31 Jul 2000 12:41:46 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA10049 for pilc-outgoing; Mon, 31 Jul 2000 11:29:44 -0400 (EDT) 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 LAA10014 for ; Mon, 31 Jul 2000 11:29:42 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA02150; Mon, 31 Jul 2000 11:29:38 -0400 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002102; Mon, 31 Jul 00 11:29:24 -0400 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13JHUo-0003Qw-00; Mon, 31 Jul 2000 16:28:50 +0100 Date: Mon, 31 Jul 2000 16:28:47 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: karn@qualcomm.com cc: Michael.Meyer@eed.ericsson.se, pilc@grc.nasa.gov Subject: Re: Comments to "Advice for Internet Subnetwork Designers" In-Reply-To: <200007311454.HAA01073@patty.ka9q.ampr.org> 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 Mon, 31 Jul 2000, Phil Karn wrote: > >Besides the negative impacts of increased delays for TCP slow start, > >increasing the interleaving delay might be harmful, because TCP has > >this bias for connections with a large RTT. This is for me another > >reason for not having large interleaving blocks. bias _against_ connections with a large RTT when they're competing in a pipe against connections with smaller RTTs which adapt faster to changes. Up the overall RTT of your TCP connections by interleaving, and expect them to do less well against other connections. > I don't quite understand this. My experience is that TCP adapts quite > well to large RTTs, especially if the RTTs are stable and the packet > loss rate is low. TCP window scaling is now pretty widely deployed, > although it may have to be enabled. L. PGP