From owner-pilc@lerc.nasa.gov Fri Nov 3 18:14: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 SMTP id SAA25496 for ; Fri, 3 Nov 2000 18:14:54 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA13488 for pilc-outgoing; Fri, 3 Nov 2000 17:19:35 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA13468 for ; Fri, 3 Nov 2000 17:19:32 -0500 (EST) From: hv@of-hachetal.de Received: by seraph3.lerc.nasa.gov; id RAA20006; Fri, 3 Nov 2000 17:19:31 -0500 Received: from unknown(203.127.153.65) by seraph3.lerc.nasa.gov via smap (V5.5) id xma019955; Fri, 3 Nov 00 17:18:59 -0500 Received: from [63.30.197.239] by inforack.cdac.org.sg (NTMail 3.03.0014/1f.aaac) with ESMTP id sa378110 for ; Sat, 4 Nov 2000 06:26:32 +0800 To: hv@of-hachetal.de Subject: At last, Herbal V, the all natural alternative to V----A! Date: Sat, 4 Nov 2000 06:26:31 +0800 Message-Id: <22263152420759@cdac.org.sg> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Herbal V: An Incredible All-Natural Healthy Alternative Herbal V is the All Natural Approach to Male Virility, Vitality and Pleasure. Available N o w ! Welcome to the New Sexual Revolution. It's the all natural male potency and pleasure pill that men everywhere are buzzing about. Herbal V is safe, natural and specifically formulated to help support male sexual function and pleasure. You just take two easy-to-swallow tablets one hour before sex. And there's more great news - you can get Herbal V for less than $1 a pill. Amazing word of mouth praise on Herbal V has been spreading like wildfire-already over 1,500,000 men have chosen Herbal V. Since it is 100% natural you will never have to worry about safety. Try doctor-recommended Herbal V today and have the greatest night of your life! Herbal V... Bringing Back the Magic! 1,585,000 men can't be wrong. To date over 1 million men have tried the super supplement Herbal V. Here is why: No Doctor Visit Required Available Over the Counter Not a Drug 100% Natural Safe, No Worries Highest Quality Pharmaceutical-Grade Pure Nutriceuticals Guaranteed Potency & Purity Be a Real Man Again! Questions and Answers What is Herbal V? Herbal V is a proprietary blend that was specifically developed as a safe alternative for men who prefer an all-natural approach to address impotence and boost sexual performance. This amazing formula first became popular with Hollywood insiders and the wealthy elite. They were maximizing their sex lives, long before it was available to the general public. How does Herbal V work? Developed by a team whose goal was to create the perfect all-natural aphrodisiac. Herbal V is the result of that remarkable effort. The Herbal V formula contains a precise blend of cutting edge pro-sexual nutrients from around the world that provide nutritional support, making it possible for a man to have a pleasurable sexual experience. What can Herbal V do for me? Herbal V helps support male sexual function and pleasure in a safe and natural manner. Simply put, it can make your sex life incredible. Is Herbal V Safe? One of the great things about Herbal V is that it is not a drug. It is an incredible herbal dietary supplement that provides nutritional support for male sexual function and pleasure. One of the most comforting features of Herbal V is that you never have to worry about safety. Herbal V: Safe - Natural - Exciting Many have speculated that because Herbal V is so popular with men, it must contain prescription drugs or chemical components. Herbal V does not contain any elements or traces of any prescription drug. Herbal V is made using the world's most technologically advanced state-of-the-art cold processing equipment to ensure maximum purity. Herbal V has been independently analyzed by the nation's premier testing facility to ensure purity, quality and to end the rumors that, because it is so popular, it must somehow be chemical. It is not. Herbal V is natural - just as it says on the label. Herbal V is simply fantastic! Herbal V: Ingredients Yohimbe, saw palmetto, avena sativa, androstenedione, guarana, taurine, siberian ginseng, tribulus terrestris. Tribulus Terrestis is certified to enhanced testosterone levels by increasing Luteinzing hormone (LH) levels. Androstenedione which is a precursor to testosterone unlocks bound testosterone and makes it biologically active again quickly. This means a dramatic surge in desire. Avena Sativa Stimulates the neurotransmitter pleasure centers to maximum capacity. This greatly intensifies pleasure. Just listen to what Herbal V has done for the sex lives of people like you! “On a scale of 1 to 10, it's a 15. Electrifying. It's like a wonder pill!” — Justin Q B., New Haven, Texas “I haven't had sexual relations in 11 years. Then with Herbal V it was... wow! It works again!” — Sid R., Lakeland, Florida “I had sex four times in one night. It made me feel like a 19-year-old again.” — Chip S, Beech Mountain, North Carolina “Herbal V has turned my husband into a Sexual Superman! I like the fact that it's all natural and has no side effects. It's bringing back the good old days.” — Jennifer B, Beverly Hills, California The above testimonials are from product literature, and we have not independently verified them. However, the following testimonial is from a "senior" gentleman who has purchased his second bottle of Herbal V. When we heard his words with our own ears, we asked his permission to print them here. “Man! I'm wild as I can be! I feel like I'm 25 years old again! I'm not believing this!” — Mr. Murphy, age 64, Lampart, IL. Risk Free: Double Your Money Back Guarantee If Herbal V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked ! Order Now: Safe, Fast, Secure, Private Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Herbal V contains 30 tablets, approximately a 1 month supply. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Herbal V $28 ______ 2 Bottles of Herbal V $48 ______ 3 Bottles of Herbal V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ] International Orders Please add $16 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$44, 2 bottles=$64, 3 bottles=$75 ] We cannot accept foreign checks. International money orders or credit cards only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 3502 N. Powerline Rd. #525 Pompano Beach, FL 33069 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Herbal V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Herbal V helps provide herbal and nutritional support for male sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From owner-pilc@lerc.nasa.gov Tue Nov 7 06:46:53 2000 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20433 for ; Tue, 7 Nov 2000 06:46:53 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA29292 for pilc-outgoing; Tue, 7 Nov 2000 05:41:44 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id FAA29281 for ; Tue, 7 Nov 2000 05:41:43 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id FAA11172; Tue, 7 Nov 2000 05:41:41 -0500 Received: from swan.prod.itd.earthlink.net(207.217.120.123) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011146; Tue, 7 Nov 00 05:41:31 -0500 Received: from vaio (hsa072.pool013.at001.earthlink.net [216.249.76.72]) by swan.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id CAA04673 for ; Tue, 7 Nov 2000 02:41:28 -0800 (PST) From: "Shirley Tseng" To: Subject: Space Internet Workshop Nov 13-15, 2000 Date: Tue, 7 Nov 2000 02:43:55 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit The First Joint Space Internet Workshop NASA Goddard Space Flight Center Greenbelt, Maryland November 13 - 16, 2000 http://siw.gsfc.nasa.gov/ The workshop is free of charge. This should make it simpler and easier for everyone, including civil servants, to attend. Pre-registration via the workshop web site (http://siw.gsfc.nasa.gov) is highly encouraged. Note that, as stated in the workshop announcement (which is accessible on the web site), participants are responsible for their own travel and living accommodations. SCOPE The Science, Engineering, and Standards communities are pleased to announce the first of a series of Space Internet Workshops. This series will address all issues related to Internet or Internet-like communication protocols in space environments. The vision is to bring together and integrate the Internet, the Consultative Committee for Space Data Systems, and any other applicable protocol suites, to enable transparent end-to-end Internet (or future Internet) communications to space missions resources. Communications within and between the various space environments are included. The purpose of this first workshop is to foster broadly based, comprehensive discussion of cost-effective technical solutions for the design and engineering of mission communications. The goal is to develop an understanding of the technical "territory" and to plan for working the issues in future workshops. The first workshop seeks to bring forth results and information that will help to: 1. Describe the science drivers and requirements with respect to communications and information exchange 2. Define and characterize the different communication domains for space applications 3. Identify and explore the currently available and proposed technical approaches 4. Map the technical approaches onto the operational domains 5. Identify areas where solutions do exist and areas where further study, analysis, or development is needed All types of missions * robotic and manned missions * scientific, military, and commercial spacecraft * constellations, formation-flying missions, and single nodes * nano- and micro-, and macro-satellites * relay satellites * buoys, balloons, and aircraft * planetary rovers and "space" environments, for example: * Local or Wired * In Situ * Severely Resource Constrained * Nearby * Circum-planetary * Deep Space are of interest. Issues and solutions related to space and ground systems and operations as well as mission design and implementation will be under consideration. Draft Agenda >--------------------------------------------------------------------------- -- > > -------- DRAFT -------- > > Monday Tuesday Wednesday > 13 November 14 November 15 November > ------------------------------------------------------------------------ --- > | 8:00 | | | | > | 8:30 | Register | | | > | 9:00 | Welcome | Invited - Space | Invited - Earth | > | 9:10 | Keynote - Fred Baker| | Ed Torres-Martinez | > | 9:40 | | Security - 20 | Protocols - 11 | > | 10:00 | Panel / Discussion | Security - 8 | Protocols - 1 | > | 10:20 | Applications in | Security - 9 | Protocols - 24 | > | 10:40 | Space Missions | Break / Discussion | Protocols - 31 | > | 11:00 | | Protocols - 21 | Break / Discussion | > | 11:20 | - Kul Bhasin - | Protocols - 5 | Architecture - 13 | > | 11:40 | | Protocols - 12 | Architecture - 35 | > | 12:00 | Lunch / Discussion | Lunch / Discussion | Lunch / Discussion | > | 12:20 | ... | ... | ... | > | 12:40 | ... | ... | ... | > | 1:00 | Experiments - 3 | Experiments - 28 | Experiments - 17 | > | 1:20 | Experiments - 23 | Experiments - 15 | Experiments - 26 | > | 1:40 | Experiments - 27 | Experiments - 33 | Experiments - 16 | > | 2:00 | Experiments - 7 | Experiments - 4 | Experiments - 32 | > | 2:20 | Break / Discussion | Break / Discussion | Break / Discussion | > | 2:40 | Operations - 10 | Operations - 22 | Panel / Discussion | > | 3:00 | Operations - 29 | Operations - 38 | State of Network | > | 3:20 | Operations - 25 | Operations - 37 | in Space Missions | > | 3:40 | Break / Discussion | Operations - 34 | (Protocols & | > | 4:00 | Architecture - 2 | Break / Discussion | Security) | > | 4:20 | Architecture - 30 | Architecture - 14 | | > | 4:40 | Architecture - 6 | Architecture - 19 | Wrap up | > | 5:00 | Architecture - 36 | Architecture - 18 | | > | 5:20 | Discussion | Discussion | | > | 5:40 | | | | > | 6:00 | | | | > ------------------------------------------------------------------------ --- > > > >--------------------------------------------------------------------------- --- > > 1 Protocols - > A New Multicast Routing Scheme for IP-Based LEO Satellite Networks > Ian F. Akyildiz Georgia Tech > Eylem Ekici Georgia Tech > Michael D. Bender Department of Defense > > > 2 Architecture - > Payload IP Networking With The Improved Space Architecture Concept > Dr. Carl J. Beckmann Sanders > Michael Harris Sanders > > 3 Experiments - > Internet communications for planetary exploration. > Stephen Braham Simon Fraser University > Peter Anderson Simon Fraser University > Richard Alena NASA Ames Research Center > Brian Glass NASA Ames Research Center > Pascal Lee SETI/NASA Ames Research Center > > > 4 Experiments - > High Rate TCP Communication over Geo-Stationary Distances > David Brooks Infinite Global Infrastructures > Arun Welch Infinite Global Infrastructures > David Beering Infinite Global Infrastructures > Scott Jakl Lockheed Martin Space Operations > > 5 Protocols - > Transport Protocols and Applications for Internet Use in Space > Ed Criscuolo Computer Sciences Corp > Keith Hogie Computer Sciences Corp > Ron Parise Computer Sciences Corp > > > 6 Architecture - > File Management In Space > Anna R. Critchfield Computer Sciences Corp > Robert H. Zepp Computer Sciences Corp > > > 7 Experiments - > A Testbed for Internet Based Operations > James Cutler Stanford > Bob Twiggs Stanford > > > 8 Security - > IP Security Study for Space Applications > John T. Donohue, NASA/GSFC Code 584 > Anna R. Critchfield Computer Sciences Corp > > > 9 Security - > Endpoint Security Using Biometric Authentication for Secure Remote > Mission Operations > John T. Donohue, NASA/GSFC Code 584 > Anna R. Critchfield Computer Sciences Corp > > >10 Operations - > CHIPSat, 1st NASA UnEx Mission: Satellite Communications Via the Internet > Jason Gracilieri SpaceDev > Simon Dawson SpaceDev > Will Marchant UC Berkeley > Jonathan Wolff SpaceDev > > >11 Protocols - > Link and Routing Issues for Internet Protocols in Space > Keith Hogie Computer Sciences Corp > Ed Criscuolo Computer Sciences Corp > Ron Parise Computer Sciences Corp > > >12 Protocols - > Using a Generic XML Driven Translator for Downlink and Uplink Data > Paula Holmes Motorola > >13 Architecture - > 3G - Wireless Solution > Paula Holmes Motorola > >14 Architecture - > The Potential for Using LEO Telecommunications Constellations to Support > Nanosatellite Formation Flying > Stephen Horan New Mexico State University > > >15 Experiments - > Integrating & Applying Internet Protocols with a Reconfigurable Software > Radio--The Low Power Transceiver > William Horne ITT Industries > David J. Zillig NASA Goddard 567 > Marc Harlacher ITT Industries > > >16 Experiments - > The NASA Space Network Demand Access System: A Building Block Toward the > Space Internet > William Horne ITT Industries > David J. Zillig NASA/GSFC Code 567 > > >17 Experiments - > TDRSS' History as an Internet Service Provider > Dave Israel NASA/GSFC Code 567.3 > > >18 Architecture - > The Ground Station Router Interface Device (GRID) > Dave Israel NASA/GSFC Code 567.3 > > >19 Architecture - > An IP Ground Station Architecture > Dave Israel NASA/GSFC Code 567.3 > >20 Security - > A Basis for Security Utilizing the Internet Protocol for Command and > Telemetry of Spacecrafts > Freemon Johnson III NASA/GSFC Code 584 > James Rash NASA/GSFC Code 588 > > >21 Protocols - > Intersatellite Links: Lower Layer Protocols for Autonomous Constellations > Kerri Kusza Princeton Satellite Systems > Mike Paluszek Princeton Satellite Systems > > >22 Operations - > Operations Concepts Enabled by Cooperating Internet Spacecraft > Jim Langston Computer Sciences Corp > > >23 Experiments - > Use of the Internet to expedite early integration on CHIPSat > Will Marchant UC Berkeley > Simon Dawson SpaceDev > Jason Gracilieri SpaceDev > Jonathan Wolff SpaceDev > > >24 Protocols - > TCP-Peach: A New Flow Control Scheme for Satellite IP networks. > Giacomo Morabito Georgia Tech > Ian F. Akyildiz Georgia Tech > Sergio Palazzo Georgia Tech > >25 Operations - > "Faster, Better, Cheaper" - Benefits of Internet Protocols in Space > Ron Parise Computer Sciences Corp > Keith Hogie Computer Sciences Corp > Ed Criscuolo Computer Sciences Corp > Jim Langston Computer Sciences Corp > > >26 Experiments - > Demonstrations of Internet Protocols in Space Using TDRSS > James Rash NASA/GSFC Code 588 > Keith Hogie Computer Sciences Corp > Ed Criscuolo Computer Sciences Corp > Ron Parise Computer Sciences Corp > Frank Hallahan Computer Sciences Corp > Thinh Le Computer Sciences Corp > > >27 Experiments - > Results of "Internet in Space" Tests Using the UoSAT-12 Satellite > James Rash NASA/GSFC Code 588 > Keith Hogie Computer Sciences Corp > Ron Parise Computer Sciences Corp > Ed Criscuolo Computer Sciences Corp > Jim Langston Computer Sciences Corp > Chris Jackson Surrey Satellite Technology Ltd > Harold Price VyTek Wireless > > >28 Experiments - > A Study of TCP Mechanisms for Distinguishing Losses Due to Errors vs. > Losses Due to Congestion > Gregory Romaniak Infinite Global Infrastructures > David Beering Infinite Global Infrastructures > Michael Rupar US Naval Research Laboratory > Mark Solsman US Naval Research Laboratory > >29 Operations - > Operations Concepts for the Mars Relay Satellite > Tim Rykowski NASA/GSFC Code 581 > Dave Israel NASA/GSFC Code 567.3 > >30 Architecture - > Flight system architectures using Internet Protocol methods > Richard G Schnurr NASA/GSFC Code 560 > >31 Protocols - > On board flight network development activity at NASA GSFC > Richard G Schnurr NASA/GSFC Code 560 > Glenn Rakow NASA/GSFC Code 561 > Evan Webb NASA/GSFC Code 561 > > >32 Experiments - > Mobile-Router > Dan Shell Cisco System > Will Ivancic NASA Glenn Research Center > > >33 Experiments - > Deployment Tests of COTS Networking Equipment in STS and ISS > Dan Shell Cisco System > Will Ivancic NASA Glenn Research Center > > >34 Operations - > SOMO Commercialization and the Space Internet > Jon M. Smith NASA/JSC > Dan Heimingdinger > > >35 Architecture - > Crosslink Transceiver for Integrated Navigation and Communications in > Distributed Spacecraft Systems > Patrick A. Stadter JHU/APL > > >36 Architecture - > Flight Linux: Enabling Migration of the Internet to Space-Based Systems > Pat Stakem QSS Group, Inc. > >37 Operations - > DoD Satellite Control Directions > Carl A Sunshine Aerospace > > >38 Operations - > An Operations Concept for Internet-based Satellite Instruments > G. Michael Tong NASA/GSFC Code 583 James L. Rash/Code 588 Building 23, Room E403 Advanced Architectures and Automation Branch NASA Goddard Space Flight Center Greenbelt, MD 20771 301-286-5246 (voice) 301-286-1768 (fax) From owner-pilc@lerc.nasa.gov Tue Nov 7 11:07:24 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14087 for ; Tue, 7 Nov 2000 11:07:23 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA29842 for pilc-outgoing; Tue, 7 Nov 2000 10:05:12 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA29796 for ; Tue, 7 Nov 2000 10:05:10 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA10339; Tue, 7 Nov 2000 10:05:09 -0500 Received: from gatekeeper.nera.no(194.19.8.2) by seraph3.lerc.nasa.gov via smap (V5.5) id xma010250; Tue, 7 Nov 00 10:04:14 -0500 Received: from nera.no [137.133.126.26] by nera19.nera.no with ESMTP (SMTPD32-6.00) id A981277402AC; Tue, 07 Nov 2000 16:02:25 +0100 Message-ID: <3A0819A3.CD8B1E51@nera.no> Date: Tue, 07 Nov 2000 16:02:59 +0100 From: Harald Skinnemoen Organization: NERA X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: pilc@grc.nasa.gov Subject: ETSI Request for Input References: Content-Type: text/plain; charset=iso-8859-1 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by lombok-fi.lerc.nasa.gov id KAA29842 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA14087 The European Telecommunications Standards Institute, ETSI, has a Technical Committee, TC-SES, which is responsible for satellite matters. Under TC-SES, a Work Group on Broadband Satellite Multimedia, WG BSM, has been established in July 2000. This WG, of which I am the chairman, is following up on the work started by a Special Task Force (STF) established in 1998 to look into standardization aspects of Broadband Satellite Multimedia. The WG BSM has had its first meeting, with the second coming up next week. One of the work items we are looking at is “IP matters over satellite”. Motivated by a number of different proprietary IP-over-satellite solutions, various considerations described in the excellent PILC documents, and a foreseeable need for different satellite systems to be able to inter-operate in the future as efficiently as possible, we are considering what actions, if any, would be appropriate for ETSI. For example, would there be a use for optimized frame/packet sizes other than the MPEG/ATM solutions? Could these be adaptive based e.g. on QoS requirements and measured link characteristics? Could satellite multicast benefit from a common standard (or specification)? What specific or generic architectures would be worth while considering? The WG BSM has no wish to interfere with study areas that are considered to be the responsibility of the IETF. Rather, we are looking for the possibility of complementing the work of PILC/IETF with work that may be beyond the scope of IETF, yet still within the scope of ETSI/WG BSM. We are also considering a possible co-operation with the TIA of the USA on these issues. If there are within your group any viewpoints on specific issues related to IP-over-satellite that could benefit from having a standard specification across different systems, we would very much welcome such feedback. We are also planning a specific open 'IP-over-satellite' day in Vienna (Austria) in February (dates to be decided) for the purpose of highlighting and discussing these issues, related to standardization. Best regards, /Harald Skinnemoen WG BSM Chairman ETSI -- ------------------------------------------------------------- Dr. Harald Skinnemoen Chief Scientist Nera WBA (Wireless Broadband Access) N-1375 Billingstad NORWAY Email : Harald.Skinnemoen@nera.no Office: (47) 67 24 40 00 Direct: (47) 67 24 36 35 Fax: (47) 66 85 91 15 Web: www.nera.no ------------------------------------------------------------- From owner-pilc@lerc.nasa.gov Wed Nov 15 06:44:57 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03192 for ; Wed, 15 Nov 2000 06:44:56 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA29914 for pilc-outgoing; Wed, 15 Nov 2000 05:33:04 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id FAA29905 for ; Wed, 15 Nov 2000 05:33:03 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id FAA26546; Wed, 15 Nov 2000 05:33:02 -0500 Received: from nmh.informatik.uni-bremen.de(134.102.224.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma026500; Wed, 15 Nov 00 05:32:30 -0500 Received: from cabo3 (dienstmann.informatik.uni-bremen.de [134.102.218.46]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id eAFAWDU07939; Wed, 15 Nov 2000 11:32:14 +0100 (MET) From: "Dr. Carsten Bormann" To: "ROHC Mailing List" Cc: "Mikael Degermark" Subject: Call for contributions on robust TCP/IP header compression Date: Wed, 15 Nov 2000 11:32:12 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit ROHCers, the deadline for new draft submissions is nearing (this Friday). If you have contributions on robust header compression of TCP/IP flows, now is the time to turn them in. Please read the ROHC working group charter at http://www.ietf.org/html.charters/rohc-charter.html if you haven't done so. To ensure that people are aware about the contributions, we will be accepting TCP header compression proposals under the WG name, i.e. draft-ietf-rohc-tcp-NNN-00.txt. If you have such a proposal, please contact the chairs ( and me) immediately for allocating the name NNN. Of course, contributions other than outright proposals are welcome -- if they aren't quite fit for WG documents, please submit them as draft-YOURNAME-rohc-tcp-...-00.txt, so people can key on -rohc- when searching for documents. Thanks. Finally, contributions on the ROHC mailing list and at the San Diego ROHC WG meeting slots are welcome, too. If you don't have a document now, but want to make a presentation in San Diego, please let us know. Gruesse, Carsten PS.: I'm BCCing the end2end list because this is where the TCP folks live, and pilc because this is where the link considerate folks live. These lists are BCCed to ensure they don't get a barrage of replies. From owner-pilc@lerc.nasa.gov Wed Nov 15 19:27:45 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05410 for ; Wed, 15 Nov 2000 19:27:44 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA24219 for pilc-outgoing; Wed, 15 Nov 2000 18:34:46 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA24203 for ; Wed, 15 Nov 2000 18:34:44 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA13535; Wed, 15 Nov 2000 18:34:42 -0500 Received: from den.erg.sri.com(128.18.100.23) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013465; Wed, 15 Nov 00 18:34:33 -0500 Received: from localhost (hua@localhost) by den.erg.sri.com (8.9.1/8.9.0) with SMTP id PAA24062 for ; Wed, 15 Nov 2000 15:34:27 -0800 (PST) Date: Wed, 15 Nov 2000 15:34:27 -0800 (PST) From: Hua Ji To: pilc@lerc.nasa.gov Subject: About WAP 2.0's (W)TCP spec. (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Hi, folks, What's the status of WAP 2.0 spec.? I am very curious that how they do that wtcp layer, given that there is no standard track rfc yet for this wtcp. Anyone can share some thoughts? Best regards, Hua From owner-pilc@lerc.nasa.gov Thu Nov 16 10:40:35 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15570 for ; Thu, 16 Nov 2000 10:40:34 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA26559 for pilc-outgoing; Thu, 16 Nov 2000 09:29:25 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA26530 for ; Thu, 16 Nov 2000 09:29:22 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id JAA10284; Thu, 16 Nov 2000 09:29:21 -0500 Received: from hnssysa.hns.com(139.85.76.100) by seraph3.lerc.nasa.gov via smap (V5.5) id xma010227; Thu, 16 Nov 00 09:29:09 -0500 Received: from hns.com (alta14.hns.com [139.85.62.34]) by hnssysa.hns.com (8.9.0/8.8.7) with ESMTP id JAA14477 for ; Thu, 16 Nov 2000 09:29:07 -0500 (EST) Message-ID: <3A13EF32.BD2B1403@hns.com> Date: Thu, 16 Nov 2000 09:29:06 -0500 From: John Border X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: pilc@grc.nasa.gov Subject: A PEP draft update... References: <200010241010.GAA02007@ietf.org> Content-Type: multipart/mixed; boundary="------------9AF1060370F86E54D66D5902" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. --------------9AF1060370F86E54D66D5902 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit FYI, We have only a few comments on document and we are in the process of making the updates so that we can get the -05 version out before the San Diego meeting deadline. The only two changes which are anything other than cleanup are the addition of an explicit statement pointing out that PEPs are used with existing link layers which have not had the benefit of the ADVICE draft and an observatation re QoS Transparency pointing out the potential for PEP mechanisms to conflict with things like diffserv... John --------------9AF1060370F86E54D66D5902 Content-Type: text/plain; charset=us-ascii; name="Section_1.txt" Content-Disposition: inline; filename="Section_1.txt" Content-Transfer-Encoding: 7bit Section 1, 1st Paragraph, Page 4 ****** The Transmission Control Protocol [RFC0793] (TCP) is used as the transport layer protocol by many Internet and intranet applications. However, in certain environments, TCP and other higher layer protocol performance is limited by the link characteristics of the environment. [Karn00] discusses various link layer design considerations that should be taken into account when designing a link layer service that is intended to support the Internet protocols. Such design choices may have a significant influence on the performance and efficiency of the Internet. However, not all link characteristics, for example, high latency, can be compensated for by choices in the link layer design. And, the cost of compensating for > some link characteristics may be prohibitive for some technologies. + (Also, it is difficult to apply the advice in [Karn00] to link < layers which already exist.) A Performance Enhancing Proxy (PEP) ~ is used to improve the performance of the Internet protocols on ~ network paths where native performance suffers due to ~ characteristics of a link or subnetwork on the path. ****** --------------9AF1060370F86E54D66D5902 Content-Type: text/plain; charset=us-ascii; name="Section_4.5.txt" Content-Disposition: inline; filename="Section_4.5.txt" Content-Transfer-Encoding: 7bit Section 4.5, Page 22 ****** This document describes some significant implications re using Performance Enhancing Proxies. However, the list of implications provided in this document is not necessarily exhaustive. Some examples of other potential implications related to using PEPs include the use of PEPs in multi-homing environments and the use of * PEPs with respect to Quality of Service (QoS) transparency. (For + example, there may be potential interaction with the priority-based + multiplexing mechanism described in Section 3.5 and the use of * differentiated services [RFC2475].) Therefore, users and network ~ administrators who wish to deploy a PEP should look not only at the ~ implications described in this document but also at the overall ~ impact (positive and negative) that the PEP will have on their ~ applications and network infrastructure, both initially and in the ~ future when new applications are added and/or changes in the ~ network infrastructure are required. ****** Section 8, Page 39 ****** + [RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, + W. Weiss, "An Architecture for Differentiated Services," + RFC 2475, December 1998. ****** --------------9AF1060370F86E54D66D5902-- From owner-pilc@lerc.nasa.gov Mon Nov 20 07:40: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 SMTP id HAA07272 for ; Mon, 20 Nov 2000 07:40:00 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA02948 for pilc-outgoing; Mon, 20 Nov 2000 06:18:06 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id GAA02928 for ; Mon, 20 Nov 2000 06:18:05 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA15666; Mon, 20 Nov 2000 06:18:04 -0500 Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015617; Mon, 20 Nov 00 06:17:44 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05310; Mon, 20 Nov 2000 06:17:36 -0500 (EST) Message-Id: <200011201117.GAA05310@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-06.txt Date: Mon, 20 Nov 2000 06:17:35 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF. Title : End-to-end Performance Implications of Links with Errors Author(s) : S. Dawkins, G. Montenegro, M. Kojo, V. Magret, N. Vaidya Filename : draft-ietf-pilc-error-06.txt Pages : 17 Date : 17-Nov-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 degree of reliability that hosts expect, and this expansion into unreliable links causes some Internet protocols, especially TCP [RFC793], to perform poorly. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-06.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-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-error-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001117145841.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-error-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-error-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001117145841.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Mon Nov 20 14:48: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 SMTP id OAA03029 for ; Mon, 20 Nov 2000 14:48:24 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA08134 for pilc-outgoing; Mon, 20 Nov 2000 13:03:37 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA08108 for ; Mon, 20 Nov 2000 13:03:35 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA09474; Mon, 20 Nov 2000 13:03:34 -0500 Received: from diesel.erg.abdn.ac.uk(139.133.204.76) by seraph3.lerc.nasa.gov via smap (V5.5) id xma009385; Mon, 20 Nov 00 13:02:51 -0500 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.11.1/8.11.1) with ESMTP id eAKI2f708201; Mon, 20 Nov 2000 18:02:46 GMT Message-ID: <3A196742.81F5FEF5@erg.abdn.ac.uk> Date: Mon, 20 Nov 2000 18:02:43 +0000 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.73C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: pilc@grc.nasa.gov Subject: draft-ietf-pilc-link-arq-issues-00.txt 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 Some while ago, Aaron (PILC WG Chair) asked for a summary of the thread on the list regarding reliable link layers and ARQ. Much of what is described has been developed from a subset of these discussions which are archived at the IETF PILC mailing list. We'd like to thank the all the contributors to PILC, who helped us get this far. Most of all, we would welcome feedback, and comments from anyone who has experience of the interactions between link ARQ protocols and Internet protocols. The Internet Draft quoted above has been submitted to the IETF ID archive, we expect this to be issued shortly, but until then, the draft is available via http at: http://www.erg.abdn.ac.uk/users/gorry/draft-ietf-pilc-link-arq-00.txt The draft is scheduled to be discussed at the San Diego IETF meeting (see PILC WG agenda). It may be that parts of the draft are finally incorporated into the 'Advice for Internet Subnetwork Designers' draft, (P. Karn, et al): draft-ietf-pilc-link-design-XX.txt. All comments are welcome. Best wishes Gorry Fairhurst Co-Author Lloyd Wood ------------------------------ http://www.erg.abdn.ac.uk/users/gorry From owner-pilc@lerc.nasa.gov Tue Nov 21 11:57:21 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11125 for ; Tue, 21 Nov 2000 11:57:20 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA19859 for pilc-outgoing; Tue, 21 Nov 2000 10:14:28 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA19803 for ; Tue, 21 Nov 2000 10:14:26 -0500 (EST) From: aaron@PanAmSat.com Received: by seraph3.lerc.nasa.gov; id KAA03536; Tue, 21 Nov 2000 10:14:23 -0500 Received: from unknown(208.217.183.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003419; Tue, 21 Nov 00 10:14:15 -0500 Received: by atlconn1.panamsat.com with Internet Mail Service (5.5.2650.10) id ; Tue, 21 Nov 2000 10:14:15 -0500 Message-ID: <0703A3E1D430D411866100508BDFCF331918A0@CTOEXCH1> To: pilc@grc.nasa.gov Subject: FW: A New IETF Work Area Date: Tue, 21 Nov 2000 10:12:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk I don't think everyone on the PILC list is on the IETF Announce list. This may be of interest. The creation of this area will not affect the PILC working group. --aaron -----Original Message----- From: Fred Baker [mailto:chair@ietf.org] Sent: Monday, November 20, 2000 5:15 PM Subject: A New IETF Work Area Traditionally the IETF has focused its efforts "above the wire and below the application." Occasionally standards track RFCs have given advice to application implementors about what application-level commands a user should be able to execute ( e.g., Requirements for Internet Hosts -- Application and Support - RFC 1123), defined software APIs (e.g., GSSAPI - RFC 2743), and given advice on the proper use of the features of IETF technology (e.g., Use of HTTP State Management. - RFC 2964). But mostly we have left the specifications of applications and how 'wires' such as Ethernet or ATM are defined and operate to other standards organizations or to the market place. Over the years the boundary between 'wires' and IP protocols has become harder to define and the interaction has become more intertwined. For example, what appear as 'wires' or 'circuits' in a virtual network may in fact be routed datagrams in an underlying IP network. The topology of dynamic underlying networks such as ATM and soon switched optical networks can interact with IP-level traffic engineering and routing. Additionally, with IETF technologies such as MPLS we are defining a whole new class of 'wires'. It has become increasingly clear that the IETF needs to develop a systematic approach to dealing with what we used to describe as "sub-IP" technologies. This approach should be able to help clarify what specific technologies the IETF should work on, what technologies we should forward to other organizations, and what technologies we need to work with other organizations to develop. In this effort the IETF is not proposing to develop physical wire technologies such as Ethernet, we are proposing to figure out common ways to monitor and control such technologies as they apply to IP networks. The existing and any new IETF sub-IP efforts such as MPLS should be grouped together under common management. As a first cut at such a systematic approach the IESG has decided to establish a new sub-IP pseudo-area. This pseudo-area will be temporarily housed in the General Area with the IETF Chair acting as Area Director and with the Area Directors of a number of existing IETF Areas acting as a joint technical and management team. We do not expect this to be a long term arrangement and the status of the sub-IP effort will be reviewed during the Spring of 2001. At that time, the IESG will determine which of the following three options will be pursued. The IESG could determine that there is a need for a long term effort in this arena. If that is the case the IESG will establish an additional IETF Area and ask the nomcom to select one or two Area Directors to manage it. A second possibility is that the IESG could determine that there is a need for a short term (one to two year) coordinated effort in which case the IESG could establish a new temporary area as was done in the case of IPng and appoint two current Area Directors to manage the effort co-terminus with their current assignments. The third possibility is that some of the working groups being moved into the pseudo-area and some of the new working groups will finish up their work by the fall of 2001 with insufficient remaining work left over to justify the creation of even a temporary area. In that case whatever working groups remain would be dispersed to existing IETF areas. Some existing IETF working groups will be moved into this pseudo-area and a number of new working groups will be created. They will be listed under the General Area on the agenda for the San Diego IETF meeting. There are also some BOFs scheduled to be held in San Diego that may, if they become working groups, be located in the pseudo-area. One example is the Circuit over IP BOF (coip). The existing IETF working groups that will be moved into the pseudo-area are Multiprotocol Label Switching (mpls) and Internet Traffic Engineering (tewg). New and proposed working groups that are being located in this pseudo-area include: Common Control and Measurement Planes (CoMa), Provider Provisioned Virtual Private Networks (ppvpn), IP over Packet Transport Rings (ipoptr), and IP over Optical (ipo). Draft charters for these working groups were posted earlier today. From owner-pilc@lerc.nasa.gov Tue Nov 21 20:07:24 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07203 for ; Tue, 21 Nov 2000 20:07:24 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA11295 for pilc-outgoing; Tue, 21 Nov 2000 18:15:06 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA11282 for ; Tue, 21 Nov 2000 18:15:05 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA17209; Tue, 21 Nov 2000 18:15:03 -0500 Received: from lagrange.ee.washington.edu(128.95.31.212) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017163; Tue, 21 Nov 00 18:14:50 -0500 Received: from localhost (hussein@localhost) by lagrange.ee.washington.edu (8.9.3/8.9.3) with ESMTP id PAA12405; Tue, 21 Nov 2000 15:13:47 -0800 (PST) Date: Tue, 21 Nov 2000 15:13:47 -0800 (PST) From: "A. Abou-Zeid" To: pilc@grc.nasa.gov cc: Marcelo Albuquerque , "Prof. Sumit Roy" Subject: Error Models for TCP performance evaluation over lossy links Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk The attached note describes briefly our experience with regard to the above mentioned topic, with pointers to more detailed information that may be of interest to this list. Most of the research involving TCP and lossy channels face a critical decision when choosing the most adequate error model to be used. One should use caution when opting between a discrete-time two-state error model, where channel state transitions occur synchronously with packet transmissions, and a continuous-time two-state error model, where channel state transitions occur independently from packet transmissions. In the network simulator (http://www.isi.edu/nsnam), the discrete-time two state model corresponds to the former while the continuous-time model proposed in (http://students.washington.edu/abouzeid/research.htm) corresponds to the latter. The discrete-time model has the advantage of allowing for a direct computation of relevant statistics such as average packet error rate and correlation between errors. Expressing results such as throughput as a function of these parameters is quite standard in most research work. However, the model fails to be physically realistic since its state transitions are dependent on TCP dynamics. In some situations this translates into unreasonable patterns in channel state transition. The continuous-time model makes the channel state independent from TCP dynamics but makes it very difficult to obtain the most widely used error statistics, such as packet error rate. Please refer to http://students.washington.edu/marcelo/errormodels.html for a more detailed report on this issue. Best regards, Alhussein for Marcelo Albuquerque, Alhussein Abouzeid, Sumit Roy Fundamentals of Networking Laboratory (FuNLab) Department of Electrical Engineering University of Washington, Seattle From owner-pilc@lerc.nasa.gov Wed Nov 22 07:18: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 SMTP id HAA29365 for ; Wed, 22 Nov 2000 07:18:29 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA18396 for pilc-outgoing; Wed, 22 Nov 2000 06:14:31 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id GAA18375 for ; Wed, 22 Nov 2000 06:14:30 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA21733; Wed, 22 Nov 2000 06:14:29 -0500 Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021661; Wed, 22 Nov 00 06:13:32 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21522; Wed, 22 Nov 2000 06:13:31 -0500 (EST) Message-Id: <200011221113.GAA21522@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pilc@grc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pilc-link-arq-issues-00.txt Date: Wed, 22 Nov 2000 06:13:30 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF. Title : Link ARQ issues for IP traffic Author(s) : G. Fairhurst, L. Wood Filename : draft-ietf-pilc-link-arq-issues-00.txt Pages : 17 Date : 21-Nov-00 This document discusses use of automatic repeat request (ARQ) procedures as an option in the design of a link protocol, and the impact of the use of ARQ on IP traffic travelling over the link. ARQ is described in a general way that includes its use over a wide range of underlying physical media, including cellular wireless, wireless LANs, RF links, and other types of bearer channel. This document is intended to provide guidance, and to outline matters for consideration, for designers and implementers of future link ARQ mechanisms. The material presented here is intended to be combined with the PILC 'Advice for Internet Subnetwork Designers' draft [DRAFTKARN00] to provide a single document giving guidance to subnetwork designers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-arq-issues-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pilc-link-arq-issues-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-link-arq-issues-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001121111444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-link-arq-issues-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-link-arq-issues-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001121111444.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Wed Nov 22 19:34: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 SMTP id TAA03675 for ; Wed, 22 Nov 2000 19:34:14 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA25146 for pilc-outgoing; Wed, 22 Nov 2000 18:14:40 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA25127 for ; Wed, 22 Nov 2000 18:14:39 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA00518; Wed, 22 Nov 2000 18:14:37 -0500 Received: from dhcp000913092958.qualcomm.com(129.46.77.76) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000477; Wed, 22 Nov 00 18:14:30 -0500 Received: (from karn@localhost) by patty.ka9q.net (8.9.3/8.9.3/Debian 8.9.3-21) id PAA17328; Wed, 22 Nov 2000 15:14:27 -0800 Date: Wed, 22 Nov 2000 15:14:27 -0800 Message-Id: <200011222314.PAA17328@patty.ka9q.net> From: Phil Karn To: pilc@grc.nasa.gov Reply-To: karn@qualcomm.com Subject: Updating LINK Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Hi all. I've been going over the PILC mail since the last IETF and am currently revising the LINK document before Friday's deadline. The old obsolete text is now gone from my copy; the question is how to replace it. In re-reading the discussion started by Dan Grossman's suggested new text for the QoS section, a few things occurred to me. I have always been struck by how discussions about QoS inevitably become extremely abstract, and I believe this has kept QoS from making much concrete progress in the real world. For example, Dan's section begins with a fairly lengthy (and abstract) review of current differentiated services work and ends with a single paragraph that dealt directly with link design issues. Given that not much of a consensus was reached in the ensuing list discussion, I'm inclined to leave out much of the review stuff in favor of pointers to existing documents, and to keep his last section. Since this is a document intended for subnetwork designers, any recommendations we make about QoS should be in concrete terms that subnetwork designers already understand. I still believe we should simply point out that many subnetworks have "knobs" that can make qualitative tradeoffs between competing measures of performance, that applications differ in which performance measures they consider important, give a few representative examples of such knobs, and recommend that the designers not preclude the ability of some future IP QoS mechanism to control them should the QoS folks ever figure out what they really want to do. Any comments? Phil From owner-pilc@lerc.nasa.gov Wed Nov 22 20:49:31 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20940 for ; Wed, 22 Nov 2000 20:49:31 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA00151 for pilc-outgoing; Wed, 22 Nov 2000 19:45:37 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA00126 for ; Wed, 22 Nov 2000 19:45:35 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA08273; Wed, 22 Nov 2000 19:45:34 -0500 Received: from dhcp000913092958.qualcomm.com(129.46.77.76) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008242; Wed, 22 Nov 00 19:45:06 -0500 Received: (from karn@localhost) by patty.ka9q.net (8.9.3/8.9.3/Debian 8.9.3-21) id QAA17520; Wed, 22 Nov 2000 16:45:02 -0800 Date: Wed, 22 Nov 2000 16:45:02 -0800 Message-Id: <200011230045.QAA17520@patty.ka9q.net> From: Phil Karn To: Reiner.Ludwig@ericsson.com CC: pilc@grc.nasa.gov Reply-To: karn@qualcomm.com In-reply-to: <4.3.2.7.0.20000801115412.00b847e0@chapelle.ericsson.se> (message from Reiner Ludwig on Tue, 01 Aug 2000 12:33:54 +0200) Subject: Re: Comments to "Advice for Internet Subnetwork Designers" References: < <5E5172B4DE05D311B3AB0008C75DA941019EF683@edeacnt100.eed.ericsson.se> <5E5172B4DE05D311B3AB0008C75DA941019EF683@edeacnt100.eed.ericsson.se> <4.3.2.7.0.20000801115412.00b847e0@chapelle.ericsson.se> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Going back to some mail of yours from early August, I've been giving your comments a lot of thought, and I have to admit I'm moving closer to your point of view on some things. >>What you really want to avoid are the nasty interactions between TCP >>and link/physical layer retransmissions that can occur in certain link >>operating regions. >People often talk about those interactions as if there where so many of >those. What are those interactions you are talking about? >I only know of two such interactions: >(1) spurious timeouts that lead to a go-back-N retransmisison mode in TCP, and A compliant TCP never does go-back-N; it only retransmits the oldest unacked segment. But even this could be a spurious retransmission if the earlier delay was caused by a link layer retransmission. >(2) out-of-order delivery at the link layer that falsely triggers fast >retransmit / fast recovery. I think this is not as significant a problem in practice, since most link layers already enforce packet ordering. >Given that PILC recommends that link layers should avoid out-of-order >delivery (also for the sake of not causing trouble for TCP/IP header >compression) this leaves spurious timeouts as the cardinal problem. But now I'm no longer sure that ordered delivery at the link level is even a good thing. The basic problem is that ordered delivery can only be done by intentionally delaying any packets that would otherwise be delivered out of order. This is harmless or even beneficial if the delayed packets belong to the same TCP connection. But if they don't, then you merely impair the performance of the other connection(s) with no compensating benefit. (True, the link *could* peek at the TCP and IP headers and only enforce in-order delivery of packets belonging to the same TCP connection, but that would be an egregious layer violation -- i.e., it wouldn't work with IPSEC). I believe this is much the same reasoning that originally led to the Internet architects to say that IP need not deliver packets in sequence, that reordering is a transport layer responsibility. Transport protocols can compensate for many subnetwork and Internet ills, including packet loss, duplication and reordering. But high delay is one subnetwork ill that a transport protocol can *never* overcome. That's why I think any low-level mechanism that deliberately introduces delay should be viewed with great skepticism. This also leads to the conclusion that if packet reordering spuriously triggers TCP's dup ack mechanism, then this is really TCP's fault and it should be fixed inside TCP. (I didn't say this would be easy, though.) This leaves one remaining argument for ordered delivery on links: VJ header compression. So we could simply say that in-order delivery is important only if you plan to implement VJ header compression. Anyway, back to retransmission interactions. >>But whenever the link layer retransmits, the RTT spikes >>and there's a spurious TCP retransmission. >This is a simply not true. You have to let things go really bad to force a >spurious timeout in TCP. Depending on your path characteristics especially You say it's rare, but it is something I've seen quite often in TCP traces. I think this difference is simply due to our having operated over different environments. Our air links tend to have relatively high latencies even without link level retransmissions, and more significantly this latency tends to dominate that of the total Internet path. So we probably see many more cases of spurious TCP retransmissions being triggered by link retransmissions than you do. Also, our link protocols have historically been implemented in cell phones with severely limited memory resources, and this has led us to implement non-persistent link ARQ schemes that don't require a lot of buffer memory. Of course, this problem is going away over time. But perhaps you're right that, overall, it's better to not limit the persistence of the link layer ARQ scheme. Fair queuing might help limit the effect of the spurious retransmissions on other competing flows, for example. Also, having a highly persistent link layer ARQ might be the best way to help TCP recover quickly from sustained link outages. Phil From owner-pilc@lerc.nasa.gov Thu Nov 23 09:39:52 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06743 for ; Thu, 23 Nov 2000 09:39:52 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA03016 for pilc-outgoing; Thu, 23 Nov 2000 08:04:42 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id IAA03007 for ; Thu, 23 Nov 2000 08:04:40 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA02089; Thu, 23 Nov 2000 08:04:39 -0500 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002060; Thu, 23 Nov 00 08:04:29 -0500 Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 13yw38-0005sj-00; Thu, 23 Nov 2000 13:04:26 +0000 Date: Thu, 23 Nov 2000 13:04:25 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: karn@qualcomm.com cc: PILC mailing list Subject: Re: Comments to "Advice for Internet Subnetwork Designers" In-Reply-To: <200011230045.QAA17520@patty.ka9q.net> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Wed, 22 Nov 2000, Phil Karn wrote: > >(2) out-of-order delivery at the link layer that falsely triggers fast > >retransmit / fast recovery. > > I think this is not as significant a problem in practice, since most > link layers already enforce packet ordering. That's not what Bennett and Partridge observed in the backbone: J.C. Bennett, C. Partridge, and N. Schectman, Packet Reordering is Not Pathological Network Behaviour, IEEE/ACM Transactions on Networking, 7(6), pp. 789-798, 2000. > Transport protocols can compensate for many subnetwork and Internet > ills, including packet loss, duplication and reordering. But high > delay is one subnetwork ill that a transport protocol can *never* > overcome. That's why I think any low-level mechanism that > deliberately introduces delay should be viewed with great skepticism. ...including highly-persistent ARQ. > This also leads to the conclusion that if packet reordering spuriously > triggers TCP's dup ack mechanism, then this is really TCP's fault and > it should be fixed inside TCP. (I didn't say this would be easy, though.) Yes - and tweaking the dupack threshold is being examined by a few people. L. PGP From owner-pilc@lerc.nasa.gov Thu Nov 23 10:37: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 SMTP id KAA23399 for ; Thu, 23 Nov 2000 10:37:09 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA04742 for pilc-outgoing; Thu, 23 Nov 2000 08:50:53 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id IAA04733 for ; Thu, 23 Nov 2000 08:50:52 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA05371; Thu, 23 Nov 2000 08:50:52 -0500 Received: from diesel.erg.abdn.ac.uk(139.133.204.76) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005342; Thu, 23 Nov 00 08:50:14 -0500 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.11.1/8.11.1) with ESMTP id eANDo4729249; Thu, 23 Nov 2000 13:50:04 GMT Message-ID: <3A1D208B.CD3E8FAA@erg.abdn.ac.uk> Date: Thu, 23 Nov 2000 13:50:05 +0000 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.73C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: karn@qualcomm.com CC: Reiner.Ludwig@ericsson.com, pilc@grc.nasa.gov Subject: Re: Comments to "Advice for Internet Subnetwork Designers" References: < <5E5172B4DE05D311B3AB0008C75DA941019EF683@edeacnt100.eed.ericsson.se> <5E5172B4DE05D311B3AB0008C75DA941019EF683@edeacnt100.eed.ericsson.se> <4.3.2.7.0.20000801115412.00b847e0@chapelle.ericsson.se> <200011230045.QAA17520@patty.ka9q.net> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit See also: draft-ietf-pilc-link-arq-issues-00.txt Phil Karn wrote: > Going back to some mail of yours from early August, I've been giving > your comments a lot of thought, and I have to admit I'm moving closer > to your point of view on some things. > > >>What you really want to avoid are the nasty interactions between TCP > >>and link/physical layer retransmissions that can occur in certain link > >>operating regions. > > >People often talk about those interactions as if there where so many of > >those. What are those interactions you are talking about? > > >I only know of two such interactions: > >(1) spurious timeouts that lead to a go-back-N retransmisison mode in TCP, and > > A compliant TCP never does go-back-N; it only retransmits the oldest > unacked segment. But even this could be a spurious retransmission if the earlier > delay was caused by a link layer retransmission. > > >(2) out-of-order delivery at the link layer that falsely triggers fast > >retransmit / fast recovery. > > I think this is not as significant a problem in practice, since most > link layers already enforce packet ordering. > > >Given that PILC recommends that link layers should avoid out-of-order > >delivery (also for the sake of not causing trouble for TCP/IP header > >compression) this leaves spurious timeouts as the cardinal problem. > > But now I'm no longer sure that ordered delivery at the link level is > even a good thing. > > The basic problem is that ordered delivery can only be done by > intentionally delaying any packets that would otherwise be delivered > out of order. This is harmless or even beneficial if the delayed > packets belong to the same TCP connection. But if they don't, then > you merely impair the performance of the other connection(s) with no > compensating benefit. I thought PILC recommended PER-FLOW ordering. This may in many protocols be implemented as PER-LINK or per-host-pair-of-IP-addresses, but these are design decisions taken during the link implementation. There are cases for out-of-order delivery between flows. Low persistency may also reduce the head-of-line link reciever blocking which you mention. > (True, the link *could* peek at the TCP and IP > headers and only enforce in-order delivery of packets belonging to the > same TCP connection, but that would be an egregious layer violation -- > i.e., it wouldn't work with IPSEC). > > I believe this is much the same reasoning that originally led to the > Internet architects to say that IP need not deliver packets in > sequence, that reordering is a transport layer responsibility. > > Transport protocols can compensate for many subnetwork and Internet > ills, including packet loss, duplication and reordering. But high > delay is one subnetwork ill that a transport protocol can *never* > overcome. That's why I think any low-level mechanism that > deliberately introduces delay should be viewed with great skepticism. > > This also leads to the conclusion that if packet reordering spuriously > triggers TCP's dup ack mechanism, then this is really TCP's fault and > it should be fixed inside TCP. (I didn't say this would be easy, though.) That is re-ordering within a flow - I think you mean. > > This leaves one remaining argument for ordered delivery on links: VJ > header compression. So we could simply say that in-order delivery is > important only if you plan to implement VJ header compression. V-J isn't recommended with lossey links.... There are more arguments for low link delay in: draft-ietf-pilc-link-arq-issues-00.txt > > Anyway, back to retransmission interactions. > > >>But whenever the link layer retransmits, the RTT spikes > >>and there's a spurious TCP retransmission. > > >This is a simply not true. You have to let things go really bad to force a > >spurious timeout in TCP. Depending on your path characteristics especially > > You say it's rare, but it is something I've seen quite often in TCP > traces. I think this difference is simply due to our having operated > over different environments. Our air links tend to have relatively > high latencies even without link level retransmissions, and more > significantly this latency tends to dominate that of the total > Internet path. So we probably see many more cases of spurious TCP > retransmissions being triggered by link retransmissions than you do. > > Also, our link protocols have historically been implemented in cell > phones with severely limited memory resources, and this has led us to > implement non-persistent link ARQ schemes that don't require a lot of > buffer memory. Of course, this problem is going away over time. > > But perhaps you're right that, overall, it's better to not limit the > persistence of the link layer ARQ scheme. Fair queuing might help > limit the effect of the spurious retransmissions on other competing > flows, for example. Also, having a highly persistent link layer ARQ > might be the best way to help TCP recover quickly from sustained link > outages. FQ helps at the input to the link-ARQ, it can't help if the link propagation delay is high and there are frames under-going error recovery. > > > Phil Gorry ------------------------------ http://www.erg.abdn.ac.uk/users/gorry From owner-pilc@lerc.nasa.gov Thu Nov 23 11:37: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 SMTP id LAA16888 for ; Thu, 23 Nov 2000 11:37:50 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA08232 for pilc-outgoing; Thu, 23 Nov 2000 10:17:34 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA08212 for ; Thu, 23 Nov 2000 10:17:32 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA11813; Thu, 23 Nov 2000 10:17:31 -0500 Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011789; Thu, 23 Nov 00 10:17:24 -0500 Received: from aachen.eed.ericsson.se (aachen.eed.ericsson.se [164.48.130.2]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eANFHM224564; Thu, 23 Nov 2000 16:17:22 +0100 (MET) Received: from e00d059101eba.Ericsson.com (dhcp4-117 [164.48.140.117]) by aachen.eed.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id QAA24232; Thu, 23 Nov 2000 16:17:20 +0100 (MET) Message-Id: <5.0.1.4.0.20001123152149.0244ab10@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 23 Nov 2000 16:17:19 +0100 To: karn@qualcomm.com From: Reiner Ludwig Subject: Re: Comments to "Advice for Internet Subnetwork Designers" Cc: pilc@grc.nasa.gov In-Reply-To: <200011230045.QAA17520@patty.ka9q.net> References: <4.3.2.7.0.20000801115412.00b847e0@chapelle.ericsson.se> < <5E5172B4DE05D311B3AB0008C75DA941019EF683@edeacnt100.eed.ericsson.se> <5E5172B4DE05D311B3AB0008C75DA941019EF683@edeacnt100.eed.ericsson.se> <4.3.2.7.0.20000801115412.00b847e0@chapelle.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 01:45 23.11.00, Phil Karn wrote: >Going back to some mail of yours from early August, I've been giving >your comments a lot of thought, and I have to admit I'm moving closer >to your point of view on some things. I'm glad to hear this. Ideally, we can get our views converged on this matter so that we can get this section "Reliability and Error Control" straight in the "Advice for Internet Subnetwork Designers". Maybe, we can make this a topic at the PILC meeting in San Diego. I would be happy to present my view ... if the WG chairs think that that's appropriate. > >>What you really want to avoid are the nasty interactions between TCP > >>and link/physical layer retransmissions that can occur in certain link > >>operating regions. > > >People often talk about those interactions as if there where so many of > >those. What are those interactions you are talking about? > > >I only know of two such interactions: > >(1) spurious timeouts that lead to a go-back-N retransmisison mode in > TCP, and > >A compliant TCP never does go-back-N; it only retransmits the oldest >unacked segment. But even this could be a spurious retransmission if the >earlier >delay was caused by a link layer retransmission. Please, check out section 3.1 in this paper: http://www.acm.org/sigcomm/ccr/archive/2000/jan00/ccr-200001-ludwig.html A compliant TCP has no other chance but to go into go-back-N after a spurious timeout, i.e., a spurious timeout forces TCP into the go-back-N. I have just submitted an Internet Draft to TSVWG on this matter: http://search.ietf.org/internet-drafts/draft-ludwig-tsvwg-tcp-eifel-alg-00.txt > >(2) out-of-order delivery at the link layer that falsely triggers fast > >retransmit / fast recovery. > >I think this is not as significant a problem in practice, since most >link layers already enforce packet ordering. I agree with respect to existing link layers. I'm not so sure, though, whether we should also recommend in-order delivery for future wireless links. > >Given that PILC recommends that link layers should avoid out-of-order > >delivery (also for the sake of not causing trouble for TCP/IP header > >compression) this leaves spurious timeouts as the cardinal problem. > >But now I'm no longer sure that ordered delivery at the link level is >even a good thing. > >The basic problem is that ordered delivery can only be done by >intentionally delaying any packets that would otherwise be delivered >out of order. This is harmless or even beneficial if the delayed >packets belong to the same TCP connection. But if they don't, then >you merely impair the performance of the other connection(s) with no >compensating benefit. (True, the link *could* peek at the TCP and IP >headers and only enforce in-order delivery of packets belonging to the >same TCP connection, but that would be an egregious layer violation -- >i.e., it wouldn't work with IPSEC). Again, I agree except to the layer violation concerns. I would also like to stronlgly promote clean designs, i.e., without layer violations. But to implement what I call inter-flow out-of-order delivery (as opposed to intra-flow out-of-order delivery, i.e., o-o-o delivery within a single flow), you do not need to have the link layer inspect IP headers. Instead, you could, e.g., run multiple logical link layers (one per flow) across a hop, and have IP distribute the packets onto those links based on port numbers. "one per flow" clearly does not scale, but for the first/last hop this shouldn't be a problem. Yes, as with so many things, this does not work with IPsec. >I believe this is much the same reasoning that originally led to the >Internet architects to say that IP need not deliver packets in >sequence, that reordering is a transport layer responsibility. > >Transport protocols can compensate for many subnetwork and Internet >ills, including packet loss, duplication and reordering. But high >delay is one subnetwork ill that a transport protocol can *never* >overcome. That's why I think any low-level mechanism that >deliberately introduces delay should be viewed with great skepticism. > >This also leads to the conclusion that if packet reordering spuriously >triggers TCP's dup ack mechanism, then this is really TCP's fault and >it should be fixed inside TCP. (I didn't say this would be easy, though.) The ID I mentioned above is such a fix (inside TCP). >This leaves one remaining argument for ordered delivery on links: VJ >header compression. So we could simply say that in-order delivery is >important only if you plan to implement VJ header compression. The evolved VJ header compression, RFC2507, optionally uses sequence numbers within the compressed headers to deal with links that re-order. So, this would eliminate the "one remaining argument". However, there would be no benefit in having the link layer do o-o-o delivery in this case, since now we have the header decompressor delaying the packets to bring them back into order. >Anyway, back to retransmission interactions. > > >>But whenever the link layer retransmits, the RTT spikes > >>and there's a spurious TCP retransmission. > > >This is a simply not true. You have to let things go really bad to force a > >spurious timeout in TCP. Depending on your path characteristics especially > >You say it's rare, but it is something I've seen quite often in TCP >traces. I think this difference is simply due to our having operated >over different environments. Plus, it very much depends on your TCP (timer granularity, restart of the timer after an ACK, ...). We see more spurious timeouts with LINUX for example. Still, with the current RTO calculation, spurious timeouts should be rare. >Our air links tend to have relatively >high latencies even without link level retransmissions, and more >significantly this latency tends to dominate that of the total >Internet path. So we probably see many more cases of spurious TCP >retransmissions being triggered by link retransmissions than you do. I don't know what you mean when you say "our air links", but I did quite a few measurements in GSM which certainly qualifies as high latency, and also it dominates the e2e RTT. Still, spurious timeouts were extremely rare (in BSD) and when they occured, then this was always in the beginning of the connection. This is since the RTO had not been given enough time to adapt. >Also, our link protocols have historically been implemented in cell >phones with severely limited memory resources, and this has led us to >implement non-persistent link ARQ schemes that don't require a lot of >buffer memory. Of course, this problem is going away over time. I see highly persistent LL ARQ as independent from buffer memory. When some people hear highly persistent LL ARQ, they often think that this equals "buffering for ever". *No, it does not!* The queues need to remain appropriately small also with highly persistent LL ARQ. >But perhaps you're right that, overall, it's better to not limit the >persistence of the link layer ARQ scheme. I think it should be limited to 64 seconds sicne this is TCP max. RTO. There is really no point in delaying a packet beyond that. In addition, should the system hosting the link layer get into memory problems, then this might also be a reason to drop (from front) packets before 64sec have passed. >Fair queuing might help >limit the effect of the spurious retransmissions on other competing >flows, for example. I agree, if you seperate flow classes (UDP vs. TCP) at the link layer, there needs to be some scheme in place that devides the link's bandwidth between those classes. E.g., 30% for elastic TCP traffic, the rest for delay-sensitive traffic. >Also, having a highly persistent link layer ARQ >might be the best way to help TCP recover quickly from sustained link >outages. Exactly. ///Reiner From owner-pilc@lerc.nasa.gov Thu Nov 23 12:55:00 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13117 for ; Thu, 23 Nov 2000 12:55:00 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA10569 for pilc-outgoing; Thu, 23 Nov 2000 11:10:06 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA10561 for ; Thu, 23 Nov 2000 11:10:04 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA16077; Thu, 23 Nov 2000 11:10:03 -0500 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016007; Thu, 23 Nov 00 11:09:49 -0500 Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 13yywS-0007ZO-00; Thu, 23 Nov 2000 16:09:44 +0000 Date: Thu, 23 Nov 2000 16:09:43 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Reiner Ludwig cc: karn@qualcomm.com, pilc@grc.nasa.gov Subject: Re: Comments to "Advice for Internet Subnetwork Designers" In-Reply-To: <5.0.1.4.0.20001123152149.0244ab10@chapelle.ericsson.se> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Thu, 23 Nov 2000, Reiner Ludwig wrote: > Phil Karn wrote in replky to Reiner: > > > >>What you really want to avoid are the nasty interactions between TCP > > >>and link/physical layer retransmissions that can occur in certain link > > >>operating regions. > > > > >People often talk about those interactions as if there where so many of > > >those. What are those interactions you are talking about? > > > > >I only know of two such interactions: > > >(1) spurious timeouts that lead to a go-back-N retransmisison mode in > > TCP, and > > > >A compliant TCP never does go-back-N; it only retransmits the oldest > >unacked segment. But even this could be a spurious retransmission if the > >earlier delay was caused by a link layer retransmission. > > Please, check out section 3.1 in this paper: > http://www.acm.org/sigcomm/ccr/archive/2000/jan00/ccr-200001-ludwig.html > > A compliant TCP has no other chance but to go into go-back-N after a > spurious timeout, i.e., a spurious timeout forces TCP into the go-back-N. even with use of SACK and knowledge of the receiver window state? (Did I miss a timeout causing the SACK scoreboard to be discarded?) puzzled, L. PGP From owner-pilc@lerc.nasa.gov Thu Nov 23 19:17:17 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12510 for ; Thu, 23 Nov 2000 19:17:16 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA24475 for pilc-outgoing; Thu, 23 Nov 2000 17:14:49 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA24461 for ; Thu, 23 Nov 2000 17:14:47 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA12631; Thu, 23 Nov 2000 17:14:46 -0500 Received: from albatross-ext.wise.edt.ericsson.se(194.237.142.116) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012599; Thu, 23 Nov 00 17:14:40 -0500 Received: from aachen.eed.ericsson.se (aachen.eed.ericsson.se [164.48.130.2]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eANMEct05575; Thu, 23 Nov 2000 23:14:39 +0100 (MET) Received: from e00d059101eba.Ericsson.com (rac166pc.edd.ericsson.se [164.48.123.166]) by aachen.eed.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id XAA21801; Thu, 23 Nov 2000 23:14:35 +0100 (MET) Message-Id: <5.0.1.4.0.20001123225519.0250dec0@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 23 Nov 2000 23:03:35 +0100 To: L.Wood@eim.surrey.ac.uk From: Reiner Ludwig Subject: Re: Comments to "Advice for Internet Subnetwork Designers" Cc: pilc@grc.nasa.gov In-Reply-To: References: <5.0.1.4.0.20001123152149.0244ab10@chapelle.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 17:09 23.11.00, Lloyd Wood wrote: >On Thu, 23 Nov 2000, Reiner Ludwig wrote: > > A compliant TCP has no other chance but to go into go-back-N after a > > spurious timeout, i.e., a spurious timeout forces TCP into the go-back-N. > >even with use of SACK and knowledge of the receiver window state? (Did >I miss a timeout causing the SACK scoreboard to be discarded?) Yes, even with SACK. Note, that the first thing(s) a sender sees after a spurious timeout are the returning ACKs that were triggered by the *original* segments arriving at the receiver. Those ACKs will not carry any SACK info. Sure, *after* the go-back-N has been performed, the sender will then find out what went wrong when it receives D-SACK info in the ACKs that are triggered by the duplicate segments sent during the go-back-N. But at that point it's too late; an entire flight has already been resent unnecessarily. ///Reiner From owner-pilc@lerc.nasa.gov Fri Nov 24 04:04:11 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13916 for ; Fri, 24 Nov 2000 04:04:10 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA00212 for pilc-outgoing; Fri, 24 Nov 2000 02:44:48 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id CAA00179 for ; Fri, 24 Nov 2000 02:44:44 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id CAA20218; Fri, 24 Nov 2000 02:44:44 -0500 Received: from 24-130-188-101.san.rr.com(24.130.188.101) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020180; Fri, 24 Nov 00 02:43:53 -0500 Received: (from karn@localhost) by homer.ka9q.net (8.9.3/8.9.3/Debian 8.9.3-21) id XAA19783; Thu, 23 Nov 2000 23:43:31 -0800 Date: Thu, 23 Nov 2000 23:43:31 -0800 Message-Id: <200011240743.XAA19783@homer.ka9q.net> From: Phil Karn To: L.Wood@eim.surrey.ac.uk CC: pilc@grc.nasa.gov In-reply-to: (message from Lloyd Wood on Thu, 23 Nov 2000 13:04:25 +0000 (GMT)) Subject: Re: Comments to "Advice for Internet Subnetwork Designers" Reply-to: karn@qualcomm.com References: Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >> I think this is not as significant a problem in practice, since most >> link layers already enforce packet ordering. >That's not what Bennett and Partridge observed in the backbone: Thanks for the pointer to that paper, as I wasn't aware of it. I just finished reading it. It's very good, and I recommend it to the group. I found this rather poor quality PDF copy: http://www.acm.org/pubs/articles/journals/ton/1999-7-6/p789-bennett/p789-bennett.pdf I should have been more clear in my choice of words. I was thinking of a single point-to-point link, not a collection of parallel links and/or reordering routers along a given Internet path. I think it's still correct to say that most physical links still enforce packet ordering, even if those links are frequently used in parallel and/or with switches and routers (like the DEC Gigaswitch discussed in that paper) that do frequently reorder packets. I generally agree with the paper's conclusions: reordering does happen in the real Internet and it does cause problems with TCP performance. TCP should be made more robust to reordering *and* the subnetworks should be designed to avoid it whenever possible. So how's this for a LINK recommendation: subnetworks should try to deliver packets in order when possible, but not if doing so impairs the subnetwork's capacity or increases its latency. Comments? Phil From owner-pilc@lerc.nasa.gov Fri Nov 24 09:51:48 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29617 for ; Fri, 24 Nov 2000 09:51:48 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA24942 for pilc-outgoing; Fri, 24 Nov 2000 08:32:17 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id IAA24928 for ; Fri, 24 Nov 2000 08:32:16 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA13008; Fri, 24 Nov 2000 08:32:14 -0500 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012965; Fri, 24 Nov 00 08:31:48 -0500 Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 13zIx0-0007Fw-00; Fri, 24 Nov 2000 13:31:38 +0000 Date: Fri, 24 Nov 2000 13:31:38 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Reiner Ludwig cc: pilc@grc.nasa.gov Subject: Re: Comments to "Advice for Internet Subnetwork Designers" In-Reply-To: <5.0.1.4.0.20001123225519.0250dec0@chapelle.ericsson.se> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Thu, 23 Nov 2000, Reiner Ludwig wrote: > At 17:09 23.11.00, Lloyd Wood wrote: > >On Thu, 23 Nov 2000, Reiner Ludwig wrote: > > > A compliant TCP has no other chance but to go into go-back-N after a > > > spurious timeout, i.e., a spurious timeout forces TCP into the go-back-N. > > > >even with use of SACK and knowledge of the receiver window state? (Did > >I miss a timeout causing the SACK scoreboard to be discarded?) > > Yes, even with SACK. Note, that the first thing(s) a sender sees after a > spurious timeout are the returning ACKs that were triggered by the > *original* segments arriving at the receiver. Those ACKs will not carry any > SACK info. > > Sure, *after* the go-back-N has been performed, the sender will then find > out what went wrong when it receives D-SACK info in the ACKs that are > triggered by the duplicate segments sent during the go-back-N. But at that > point it's too late; an entire flight has already been resent unnecessarily. isn't this really an argument against bursts and in favour of TCP pacing? L. PGP From owner-pilc@lerc.nasa.gov Fri Nov 24 09:52:07 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29696 for ; Fri, 24 Nov 2000 09:52:07 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA23775 for pilc-outgoing; Fri, 24 Nov 2000 08:13:13 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id IAA23761 for ; Fri, 24 Nov 2000 08:13:11 -0500 (EST) From: Marie-Jose.Montpetit@nokia.com Received: by seraph3.lerc.nasa.gov; id IAA11679; Fri, 24 Nov 2000 08:13:10 -0500 Received: from mgw-dax2.ext.nokia.com(63.78.179.217) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011635; Fri, 24 Nov 00 08:12:58 -0500 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eAODCt620294 for ; Fri, 24 Nov 2000 07:13:15 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Fri, 24 Nov 2000 07:12:27 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 24 Nov 2000 07:12:27 -0600 Message-ID: To: karn@qualcomm.com, pilc@grc.nasa.gov Subject: RE: Updating LINK Date: Fri, 24 Nov 2000 07:04:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk snip/snip Since this is a document intended for subnetwork designers, any recommendations we make about QoS should be in concrete terms that subnetwork designers already understand. I still believe we should simply point out that many subnetworks have "knobs" that can make qualitative tradeoffs between competing measures of performance, that applications differ in which performance measures they consider important, give a few representative examples of such knobs, and recommend that the designers not preclude the ability of some future IP QoS mechanism to control them should the QoS folks ever figure out what they really want to do. Any comments? Well yes I agree with the approach. I think we have erred maybe a bit to much on the high level advice :-) I think for QoS in particular whatever is at the edge of the subnet has to do the "translation" from what the application/session needs into what the subnet can deliver (or cannot deliver for that matter). In any subnet that does encapsulation or segmenting of the IP packet there are often a native set of QoS "levels" that will be used and mapped to the diffserv classes. Phil, are you suggesting we (pilc) should define the mapping mechanisms or the QoS signaling (some RSVP-light for edge devices that are not routers?) and look at subnet-level admission control based on resource management methods? I think that would be valuable but maybe worth of a draft of it's own. Marie-Jose From owner-pilc@lerc.nasa.gov Fri Nov 24 13:13:03 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16953 for ; Fri, 24 Nov 2000 13:13:03 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA09303 for pilc-outgoing; Fri, 24 Nov 2000 11:59:08 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA09280 for ; Fri, 24 Nov 2000 11:59:05 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA29198; Fri, 24 Nov 2000 11:59:04 -0500 Received: from 24-130-188-101.san.rr.com(24.130.188.101) by seraph3.lerc.nasa.gov via smap (V5.5) id xma029141; Fri, 24 Nov 00 11:58:43 -0500 Received: (from karn@localhost) by homer.ka9q.net (8.9.3/8.9.3/Debian 8.9.3-21) id IAA20743; Fri, 24 Nov 2000 08:58:15 -0800 Date: Fri, 24 Nov 2000 08:58:15 -0800 Message-Id: <200011241658.IAA20743@homer.ka9q.net> From: Phil Karn To: L.Wood@eim.surrey.ac.uk CC: Reiner.Ludwig@ericsson.com, pilc@grc.nasa.gov In-reply-to: (message from Lloyd Wood on Thu, 23 Nov 2000 16:09:43 +0000 (GMT)) Subject: Re: Comments to "Advice for Internet Subnetwork Designers" Reply-to: karn@qualcomm.com References: Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >> A compliant TCP has no other chance but to go into go-back-N after a >> spurious timeout, i.e., a spurious timeout forces TCP into the go-back-N. >even with use of SACK and knowledge of the receiver window state? (Did >I miss a timeout causing the SACK scoreboard to be discarded?) I'm still confused here. I have always understood TCP to requre (or at least strongly encourage) that when a timeout occurs, only the oldest unacknowledged segment is retransmitted. If this fills a hole in the receiver's reassembly queue (the receiver has already received subsequent segments), the receiver will ack as much as it can. This is not classic "go-back-N" as it was implemented in HDLC LAPB, for example. In LAPB, anything received after a missing frame was discarded, and the sender resends all N frames from the missing frame onward. Obviously this is much less efficient than resending just the missing frame. So perhaps by "go back N" you simply meant that TCP has to go back and fill in the missing packet with a retransmission, not retransmit the entire window's worth of data? Phil From owner-pilc@lerc.nasa.gov Fri Nov 24 14:41: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 SMTP id OAA06781 for ; Fri, 24 Nov 2000 14:41:55 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA13695 for pilc-outgoing; Fri, 24 Nov 2000 13:09:45 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA13686 for ; Fri, 24 Nov 2000 13:09:43 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA04821; Fri, 24 Nov 2000 13:09:42 -0500 Received: from diesel.erg.abdn.ac.uk(139.133.204.76) by seraph3.lerc.nasa.gov via smap (V5.5) id xma004798; Fri, 24 Nov 00 13:09:40 -0500 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.11.1/8.11.1) with ESMTP id eAOI9Y707019; Fri, 24 Nov 2000 18:09:35 GMT Message-ID: <3A1EAEDF.5EB481F3@erg.abdn.ac.uk> Date: Fri, 24 Nov 2000 18:09:37 +0000 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.73C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Reiner Ludwig , pilc@grc.nasa.gov Subject: Re: Comments to "Advice for Internet Subnetwork Designers" References: <4.3.2.7.0.20000801115412.00b847e0@chapelle.ericsson.se> < <5E5172B4DE05D311B3AB0008C75DA941019EF683@edeacnt100.eed.ericsson.se> <5E5172B4DE05D311B3AB0008C75DA941019EF683@edeacnt100.eed.ericsson.se> <4.3.2.7.0.20000801115412.00b847e0@chapelle.ericsson.se> <5.0.1.4.0.20001123152149.0244ab10@chapelle.ericsson.se> Content-Type: text/plain; charset=iso-8859-1; x-mac-type="54455854"; x-mac-creator="4D4F5353" X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id eAOI9Y707019 X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id NAA13688 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by lombok-fi.lerc.nasa.gov id NAA13695 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA06781 You make many interesting points... >Reiner Ludwig wrote: >I would also like to strongly promote clean designs, i.e., without layer > violations. But to implement what I call inter-flow out-of-order delivery > (as opposed to intra- > flow out-of-order delivery, i.e., o-o-o delivery > within a single flow), you do not need to have the link layer inspect IP > headers. > Instead, you could, e.g., run multiple logical link layers (one per flow) > across a hop, and have IP distribute the packets onto those links based on > port numbers. "one per flow" clearly does not scale, but for the first/last > hop this shouldn't be a problem. I agree with this idea. I like the idea of decoupling the ARQ between different flows. Ordering does not require persistence, or vice versa - yet many link protocols I have seen do both of these or neither. I know there are protocols which do not, and I am very interested in thinking about the implications of this. Have you thought about the pros and cons of using parallel links with individual ARQ? > I see highly persistent LL ARQ as independent from buffer memory. When some > people hear highly persistent LL ARQ, they often think that this equals > "buffering for ever". *No, it does not!* The queues need to remain > appropriately small also with highly persistent LL ARQ. > ///Reiner I think this is where I begin to get confused? When the link carries some TCP and some UDP flows. The UDP sources don’t simply stop because some of their data is lost or waiting transmission in the link layer. Then, don’t you end up with an excess of data queued at the link transmit interface. If the window/queue is small, then you drop? Do you have to drop UDP preferentially to keep TCP performance? I wonder what happens when you have many many TCP flows all sharing then, don’t you need to buffer a lot? or drop a lot? Gorry Fairhurst ------------------------------ http://www.erg.abdn.ac.uk/users/gorry From owner-pilc@lerc.nasa.gov Fri Nov 24 17:25:52 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12192 for ; Fri, 24 Nov 2000 17:25:52 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA25937 for pilc-outgoing; Fri, 24 Nov 2000 16:39:32 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA25921 for ; Fri, 24 Nov 2000 16:39:30 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA20662; Fri, 24 Nov 2000 16:39:29 -0500 Received: from servo.qualcomm.com(129.46.76.82) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020612; Fri, 24 Nov 00 16:38:40 -0500 Received: (from karn@localhost) by servo.qualcomm.com (8.9.3/8.9.3/1.0) id NAA04940; Fri, 24 Nov 2000 13:38:38 -0800 (PST) Date: Fri, 24 Nov 2000 13:38:38 -0800 (PST) Message-Id: <200011242138.NAA04940@servo.qualcomm.com> From: Phil Karn To: pilc@grc.nasa.gov Subject: draft-ietf-pilc-link-design-04.txt submitted Sender: owner-pilc@lerc.nasa.gov Precedence: bulk I have just submitted the latest version of the LINK document to internet-drafts@ietf.org. It's also up on my website as http://people.qualcomm.com/karn/pilc.txt The major changes in this version: 1. Fixed erroneous reference to the minimum MTU allowed in IP (thanks to Kevin Lahey for spotting this one). 2. Reworked the QoS section largely as I discussed on the list the other day. I removed the obsolete text about the old TOS bits, inserted some new explanatory text, and included the latter part of Dan Grossman's suggested text (the part with the list of actual recommendations to the subnetwork designers). 3. Wrote a new section on Fairness vs Performance. 4. Wrote a new section on Delay Characteristics. 5. Reworked the section on Packet Reordering to cite the Bennett/Partridge/Shectman paper, and to recommend that subnetwork packet reordering should be avoided unless doing so impairs performance, latency and/or reliability. 6. Wrote a new section on Multicasting. 7. Wrote a new section on Routing. 8. Wrote a new section on Security. Although the deadline for formal submissions is in about 20 minutes, comments are still welcome; I'll keep updating the copy on my website. Phil From owner-pilc@lerc.nasa.gov Mon Nov 27 13:21:33 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14109 for ; Mon, 27 Nov 2000 13:21:32 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA21630 for pilc-outgoing; Mon, 27 Nov 2000 11:22:44 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA21607 for ; Mon, 27 Nov 2000 11:22:42 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA21854; Mon, 27 Nov 2000 11:22:41 -0500 Received: from motgate.mot.com(129.188.136.100) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021787; Mon, 27 Nov 00 11:22:27 -0500 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA21258; Mon, 27 Nov 2000 09:22:25 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA06425; Mon, 27 Nov 2000 09:22:24 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id LAA19633; Mon, 27 Nov 2000 11:22:24 -0500 (EST) Message-Id: <200011271622.LAA19633@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: karn@qualcomm.com cc: pilc@grc.nasa.gov Subject: Re: Updating LINK In-reply-to: Your message of "Wed, 22 Nov 2000 15:14:27 EST." <200011222314.PAA17328@patty.ka9q.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Nov 2000 11:22:23 -0500 From: Dan Grossman Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Phil, The reason for the lengthy exposition was that most people who aren't actively involved in QoS work usually don't understand the issues. My view was (and still is) that a "level set" is needed. Unfortunately, there is not one RFC (and I haven't found a good single paper in the literature) that one can point to that has information of this nature. QoS stuff is somewhat abstract, because unless one starts at first principle, one is likely to get it wrong. I disagree that "this has kept it from making progress in the real world." There are other reasons, which rate a side-discussion in San Diego but are off topic for this list. I don't think that the amount of exposiontion in my proposed text is inconsistent with the amount of exposition on, say TCP. There probably is some material which could be cut back, and if you strongly need to do that, it could be done. However, I really think your current version threw out the baby with the bathwater. It also retained some material that is at least misleading if not incorrect, namely the first couple of paragraphs. WRT subnet designers, in addition to the tutorial material, I think we need at a minimum to make the following points: -- QoS is quantitative and measureable. QoS != priority. -- Don't waste your time on QoS classes; use network mechanisms like RSVP to negotiate -- Don't assume that just setting a few bits in the IP header (TOS or Diffserv) solve your QoS problems -- QoS guarantees require cooperating mechanisms that play together as a system. Some of these are not stateless. I'm not able to do much on this for the next few days. We can talk about this in San Diego, or if you can be specific as to how much material you think needs to be cut out, I can try to rework. Dan From owner-pilc@lerc.nasa.gov Mon Nov 27 20:26: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 SMTP id UAA14672 for ; Mon, 27 Nov 2000 20:26:28 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA01417 for pilc-outgoing; Mon, 27 Nov 2000 19:16:18 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA01410 for ; Mon, 27 Nov 2000 19:16:17 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA22006; Mon, 27 Nov 2000 19:16:16 -0500 Received: from ertpg14e1.nortelnetworks.com(47.234.0.35) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021959; Mon, 27 Nov 00 19:15:44 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Mon, 27 Nov 2000 17:44:44 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 27 Nov 2000 17:44:40 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8923@zwdld001.ca.nortel.com> From: "Gary Kenward" To: "'Dan Grossman'" , karn@qualcomm.com Cc: pilc@grc.nasa.gov Subject: RE: Updating LINK Date: Mon, 27 Nov 2000 17:44:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C058C3.9DDF0680" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C058C3.9DDF0680 Content-Type: text/plain; charset="iso-8859-1" Dan: I could not agree with your email more. It echoes every point I have been trying to designers for the last year. While I also agree with your statement "QoS is quantitative and measurable", I have found that the Diff Serv model tends to, at best, muddy the water. Subnet designers tend to want to define Classes of Service and specify performance bounds (c.f. 3GPP QoS). I consider this a bad approach, as it embeds, at the subnetwork level, QoS definitions that are ultimately application driven. If I understand your observations completely, you are proposing a "parametric control" approach to QoS configuration on the subnet (perhaps using RSVP)? Do you foresee any problems in saying as much in the draft? Regards, Gary Kenward ========================================================================== Gary W. Kenward gkenward@nortelnetworks.com Advisor, Wireless Architecture (613) 765-1437 Advanced Technology Labs FAX: (613) 763-2686 Nortel Networks ========================================================================== As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. -- Albert Einstein -----Original Message----- From: Dan Grossman [mailto:dan@dma.isg.mot.com] Sent: Monday, November 27, 2000 11:22 AM To: karn@qualcomm.com Cc: pilc@grc.nasa.gov Subject: Re: Updating LINK Phil, The reason for the lengthy exposition was that most people who aren't actively involved in QoS work usually don't understand the issues. My view was (and still is) that a "level set" is needed. Unfortunately, there is not one RFC (and I haven't found a good single paper in the literature) that one can point to that has information of this nature. QoS stuff is somewhat abstract, because unless one starts at first principle, one is likely to get it wrong. I disagree that "this has kept it from making progress in the real world." There are other reasons, which rate a side-discussion in San Diego but are off topic for this list. I don't think that the amount of exposiontion in my proposed text is inconsistent with the amount of exposition on, say TCP. There probably is some material which could be cut back, and if you strongly need to do that, it could be done. However, I really think your current version threw out the baby with the bathwater. It also retained some material that is at least misleading if not incorrect, namely the first couple of paragraphs. WRT subnet designers, in addition to the tutorial material, I think we need at a minimum to make the following points: -- QoS is quantitative and measureable. QoS != priority. -- Don't waste your time on QoS classes; use network mechanisms like RSVP to negotiate -- Don't assume that just setting a few bits in the IP header (TOS or Diffserv) solve your QoS problems -- QoS guarantees require cooperating mechanisms that play together as a system. Some of these are not stateless. I'm not able to do much on this for the next few days. We can talk about this in San Diego, or if you can be specific as to how much material you think needs to be cut out, I can try to rework. Dan ------_=_NextPart_001_01C058C3.9DDF0680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Updating LINK

Dan:

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

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

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

Regards,
Gary Kenward

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

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



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


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

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

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

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

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

Dan

 




------_=_NextPart_001_01C058C3.9DDF0680-- From owner-pilc@lerc.nasa.gov Tue Nov 28 12:01: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 SMTP id MAA01109 for ; Tue, 28 Nov 2000 12:01:08 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA14282 for pilc-outgoing; Tue, 28 Nov 2000 10:41:58 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA14243 for ; Tue, 28 Nov 2000 10:41:56 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA15481; Tue, 28 Nov 2000 10:41:54 -0500 Received: from porsta.cs.helsinki.fi(128.214.48.124) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015391; Tue, 28 Nov 00 10:41:18 -0500 Received: from kaloure.cs.Helsinki.FI (kojo@kaloure.cs.Helsinki.FI [128.214.9.79]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with ESMTP id RAA16003; Tue, 28 Nov 2000 17:41:11 +0200 Date: Tue, 28 Nov 2000 17:41:10 +0200 (EET) From: Markku Kojo To: Subject: PEP -05 and SLOW -05 submitted for IETF-49 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk New versions of draft-ietf-pilc-pep-05.txt and draft-ietf-pilc-slow-05.txt have been submitted to internet-drafts@ietf.org. As it might take a while before they will be available at the IETF central repository, I've also made them available at http://www.cs.helsinki.fi/u/kojo/draft-ietf-pilc-pep-05.txt and http://www.cs.helsinki.fi/u/kojo/draft-ietf-pilc-slow-05.txt Thanks, /Markku From owner-pilc@lerc.nasa.gov Tue Nov 28 17:49:35 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27603 for ; Tue, 28 Nov 2000 17:49:35 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA26279 for pilc-outgoing; Tue, 28 Nov 2000 16:24:55 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA26257 for ; Tue, 28 Nov 2000 16:24:53 -0500 (EST) From: afalk@PanAmSat.com Received: by seraph3.lerc.nasa.gov; id QAA07564; Tue, 28 Nov 2000 16:24:53 -0500 Received: from unknown(208.217.183.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma007510; Tue, 28 Nov 00 16:23:55 -0500 Received: by atlconn1.panamsat.com with Internet Mail Service (5.5.2650.10) id ; Tue, 28 Nov 2000 16:23:54 -0500 Message-ID: <0703A3E1D430D411866100508BDFCF33191907@CTOEXCH1> To: agenda@ietf.org, pilc@grc.nasa.gov Cc: mankin@east.isi.edu, spencer.dawkins@fnc.fujitsu.com Subject: PILC working group meeting agenda Date: Tue, 28 Nov 2000 16:22:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Here's the agenda for our meeting in San Diego. Note that we are scheduled to start at 9am on Friday, December 15th. See http://www.ietf.org/meetings/IETF-49.html for more information on the IETF meeting. Please read the updated drafts *before* you come to the meeting. Hope to see you all there. --aaron ---------------------------------------------------------------------------- ------------------------------------------------------------- Performance Implications of Link Characteristics (PILC) MEETING AGENDA - Agenda-bashing (Falk/Dawkins) - Working Group Status (Falk/Dawkins) - Update on TCP over Asymmetric Links (ASYM) (Falk) - Update on TCP over Wireless doc (Falk) - Update on Performance Enhancing Proxies (PEP) doc (Border/Kojo) - Update on Advice for Internet Subnetwork Designers (LINK) doc (Karn) - Discussion on Reliable Link Layer summary (Karn for Fairhurst) From owner-pilc@lerc.nasa.gov Tue Nov 28 19:42:32 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13101 for ; Tue, 28 Nov 2000 19:42:31 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA11485 for pilc-outgoing; Tue, 28 Nov 2000 18:36:22 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA11464; Tue, 28 Nov 2000 18:36:20 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA23830; Tue, 28 Nov 2000 18:36:18 -0500 Received: from tc070.bbn.com(128.33.238.70) by seraph3.lerc.nasa.gov via smap (V5.5) id xmaa23735; Tue, 28 Nov 00 18:36:00 -0500 Received: from lawyers.grc.nasa.gov (mallman@localhost) by lawyers.grc.nasa.gov (8.9.3/8.9.3) with ESMTP id LAA00331; Tue, 28 Nov 2000 11:35:17 -0500 Message-Id: <200011281635.LAA00331@lawyers.grc.nasa.gov> To: tcpsat@grc.nasa.gov, pilc@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: Michael Hadjitheodosiou: CFP: Communications for Space Missions Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Roadhouse Blues Date: Tue, 28 Nov 2000 11:35:16 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk I was asked to forward this announcement to folks on tcpsat and pilc, as there very well could be interested folks on these lists. allman ------- Forwarded Message Date: Fri, 20 Oct 2000 15:51:09 -0400 To: mallman@grc.nasa.gov From: Michael Hadjitheodosiou Subject: CFP: Communications for Space Missions Call For Papers: Special Issue of the International Journal of Satellite Communications: Communications for Space Missions - ------------------------------------------------------------------------------- The start of the deployment of the International Space Station and an increasing number of planetary and other scientific missions have ushered in a new era in space exploration. At the same time, advances in communication technologies will allow investigators on Earth to enjoy a virtual presence in space. This generates a need to provide researchers with high quality communication support that will enable cost effective global access to experimental data from future space missions. Space agencies, like NASA, as well as Industry are also interested to gradually facilitate broadband Internet services throughout future space missions, eventually leading to a scenario where every spacecraft and instrument can be an addressable node and have a direct connection to the Internet. At the same time, there is a drive for space agencies to start utilizing capacity from commercial providers and adopt Commercial Of The Shelf technology. There is clearly a gradual transition to an operational scenario that will enable investigators to access their data "anytime, anywhere" through the Internet. For these reasons, the International Journal of Satellite Communications is launching a special issue on "Communications for Space Missions". This special issue will publish papers describing recent experiences and innovative new ideas on these issues. Specific topics of interest include, but are not limited to: - -Communication Architectures for supporting future near-Earth or Planetary missions. - - Network Issues related to extending IP services to next generation spacecraft. - - New Coding and Modulation techniques for Deep Space Missions. - - Related Antenna Technology developments (e.g. Ka-band, Phased Arrays). - - Protocol support for space missions [Custom protocols (SAFE, SCPS) Vs standard internet protocols (TCP/IP, FTP)]. - - Networking issues for constellations of : -formation flying Nano-satellites,; -networked sensors in space; -the "distributed spacecraft" concept. - - Supporting mission requirements using commercial satcomm providers. DEADLINES Intention to Submit with Abstract (up to 500 words): December 31st, 2000 (Include Full Paper, if available) Full Paper Due: February 28, 2001 Review Process/ Final Paper Due: June 30, 2001 Expected Publication Date: Summer 2001 SUBMISSION INSTRUCTIONS Interested authors should submit a Title / Abstract to : Dr. Michael Hadjitheodosiou Center for Satellite & Hybrid Communication Networks ISR, A.V. Williams Building University of Maryland, College Park MD 20742, USA Tel:+301-405-7904 Fax:+301-314-8586 e-mail: michalis@isr.umd.edu Preferred Method of Submission: - ------------------------------- By e-mail to: michalis@isr.umd.edu Abstract: TXT Format Full Paper: PDF (preferred), Postscript or MS Word electronic attachment. - --------------------------------------------------------------------------- The International Journal of Satellite Communications provides a focus for professionals in all aspects of satellite communications. The Journal covers all aspects of the theory and practice of satellite systems and networks. Information about the Journal: http://www.interscience.wiley.com/jpages/0737-2884/info.html ------- End of Forwarded Message From owner-pilc@lerc.nasa.gov Wed Nov 29 15:04:44 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14251 for ; Wed, 29 Nov 2000 15:04:41 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA20605 for pilc-outgoing; Wed, 29 Nov 2000 13:51:39 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA20510 for ; Wed, 29 Nov 2000 13:51:36 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA23591; Wed, 29 Nov 2000 13:51:30 -0500 Received: from ertpg14e1.nortelnetworks.com(47.234.0.35) by seraph3.lerc.nasa.gov via smap (V5.5) id xma023484; Wed, 29 Nov 00 13:50:57 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Wed, 29 Nov 2000 13:30:41 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 29 Nov 2000 13:30:41 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A893D@zwdld001.ca.nortel.com> From: "Gary Kenward" To: pilc@grc.nasa.gov Subject: comments on draft-pilc-link-arq-issues-00 Date: Wed, 29 Nov 2000 13:30:28 -0500 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05A32.72DEC2C0" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C05A32.72DEC2C0 Content-Type: text/plain; charset="iso-8859-1" I have two comments on the draft draft-pilc-link-arq-issues-00: 1. Under Section 2, ARQ Persistence, the second paragraph attempts to define "retransmission persistence". There are many dimensions to persistence at the link layer, and I feel the current description is not clear enough. From an ARQ perspective, there is not only the duration of repeated attempts, but also the frequency and priority of the attempts. The reason I was initially confused by the text is that I am more familiar with the definition of persistence as used with stochastic contention resolution protocols such as CSMA; e.g. p-persistent CSMA refers to the probability that a retransmission will be attempted within a certain time period. Perhaps this is too much detail for a draft of this scope, however, given that the concept of persistence is used throughout the draft, it should be defined more crisply, and, the definition should be complete. 2. In the subsections 2.n, you characterize different types of persistence as a trade off between delay and reliability. Again, frequency and priority of repeats must be accounted for in your taxonomy. However, I also wanted to point out that the reason many protocols, including Ethernet, use a finite number of repeated transfer attempts (or retransmissions in Ethernet) is to ensure *stability* of the channel. An ARQ protocol with an infinite number of repeated attempts is generally unstable. A finite number of retransmissions does not necessarily ensure stability. I do not have the references at hand (I could probably find them if you are interested), but for a finite population size, stability bounds on the number of repeats have been derived for particular protocols (e.g. CSMA, ALOHA, S-CSMA, S-ALOHA). I hope these comments help. If I have missed something, I would happy to know it. Gary Kenward ========================================================================== Gary W. Kenward gkenward@nortelnetworks.com ========================================================================== As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. -- Albert Einstein ------_=_NextPart_001_01C05A32.72DEC2C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable comments on draft-pilc-link-arq-issues-00

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

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

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

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

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

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

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

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

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

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

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


------_=_NextPart_001_01C05A32.72DEC2C0-- From owner-pilc@lerc.nasa.gov Thu Nov 30 06:55: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 SMTP id GAA25920 for ; Thu, 30 Nov 2000 06:55:24 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA11093 for pilc-outgoing; Thu, 30 Nov 2000 05:57:29 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id FAA11079 for ; Thu, 30 Nov 2000 05:57:27 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id FAA28849; Thu, 30 Nov 2000 05:57:26 -0500 Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028826; Thu, 30 Nov 00 05:57:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28006; Thu, 30 Nov 2000 05:57:14 -0500 (EST) Message-Id: <200011301057.FAA28006@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pilc@grc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pilc-asym-02.txt Date: Thu, 30 Nov 2000 05:57:13 -0500 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF. Title : TCP Performance Implications of Network Asymmetry Author(s) : H. Balakrishnan, V. Padmanabhan Filename : draft-ietf-pilc-asym-02.txt Pages : 15 Date : 29-Nov-00 This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio networks, for different underlying reasons. However, the net effect on TCP performance is the same in both cases: performance degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender. This document details several solutions to these problems, which use a combination of local link-layer techniques and end-to-end mechanisms. Solutions to the problem of asymmetry are two-pronged: (i) techniques to manage the reverse channel used by ACKs, typically using header compression or reducing the frequency of TCP ACKs, and (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's acknowledgment-triggered self-clocking. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-asym-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pilc-asym-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-asym-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001129114548.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-asym-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-asym-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001129114548.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Thu Nov 30 11:16: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 SMTP id LAA13960 for ; Thu, 30 Nov 2000 11:16:08 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA06090 for pilc-outgoing; Thu, 30 Nov 2000 09:44:59 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA06066 for ; Thu, 30 Nov 2000 09:44:57 -0500 (EST) From: V@tzw.de Received: by seraph3.lerc.nasa.gov; id JAA23413; Thu, 30 Nov 2000 09:44:55 -0500 Received: from unknown(202.103.160.51) by seraph3.lerc.nasa.gov via smap (V5.5) id xma023352; Thu, 30 Nov 00 09:44:37 -0500 Received: from h809 (1Cust103.tnt3.mia5.da.uu.net [63.30.200.103]) by bbs.ht.net.cn (8.8.7/8.7.3) with SMTP id XAA27158; Thu, 30 Nov 2000 23:04:47 +0800 Date: Thu, 30 Nov 2000 23:04:47 +0800 Message-Id: <200011301504.XAA27158@bbs.ht.net.cn> To: V@tzw.de Subject: Lady V: The Pleasure Pill for Women! Sender: owner-pilc@lerc.nasa.gov Precedence: bulk LADY V: The Pleasure Pill for Women! Men Have Their Viagra®! Finally, A Pill for Women! It's Here! The Revolutionary Woman's Sexual Sensation is Now Available. Researchers are calling Lady V the greatest breakthrough for women since the Birth Control Pill. And you don't even need a prescription to get it! Welcome to the New Sexual Revolution! It's no secret that men have been having the time of their lives since the wonder pill Viagra® was made available. But, women were left out in the cold with no pill... nothing! Well now thanks to an all-star team of medical researchers who have been working around the clock, those days are finally over. The perfect female "pleasure pill" has been created and you don't even need a prescription. You can now get it from Lion Sciences! Lady V is the world's first pleasure pill scientifically designed for women. Lady V is an all-natural proprietary herbal blend of prosexual nutrients from around the world synergistically blended to naturally stimulate neurotransmitter endorphin signals. This magical combination increases targeted blood flow, unleashes natural stimulator for maximum stimulation, triggering pleasure responses quickly. Lady V is safe, natural and doctor-recommended. Since its introduction Lady V has been taking the world by storm! From Malibu to Miami women are enjoying the most intense pleasure of their lives! • 100% Natural • Safe • The Highest Quality Pharmaceutical Pure Nutraceuticals • Guaranteed Potency • Certified Purity Lady V is Sweeping the Nation! Women are going crazy over Lady V. Suddenly couples are falling in love all over again. The passion and pleasure that women are reporting is off the charts! Lady V has an incredible 88% success rate. Best of all, while Viagra costs $10 a pill, Lady V costs less than $1 a pill! It's not just a man's world anymore! Just look at what a few women have to say: "I thought my love life was good before, but now it is out of this world! Lady V is remarkable." — Mary J., Interior Designer "I haven't smiled like this in a long time. My husband and I feel like a couple of 19 year olds again!" — Debra T, Assistant Buyer "Imagine what it would feel like to have incredible passion and pleasure anytime you want." — Jennifer C., Film Editor "Suddenly my husband and I are spending more time in the bedroom instead of the TV room." — Angie R., Realtor Ingredients: Vitamin D, Niacin, Vitamin B6, Folic Acid, Vitamin B12, Avena Sativa, Kava Kava, Guarana, White Willow Extract, Mura Puama, St. John's Wort, Siberian Ginseng, Cordyceps, Damiana, and L-Taurine. Each bottle of Lady V contains 30 tablets. Take three capsules one hour before romantic activity as a dietary supplement. Risk Free: Double Your Money Back Guarantee If Lady V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked! Order Now: Safe, Fast, Secure, Private Lady V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Lady V contains 30 tablets. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Lady V $24 ______ 2 Bottles of Lady V $44 ______ 3 Bottles of Lady V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ] International Orders Please add $18 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$42, 2 bottles=$62, 3 bottles=$77 ] We cannot accept foreign checks. International money orders or credit cards only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 273 S. State Rd. 7, #193 Margate, FL 33068-5727 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Lady V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Lady V helps provide herbal and nutritional support for female sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From owner-pilc@lerc.nasa.gov Thu Nov 30 21:29:24 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05186 for ; Thu, 30 Nov 2000 21:29:23 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA06427 for pilc-outgoing; Thu, 30 Nov 2000 20:25:09 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id UAA06412 for ; Thu, 30 Nov 2000 20:25:07 -0500 (EST) From: Younger@bdsm.at Received: by seraph3.lerc.nasa.gov; id UAA23586; Thu, 30 Nov 2000 20:25:06 -0500 Date: Thu, 30 Nov 2000 20:25:06 -0500 Message-Id: <200012010125.UAA23586@seraph3.lerc.nasa.gov> Received: from gencat.es(194.179.95.227) by seraph3.lerc.nasa.gov via smap (V5.5) id xma023526; Thu, 30 Nov 00 20:24:45 -0500 Received: from aks011 (1Cust54.tnt1.mia5.da.uu.net [63.30.194.54]) by mail.governacio-ri.gencat.es with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id X8T2JYZ3; Fri, 1 Dec 2000 02:22:54 +0100 To: Younger@bdsm.at Subject: REVERSE the AGING PROCESS 10-20 Years! MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)??? Released by your own pituitary gland, HGH starts declining in your 20s, even more in your 30s and 40s, eventually resulting in the shrinkage of major organs-plus all other symptoms related to old age. THIS CAN NOW BE REVERSED!!! IN THOUSANDS OF CLINICAL STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING: * Reduce Body Fat Without Dieting Build Lean Muscle WITHOUT EXERCISE! * Enhance Sexual Performance * Remove Wrinkles and Cellulite * Lower Blood Pressure and improve Cholesterol Profile * Improve Sleep, Vision and Memory * Restore Hair Color and Growth * Strengthen the Immune System * Increase Energy and Cardiac Output * Turn back your body's Biological Time Clock 10-20 years in 6 months of usage !!! You don't have to spend thousands of dollars on shots. You don't have to spend the $139.00 per bottle that HGH is selling for at some Clinics in the United States. For the next 30 Days, you can obtain a complete one-month supply of our HGH releaser for our special "New Customers" price of just $69.95 plus $6.00 shipping and handling. To ensure a constant supply and to SAVE EVEN MORE, you can order with confidence 3 bottles of HGH and GET 1 FREE - that's just $209.85 for 4 bottles, plus $6.00 shipping and handling. You SAVE $69.95! ORDER TODAY! Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express payments. Money Orders are accepted only by Postal Mail. Step 1: Place a check by your desired quanity. ______ 1 Bottle of HGH $69.95 ______ 2 Bottles of HGH $131.90 ($65.95 a bottle) ______ 4 Bottles of HGH (Buy 3 get 1 FREE. SAVE $69.95) $209.85 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$75.95, 2 bottles=$137.90, 4 bottles=$215.85 ] International shipping, please add $35 for any size order [ Total cost including shipping & handling, 1 bottle=$104.95, 2 bottles=$166.90, 4 bottles=$244.85 ] Foreign checks are not accepted. Credit cards & international money orders only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: Lion Sciences National 273 S. State Rd. 7 #193 Margate, FL 33068-5727 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: HGH is not intended to diagnose, treat, cure or prevent any disease. The FDA has not evaluated these statements.