From owner-pilc@lerc.nasa.gov Mon Feb 7 11:35:19 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14487 for ; Mon, 7 Feb 2000 11:35:18 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA14283 for pilc-outgoing; Mon, 7 Feb 2000 10:05:54 -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 ESMTP id KAA14244; Mon, 7 Feb 2000 10:05:51 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA19986; Mon, 7 Feb 2000 10:05:49 -0500 (EST) Received: from smtp7.atl.mindspring.net(207.69.128.51) by seraph3.lerc.nasa.gov via smap (V5.0) id xma019858; Mon, 7 Feb 00 10:05:20 -0500 Received: from dave2 (user-33qt8bb.dialup.mindspring.com [199.174.161.107]) by smtp7.atl.mindspring.net (8.9.3/8.8.5) with SMTP id KAA13601; Mon, 7 Feb 2000 10:05:15 -0500 (EST) Reply-To: From: "David R. Beering" To: , , Subject: CALL FOR PARTICIPATION - Explicit Corruption Notification Experiments Date: Mon, 7 Feb 2000 09:05:27 -0600 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.2314.1300 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit C A L L F O R P A R T I C I P A T I O N Study of Mechanisms and Algorithms for TCP/IP Explicit Corruption Notification NASA Glenn Research Center at Lewis Field Background: For the past three years a group of researchers, along with a large group of partner organizations from industry and government laboratories, have been engaged in a multi-platform TCP/IP performance experiment using NASA's Advanced Communications Technology Satellite (ACTS). This experiment, currently known as ACTS Experiment 154, has focused on TCP/IP performance optimization over the ACTS Geostationary satellite at data rates of 155Mbps and 622Mbps. As a result of extensive FEC, these channels typically operate error-free, providing an ideal environment for TCP performance testing. More information on the experiment is provided below: Purpose: Testing of TCP/IP performance and interoperability using NASA's Advanced Communications Technology Satellite (ACTS). Testing is conducted in homogeneous host configurations (i.e. Sun-to-Sun) and in heterogeneous host configurations (i.e. Sun to IBM). Primary experiment Components: 1. Single-stream TCP/IP performance testing over satellite channels with bandwidth-delay products of up to 70 MBytes 2. Research and development / discovery of new techniques to help TCP distinguish between channel corruption and congestion Technical Environment: Workstation interfaces (LAN): - 100BaseT - Gigabit Ethernet - ATM (155 Mbps and 622 Mbps) Satellite Channel: - 1 x 155 Mbps SONET - 2 x 155 Mbps SONET - 1 x 622 Mbps SONET WAN Interfaces: - 155 Mbps ATM - 622 Mbps ATM - 155 Mbps PoS - 622 Mbps PoS The 154 Experiment Consortium presently includes the following participants: NASA Glenn Research Center NASA Johnson Space Center NASA Jet Propulsion Laboratory NASA Goddard Space Flight Center US Naval Research Laboratory Lawrence Livermore National Laboratory Marconi Communications Cisco Systems Ampex Data Systems Cabletron Systems Raytheon Telecommunications Spectrum Astro Lockheed Martin Space Systems / Loral Hughes Space & Communications Sun Microsystems Intel Microsoft Compaq IBM Hewlett-Packard NetManage WindRiver Systems More information: For more information on the experiment, including some historical TCP performance test results, please visit our public web site, located at the URL below: http://mrpink.grc.nasa.gov/118x The Opportunity: Our team is in the process of building a new testbed facility that will support links across the ACTS spacecraft at data rates ranging up to 8 Mbps, with any bit error rate. The testbed will utilize laboratories at the NASA Glenn Research Center in Cleveland, the US Naval Research Laboratory in Washington, DC, and Lockheed Martin Space Operations in Houston. We will also be able to leverage the unique ability of ACTS to support satellite links operating at extremely high rates (155Mbps, 622Mbps) for this work, should that be desirable in the context of these tests. The focus of the new laboratory capability will be to specifically study mechanisms that provide explicit notification of link corruption and congestion, with the goal of gaining a better understanding of these mechanisms in order to promote further work on the most promising mechanisms. The eventual goal of this work is the make it possible for Explicit Corruption Nofitication mechanisms to be safe for implementation in the Internet at-large. This work is expected to continue beyond the end of life of the ACTS spacecraft, presently slated for the end of June, 2000. We are soliciting participation from the Internet community through personal invitations, and through this announcement being distributed via the IETF's 'tcpsat', 'pilc', and 'end2end' interest groups. We are in the process of assembling the workstations and networking hardware to support this experiment. This initially will include Unix workstations supporting Solaris 7, and PC platforms supporting Linux. Other platforms and operating system environments will be added depending on requirements. Experiment proposals will be evaluated by our team for their ability to be integrated into and tested in our environment. For those mechanisms selected for testing, we will provide access to the hardware platforms (in-person and/or remote), and satellite time on the ACTS spacecraft for testing and evaluation of the mechanisms. If your organization is involved in the development of algorithms or mechanisms in the area of explicit corruption notification, and you would be interested to participate in this experiment, please contact our team at one of the contact coordinates below: David R. Beering Experiment 154 Coordinator NASA Glenn Research Center drbeering@sprynet.com 630-665-1396 (Office) 630-235-7965 (PCS) or Michael J. Zernic ACTS HDR Experiment Manager NASA Glenn Research Center mzernic@grc.nasa.gov 216-433-5286 (Office) or Mark Solsman United States Naval Research Laboratory Information Technology Division Satellite and Wireless Networking Section solsman@nrl.navy.mil 202-404-4667 (Office) From owner-pilc@lerc.nasa.gov Wed Feb 9 16:01:12 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23574 for ; Wed, 9 Feb 2000 16:01:12 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA23975 for pilc-outgoing; Wed, 9 Feb 2000 14:12:30 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA23935 for ; Wed, 9 Feb 2000 14:12:28 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA29824; Wed, 9 Feb 2000 14:12:26 -0500 (EST) Received: from mail.ececs.uc.edu(129.137.8.2) by seraph3.lerc.nasa.gov via smap (V5.0) id xma029790; Wed, 9 Feb 00 14:12:07 -0500 Received: from wayward.ececs.uc.edu (wayward.ececs.uc.edu [129.137.9.117]) by babbage.ececs.uc.edu (8.9.3+Sun/8.9.3) with ESMTP id OAA26467 for ; Wed, 9 Feb 2000 14:11:57 -0500 (EST) From: Samir Das Received: (from sdas@localhost) by wayward.ececs.uc.edu (8.9.3+Sun/8.9.1) id OAA24231 for pilc@grc.nasa.gov; Wed, 9 Feb 2000 14:11:42 -0500 (EST) Message-Id: <200002091911.OAA24231@wayward.ececs.uc.edu> Subject: MobiCom 2000 (note new deadline) To: pilc@grc.nasa.gov Date: Wed, 9 Feb 2000 14:11:42 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit -- Final Call for Papers -- MobiCom 2000 The Sixth Annual International Conference on Mobile Computing and Networking August 6-11, 2000 Seaport Hotel at the World Trade Center Boston, Massachusetts, USA ** The paper submission deadline for MobiCom 2000 is approaching. ** ** The new extended deadline is Feb 25, 2000. ** ** Visit http://www.research.telcordia.com/mobicom2000/ for the ** ** complete Call for Papers and submission instructions. ** Sponsored by ACM SIGMOBILE; In cooperation with ACM SIGCOMM and SIGMETRICS; the USENIX Association; the IEE; the IEICE (Japan); KICS (Korea) and the IFIP WG 6.3 -------------------------------------------------------------------- IMPORTANT DATES: Paper submissions due: February 25, 2000 <- extended Notification of acceptance: April 28, 2000 Camera-ready version due: May 26, 2000 -------------------------------------------------------------------- Send email to mobicom2000@research.telcordia.com with any questions or comments about the conference or for more information. Please excuse us if you receive duplicates of this message via different email lists. From owner-pilc@lerc.nasa.gov Thu Feb 24 13:20:06 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07915 for ; Thu, 24 Feb 2000 13:19:59 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA24164 for pilc-outgoing; Thu, 24 Feb 2000 12:06: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 ESMTP id MAA24140 for ; Thu, 24 Feb 2000 12:06:16 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA12190; Thu, 24 Feb 2000 12:06:15 -0500 (EST) Received: from unknown(208.217.183.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma012170; Thu, 24 Feb 00 12:06:07 -0500 Received: by atlconn1.panamsat.com with Internet Mail Service (5.5.2448.0) id ; Thu, 24 Feb 2000 12:06:07 -0500 Message-ID: <8046A317B5F4D21186610008C7EBB696F055EE@grnexch1.panamsat.com> From: "Falk, Aaron" To: "'pilc@grc.nasa.gov'" Cc: "Phil Karn (E-mail)" Subject: Draft on Advice for Internet Subnetwork Designers Date: Thu, 24 Feb 2000 12:02:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Folks-- A very important piece of work for PILC is the LINK draft that Phil Karn is editing. There has been a strong consensus that such a document is needed to give link designers a clue about how to carry Internet traffic. As Phil has eloquently put it, "most errors are those of commission, rather than omission." So, there is a need to express to folks designing links what services Internet protocols provide in a way that they can make design decisions. I've had a lot of these conversations on the satellite systems that worked on and I know many of the subscribers on this list have also. What is needed is to capture the design principles in a single place so that the gap between the physical layer community (particularly RF) and the Internet community (particularly Transport) can be bridged. I would like to encourage those who haven't done so recently to read http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-01.txt and comment to this list. Also, there are some holes in the document that need filling. (see below) I don't believe any individual can do this whole thing but we need someone to commit some time to generate a few paragraphs so that we can converge on some recommendations. The deadline for draft submission in time for the next IETF is March 10th. So, to incorporate your comments and turn around an iteration of the draft, a rapid dialog is needed. Thanks in advance for your help. --aaron ================= LINK placeholder sections: Quality of Service, Fairness vs Performance, Congestion signalling [subnet hooks for QOS bits] Delay Characteristics [self clocking TCP, (re)transmission shaping] Buffering, flow & congestion control [atm dropping individual cells in a packet means the entire packet must be dropped unless EPD/PPD is used] Mobility [best provided at a higher layer, for performance and flexibility reasons, but some subnet mobility can be a convenience as long as it's not too inefficient with routing] Routing [what is proper division between routing at the Internet layer and routing in the subnet? Is it useful or helpful to Internet routing to have subnetworks that provide their own internal routing?] Security [Security mechanisms should be placed as close as possible to the entities that they protect. E.g., mechanisms that protect host computers or users should be implemented at the higher layers and operate on an end-to-end basis under control of the users. This makes subnet security mechanisms largely redundant unless they are to protect the subnet itself, e.g., against unauthorized use.] --- Aaron Falk Director - Internet Services Development PanAmSat Corporation Greenwich, Connecticut, USA * Tel: 203.861.8326 * Fax: 203.861.8677 * mailto:afalk@panamsat.com * http://www.panamsat.com From owner-pilc@lerc.nasa.gov Mon Feb 28 05:24: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 ESMTP id FAA02358 for ; Mon, 28 Feb 2000 05:24:06 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA14624 for pilc-outgoing; Mon, 28 Feb 2000 04:10: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 ESMTP id DAA13627; Mon, 28 Feb 2000 03:54:16 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id DAA06603; Mon, 28 Feb 2000 03:54:16 -0500 (EST) Received: from leonis.nus.edu.sg(137.132.1.18) by seraph3.lerc.nasa.gov via smap (V5.0) id xma006596; Mon, 28 Feb 00 03:54:05 -0500 Received: from engtanlk.nus.edu.sg ([137.132.204.177]) by leonis.nus.edu.sg (8.9.3/8.9.3) with SMTP id PAA18765; Tue, 22 Feb 2000 15:26:44 +0800 (SST) Message-ID: <005001bf7d06$a56fb320$b1cc8489@engtanlk.nus.edu.sg> From: "ICON'2000 Secretariat" To: Subject: Calling for your contribution! Date: Tue, 22 Feb 2000 15:26:39 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01BF7D49.B392F320" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_004D_01BF7D49.B392F320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All =20 * Kindly ignore this email if you have received this before.=20 Thanks you for your kind attention. =20 The 8th IEEE International Conference On Networks will be held from=20 September 5- 8, 2000 in Singapore. The aim of the conference is to = provide=20 an international forum for experts to promote, share and discuss various = issues and developments in the broad field of computer and communication = networks. We thus seek and solicit your contributions in the form of original/unpublished papers, tutorials, and topics for=20 special sessions/panel discussions. More information on the scope of the = conference and the guidelines for the submission of contributions can be obtained at this web site : http://www.comp.nus.edu.sg/~icon/ We look forward to your participation. Thank you. Icon 2000 organizing Committee ------=_NextPart_000_004D_01BF7D49.B392F320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear All
 
*=20 Kindly ignore this email if you have received this before.=20
Thanks you for your kind = attention.
 

The 8th IEEE International Conference On Networks will be held from =

September 5- 8, 2000 in Singapore. The aim of the conference is to = provide=20

an international forum for experts to promote, share and discuss = various

issues and developments in the broad field of computer and = communication

networks. We thus seek and solicit your contributions

in the form of original/unpublished papers, tutorials, and topics for =

special sessions/panel discussions. More information on the scope of = the

conference and the guidelines for the submission of contributions = can

be obtained at this web site :

http://www.comp.nus.edu.sg/~ic= on/

We look forward to your participation. Thank you.

Icon 2000 organizing=20 Committee

------=_NextPart_000_004D_01BF7D49.B392F320-- From owner-pilc@lerc.nasa.gov Mon Feb 28 11:05:05 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12685 for ; Mon, 28 Feb 2000 11:05:04 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA14863 for pilc-outgoing; Mon, 28 Feb 2000 09:55:51 -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 ESMTP id JAA14825 for ; Mon, 28 Feb 2000 09:55:48 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id JAA08788; Mon, 28 Feb 2000 09:55:46 -0500 (EST) Received: from percy.erg.abdn.ac.uk(139.133.204.86) by seraph3.lerc.nasa.gov via smap (V5.0) id xma008678; Mon, 28 Feb 00 09:55:04 -0500 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.10.0.Beta12/8.10.0.Beta12) with ESMTP id e1SF0QI17097; Mon, 28 Feb 2000 15:00:27 GMT Message-ID: <38BA7E19.CB9D89B1@erg.abdn.ac.uk> Date: Mon, 28 Feb 2000 15:06:57 +0100 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 CC: "'pilc@grc.nasa.gov'" , "Phil Karn (E-mail)" Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <8046A317B5F4D21186610008C7EBB696F055EE@grnexch1.panamsat.com> 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 Here are some comments on Link Level Issues: "Falk, Aaron" wrote: > Folks-- > > A very important piece of work for PILC is the LINK draft that Phil Karn is > editing. > http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-01.txt PAGE 4: MTU Size It may be useful to note that using IPSEC in tunnel mode can increase the size of a packet as it travels across the network. This can result in a smaller MTU. PAGE 6: ALTERNATE FRAMING TECHNIQUES In AAL5, the 1-bit per segment flag, carried in the ATM header, indicates the end of a PDU. The PDU control information (trailer) is located at the end of the segment. Placing the trailer in a fixed position may simplify hardware reassembly. Another framing technique is to insert per segment overhead which indicates the presence of a segment option. When present, the option carries a pointer to the end of the PDU. This differs from AAL5, in that it permits another PDU to follow within the same segment. MPEG-2 supports this style of fragmentation, and may utilise either padding (limiting each transport stream packet to carry only part of one PDU with padding, or to allow a second PDU to start (no padding)). Reference: MPEG-2 or DVB reference. PAGE 6: SEGMENTATION AND CRCs I can find no recommendations on integrity checks. I enclose some text below: Most packet protocols rely upon error control at the data link layer using a Cyclical Redundancy Check (CRC) at the end of the frame. Some character-based protocols rely on less powerful error detection algorithms (e.g. parity, block checksum character); these are not well suited to a link which may be subject to varying levels of error. The IPv4 packet header contains a header checksum that verifies the integrity of the header. This checksum was originally design to protect from router software errors, however this function is no longer necessary. IPv6 does not therefore implement a network level integrity checksum. The role of the IP checksum has therefore been subsumed into the TCP and UDP checksums. This has two implications for satellite links: (1) Transport protocols should use a payload checksum when using IPv4 satellite links and must implement a checksum when used with IPv6, (previously UDP had an option to use no checksum (value=0) which had for a time been widely used for NFS in LANs). (2) Link layer protocols should provide adequate protection from transmission errors. Whereas in previous cases, small CRCs or no CRC (in the case of SLIP) have been tolerated. A CRC-32 is desirable for each packet (as in Ethernet). Links that perform transparent fragmentation may use apply the CRC to the PDU prior to segmentation and check after reassembly. Reference on suitability of CRC-32: "M. Greenwald, C. Partridge, and J. Hughes, Performance of Checksums and CRC's over Real Data, IEEE/ACM Transactions on Networking, 6(5), 529-543 (1998)" PAGE 13: Link ARQ I think it may be wise to note that there are two approaches to TCP friendly link ARQ. One has been put forward by Balakrishnan: "H. Balakrishnan, V.N. Padmanabhan, S Seshan, and R H Katz, A Comparison of Mechanisms for Improving TCP Performance over Wireless Links. IEEE Trans Net, 1997. 5(6): p. 756-759." In this case, TCP headers are read and the information used to tune the link protocol. The other approach is to bound link behaviour to match TCP "requirements" i.e. A receiver may calculate the variation of the recovery delay and then give up, if the variation which will be introduced is more than that can be tolerated by the TCP transport layer. This latter approach was summarised in one of our papers: "N Samaraweera and G Fairhurst Robust Data Link Protocols for Connection-less Service over Satellite Links. Int J. Sat Coms, 1996. 14(5): p. 427-437." PAGE 13: PACKET or FRAME? The use of "Packet" with ARQ, could be confused here.... Consider the statement: "Note that the packet size plays an important role. Larger packet sizes will allow for improved performance at the same *packet loss* rate." This is only true if packet equate to MSS or transparent fragmentation is used. Not so, for IP segmentation... In the following calculations MSS is not correct, you mean MSS+all headers including TCP, IP, Link and Physical pre/mid ambles. PAGE 13: Hybrid ARQ You do not mention that hybrid ARQ may combine the properties of ARQ and FEC. PAGE 14: GEO Satellite Delay "Links running over geostationary repeater satellites have one-way times of around 250ms (125ms up to the satellite, 125ms down) so the RTT of an end-to-end TCP connection that includes such a link can be expected to be greater than 250ms." Well, often a duplex satellite link is used. So the delay added is 2x250 ms (one to get there, and one to get back). ------------ Best wishes, Gorry Fairhurst From owner-pilc@lerc.nasa.gov Mon Feb 28 11:06:01 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12727 for ; Mon, 28 Feb 2000 11:06:00 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA14864 for pilc-outgoing; Mon, 28 Feb 2000 09:55:51 -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 ESMTP id JAA14827 for ; Mon, 28 Feb 2000 09:55:49 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id JAA08785; Mon, 28 Feb 2000 09:55:46 -0500 (EST) Received: from percy.erg.abdn.ac.uk(139.133.204.86) by seraph3.lerc.nasa.gov via smap (V5.0) id xma008752; Mon, 28 Feb 00 09:55:33 -0500 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.10.0.Beta12/8.10.0.Beta12) with ESMTP id e1SF0xI17110; Mon, 28 Feb 2000 15:00:59 GMT Message-ID: <38BA7E3B.A8C5C631@erg.abdn.ac.uk> Date: Mon, 28 Feb 2000 15:07:30 +0100 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 CC: "'pilc@grc.nasa.gov'" , "Phil Karn (E-mail)" Subject: Re: Draft on Advice for Internet Subnetwork Designers References: <8046A317B5F4D21186610008C7EBB696F055EE@grnexch1.panamsat.com> 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 Here are some comments on TCP Issues: "Falk, Aaron" wrote: > Folks-- > > A very important piece of work for PILC is the LINK draft that Phil Karn is > editing. > http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-01.txt PAGE 9: New-Reno The ID says... "Taking this as a hint that the network is congested, TCP waits for the retransmission to be ACKed before it continues, and it gradually increases the number of packets in flight as long as a timeout does not occur again." New Reno modifies this statement slightly, by adding the concept of a retransmission phase: Hoe noted that a smaller value for ssthresh causes premature termination of the slow start phase and subsequent slow (linear) increase of the cwnd. A larger value causes the sender to over-feed packets to the network (i.e. transmit too long a burst of data packets) causing congestion. Since most TCP sessions last only for a short period of time, the initial slow start period is significant for the over all performance. New Reno also introduces the concept of a Fast Retransmission Phase which improves performance when two or more segments have been lost (from the same window of data). In Reno, the Fast Retransmission and Fast Recovery algorithms will not be able to recover such losses without waiting for retransmission time out. New-Reno overcomes this problem by introducing a Fast Retransmission Phase, which starts on detection of a packet loss (receiving 3 duplicate ACKs) and ends when the receiver acknowledges reception of all data transmitted at the start of the Fast Retransmission phase. If more than one packet is missing within the same window, a retransmission only recovers the first lost packet from the window. The receiver then ACKs reception of the retransmitted segment and all following segments up to the next lost segment. This ACK is called a "partial ACK", because it has not ACKed all the packets which were transmitted prior to the start of the current Fast Retransmission Phase. The transmitter assumes reception of a partial ACK during the Fast Retransmission phase as an indication that another packet has been lost within the window and retransmits that packet immediately to prevent expiry of the retransmission timer. New Reno sets the cwnd to one segment on reception of 3 duplicate ACKs (i.e. when entering the Fast Retransmission Phase) and unacknowledged data are retransmitted using the Slow Start algorithm. The transmitter is also allowed to transmit a new data packet on receiving 2 duplicate ACKs. While the transmitter is in the Fast Retransmission Phase, it continues to retransmit packets using Slow Start until all packets have been recovered (without starting a new retransmission phase for partial ACKs). Although this modification may cause some unnecessary retransmissions, it reduces transmitter time outs and efficiently recovers multiple packet loss using partial ACKs. PAGE 10: SACK It is important to stress the role of SACK for TCP. This has benefits in terms of improved retransmission, but also in improved congestion assessment when used in combination with new-reno. For a discussion of SACK under satellite error conditions, see "N Samaraweera, and G Fairhurst, Reinforcement of TCP/IP Error Recovery for Wireless Communications. Computer Communications Review (CCR), 1998. 28(2): p. 30-38." - Extended copy under review with IEEE since Feb 1999. It may be useful to note that retransmission timer expiry can have a very profound effect on performance. I have found that some types of interference can lead to multiple loss which results in corruption of the retransmitted segment. In normal implementations of SACK, this results in timer expiry, even if there is information to suggest the link RTT has not changed and no congestion is present (see above paper for details). I can write more, if you like. PAGE 15: Asymmetry On asymmetry of capacity and ACK modification schemes you may also like to consider quoting the alternate viewpoints in: "N Samaraweera, Return Link Optimization for Internet Service Provision using DVB-S Networks. ACM CCR, 1999. 29(3)." or "G Fairhurst, N. Samaraweera, H Harun, K Hodson and R Donadio, Performance Issues in Asymmetric Service Provision using Broadband Satellite, IEE Proc (Comms), 2000." ------------ Best wishes, Gorry Fairhurst From owner-pilc@lerc.nasa.gov Mon Feb 28 11:40:21 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13930 for ; Mon, 28 Feb 2000 11:40:18 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA22384 for pilc-outgoing; Mon, 28 Feb 2000 10:38: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 ESMTP id KAA22365 for ; Mon, 28 Feb 2000 10:38:37 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA14489; Mon, 28 Feb 2000 10:34:05 -0500 (EST) Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma014024; Mon, 28 Feb 00 10:32:41 -0500 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12PS9q-00064r-00; Mon, 28 Feb 2000 15:32:26 +0000 Date: Mon, 28 Feb 2000 15:32:22 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Dr G Fairhurst cc: "'pilc@grc.nasa.gov'" , "Phil Karn (E-mail)" Subject: Re: Draft on Advice for Internet Subnetwork Designers In-Reply-To: <38BA7E3B.A8C5C631@erg.abdn.ac.uk> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Mon, 28 Feb 2000, Dr G Fairhurst wrote: [..] > New Reno sets the cwnd > to one segment on reception of 3 duplicate ACKs (i.e. when entering > the Fast Retransmission Phase) and unacknowledged data are retransmitted > using the Slow Start algorithm. setting cwnd to 1 segment and doing slow start describes timeout, surely? The fast recovery algorithm would involve halving cwnd... See RFC2581 section 3.2, equation 3, and RFC2582, equation 1. Your text is slightly confused by discussing this after discussing additional partial acks, which doesn't help. > It is important to stress the role of SACK for TCP. This has benefits in > terms of improved retransmission, but also in improved congestion > assessment when used in combination with new-reno. How, exactly? For SACK to work you need both SACK receivers and SACK senders. A SACK receiver with a NewReno sender doesn't gain you anything. > For a discussion of SACK under satellite error conditions, see > > "N Samaraweera, and G Fairhurst, Reinforcement of TCP/IP Error Recovery > for Wireless Communications. Computer Communications Review (CCR), > 1998. 28(2): p. 30-38." > - Extended copy under review with IEEE since Feb 1999. http://www.acm.org/sigcomm/ccr/archive/1998/apr98/ccr-9804-samaraweera.html if you're going to cite it, give the URL in addition. > On asymmetry of capacity and ACK modification schemes you may also like to > consider quoting the alternate viewpoints in: > > "N Samaraweera, Return Link Optimization for Internet Service Provision using > DVB-S Networks. ACM CCR, 1999. 29(3)." that would be: http://www.acm.org/sigs/sigcomm/ccr/archive/1999/jul99/ccr-9907-samaraweera4.html L. PGP From owner-pilc@lerc.nasa.gov Mon Feb 28 12:11:54 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14948 for ; Mon, 28 Feb 2000 12:11:53 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA27038 for pilc-outgoing; Mon, 28 Feb 2000 11:03: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 ESMTP id LAA26974 for ; Mon, 28 Feb 2000 11:03:25 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA18820; Mon, 28 Feb 2000 11:03:22 -0500 (EST) Received: from percy.erg.abdn.ac.uk(139.133.204.86) by seraph3.lerc.nasa.gov via smap (V5.0) id xma018682; Mon, 28 Feb 00 11:02:35 -0500 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.10.0.Beta12/8.10.0.Beta12) with ESMTP id e1SG80I18153; Mon, 28 Feb 2000 16:08:01 GMT Message-ID: <38BA8DF0.DABD424D@erg.abdn.ac.uk> Date: Mon, 28 Feb 2000 16:14:42 +0100 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: L.Wood@eim.surrey.ac.uk CC: "'pilc@grc.nasa.gov'" Subject: Re: Draft Advice for Internet Subnet.... TCP ISSUES References: Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for the Lloyd for the URL's... Lloyd Wood wrote: > > > It is important to stress the role of SACK for TCP. This has benefits in > > terms of improved retransmission, but also in improved congestion > > assessment when used in combination with new-reno. > > How, exactly? For SACK to work you need both SACK receivers and SACK > senders. A SACK receiver with a NewReno sender doesn't gain you > anything. > Sure you need a SACK implementation at both sender and receiver. I take that as granted. I think one should look at the two together, SACK operates as a loss repair mechanism, by informing the sender that packets have been received, it pre-empts possible erroneous retransmission. It also gives explicit information about segments leaving a network (i.e. ones which have made it all through the network path and therefore no longer occupy router buffers.) That is, with SACK information received from the remote, the sender is able to accurately know which segments have left, and therefore to inflate cwnd at the transmitter during the recovery phase. In the latter way, it may act in conjunction with the congestion avoidance algorithm. Gorry From owner-pilc@lerc.nasa.gov Mon Feb 28 13:07: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 ESMTP id NAA16624 for ; Mon, 28 Feb 2000 13:07:56 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA06772 for pilc-outgoing; Mon, 28 Feb 2000 12:03: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 ESMTP id MAA06733 for ; Mon, 28 Feb 2000 12:03:27 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA27802; Mon, 28 Feb 2000 12:03:24 -0500 (EST) Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma027772; Mon, 28 Feb 00 12:03:14 -0500 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12PTZd-0007Ix-00; Mon, 28 Feb 2000 17:03:09 +0000 Date: Mon, 28 Feb 2000 17:03:06 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Dr G Fairhurst cc: "'pilc@grc.nasa.gov'" Subject: Re: Draft Advice for Internet Subnet.... TCP ISSUES In-Reply-To: <38BA8DF0.DABD424D@erg.abdn.ac.uk> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Mon, 28 Feb 2000, Dr G Fairhurst wrote: > Lloyd Wood wrote: > > > > It is important to stress the role of SACK for TCP. This has benefits in > > > terms of improved retransmission, but also in improved congestion > > > assessment when used in combination with new-reno. > > > > How, exactly? For SACK to work you need both SACK receivers and SACK > > senders. A SACK receiver with a NewReno sender doesn't gain you > > anything. > > Sure you need a SACK implementation at both sender and receiver. I take > that as granted. > > I think one should look at the two together, "when used in combination with new-reno"? Oh hang on, you mean NewReno *and* SACK? http://src.doc.ic.ac.uk/rfc/rfc2582.txt This document applies only for TCP connections that are unable to use the TCP Selective Acknowledgement (SACK) option. Sorry, you've lost me completely. > SACK operates as a loss repair > mechanism, by informing the sender that packets have been received, it > pre-empts possible erroneous retransmission. Not always. (Thinking of multipath scenarios leading to reordering here.) It also gives explicit information > about segments leaving a network (i.e. ones which have made it all through > the network path and therefore no longer occupy router buffers.) That is, with > SACK information received from the remote, the sender is able > to accurately know which segments have left, and therefore to inflate > cwnd at the transmitter during the recovery phase. In the latter way, it > may act in conjunction with the congestion avoidance algorithm. I thought recovery and congestion avoidance were entirely separate transmission phases? L. PGP From owner-pilc@lerc.nasa.gov Mon Feb 28 13:14:53 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16730 for ; Mon, 28 Feb 2000 13:14:52 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA06671 for pilc-outgoing; Mon, 28 Feb 2000 12:02: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 ESMTP id MAA06632 for ; Mon, 28 Feb 2000 12:02:40 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA27700; Mon, 28 Feb 2000 12:02:39 -0500 (EST) Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma027671; Mon, 28 Feb 00 12:02:14 -0500 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12PTYe-0007I6-00; Mon, 28 Feb 2000 17:02:08 +0000 Date: Mon, 28 Feb 2000 17:02:04 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Dr G Fairhurst cc: "'pilc@grc.nasa.gov'" , "Phil Karn (E-mail)" Subject: Re: Draft on Advice for Internet Subnetwork Designers In-Reply-To: <38BA7E19.CB9D89B1@erg.abdn.ac.uk> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Mon, 28 Feb 2000, Dr G Fairhurst wrote: > "Falk, Aaron" wrote: > > > Folks-- > > > > A very important piece of work for PILC is the LINK draft that Phil Karn is > > editing. > > http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-01.txt > > PAGE 4: MTU Size > > It may be useful to note that using IPSEC in tunnel mode can increase > the size of a packet as it travels across the network. This can result > in a smaller MTU. Doesn't RFC2401 already cover this safely in PMTU advertisement? > The IPv4 packet header contains a header checksum that verifies the integrity > of the header. This checksum was originally design to protect from router > software errors, however this function is no longer necessary. bit strong. Rather, header corruption is assumed sufficiently rare and hosts sufficiently robust at coping with any misdelivery that endhost handling and subsuming into TCP/UDP checksums was considered feasible. > IPv6 does > not therefore implement a network level integrity checksum. The role of the > IP checksum has therefore been subsumed into the TCP and UDP checksums. > > This has two implications for satellite links: > (1) Transport protocols should use a payload checksum when using IPv4 > satellite links and must implement a checksum when used with IPv6, > (previously UDP had an option to use no checksum (value=0) which had for > a time been widely used for NFS in LANs). This (the draft, the implication...) is not at all satellite-link specific. It's general to anything seeking to replace TCP or UDP. (I'm expecting the UDP-Lite crew to break cover round about... now.) > (2) Link layer protocols should provide adequate protection from > transmission errors. It's a tradeoff dependent on the characteristics and use of the link, since the end-to-end checksum catches a number of errors. If the reader thinks 'adequate protection' means 100% reliability means ARQ, you've got problems. How about: Link layer protocols should provide adequate protection from transmission errors. This is necessary since: 1. there is as yet no internetwork framework for detecting or handling link transmission errors effectively 2. it is desirable from a performance viewpoint to avoid triggering congestion control algorithms needlessly as result of errored link-layer frames being discarded. 3. the TCP and UDP checksums are neither strong nor foolproof. > Whereas in previous cases, small CRCs or no CRC > (in the case of SLIP) have been tolerated. A CRC-32 is desirable for > each packet (as in Ethernet). ...or as in ATM AAL5. The best choice of CRC might be dependent on advertised MTU and link characteristics; probably need a note on transparent fragmentation here. I can't think of any references as to why CRC-32 is considered adequate/sufficient offhand, but some would be nice. > I think it may be wise to note that there are two approaches to TCP > friendly link ARQ. One has been put forward by Balakrishnan: > > "H. Balakrishnan, V.N. Padmanabhan, S Seshan, and R H Katz, A > Comparison of Mechanisms for Improving TCP Performance over > Wireless Links. IEEE Trans Net, 1997. 5(6): p. 756-759." > > In this case, TCP headers are read and the information used to tune > the link protocol. this breaks layering. Ugh. And it's a fat lot of use with e.g. IPSec. Not my first or recommended choice. > The other approach is to bound link behaviour to match TCP > "requirements" i.e. A receiver may calculate the variation > of the recovery delay and then give up, if the variation > which will be introduced is more than that can be tolerated > by the TCP transport layer. and this assumes that the link in question is the only link in the path doing such calculations. ugh again. Really, you should imo be saying that if the variation is any more than an order of magnitude less than the limit of transparency to TCP, give up on the resend requests. If it's likely to be regularly more than an order of magnitude less than the transparency limit, be very skeptical of ARQ. (500ms RTO gives 50ms per-link limit, which is probably a bit on the high side, given that the draft talks about 10-20ms delay already. But two orders of magnitude would be 5ms. I have to stop myself thinking in binary magnitudes too...) cheers, L. PGP From owner-pilc@lerc.nasa.gov Mon Feb 28 13:53:08 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17429 for ; Mon, 28 Feb 2000 13:53:06 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA15248 for pilc-outgoing; Mon, 28 Feb 2000 12:59:47 -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 ESMTP id MAA15215 for ; Mon, 28 Feb 2000 12:59:44 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA05382; Mon, 28 Feb 2000 12:59:43 -0500 (EST) Received: from dt039nf6.san.rr.com(24.30.144.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma005285; Mon, 28 Feb 00 12:58:58 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id JAA03140; Mon, 28 Feb 2000 09:58:28 -0800 Date: Mon, 28 Feb 2000 09:58:28 -0800 Message-Id: <200002281758.JAA03140@homer.ka9q.ampr.org> From: Phil Karn To: gorry@erg.abdn.ac.uk CC: pilc@grc.nasa.gov In-reply-to: <38BA7E3B.A8C5C631@erg.abdn.ac.uk> (message from Dr G Fairhurst on Mon, 28 Feb 2000 15:07:30 +0100) Subject: Re: Draft on Advice for Internet Subnetwork Designers Reply-to: karn@ka9q.ampr.org References: <8046A317B5F4D21186610008C7EBB696F055EE@grnexch1.panamsat.com> <38BA7E3B.A8C5C631@erg.abdn.ac.uk> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Gorry, Many thanks for your extensive comments! I'll work them into the next revision of the document. I'll be at the IAB Wireless workshop most of this week, so it may have to wait until this weekend. Phil From owner-pilc@lerc.nasa.gov Tue Feb 29 06:38:02 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15118 for ; Tue, 29 Feb 2000 06:38:02 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA04822 for pilc-outgoing; Tue, 29 Feb 2000 05:04:47 -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 ESMTP id EAA04114; Tue, 29 Feb 2000 04:47:17 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id EAA07799; Tue, 29 Feb 2000 04:47:16 -0500 (EST) Received: from leonis.nus.edu.sg(137.132.1.18) by seraph3.lerc.nasa.gov via smap (V5.0) id xma007791; Tue, 29 Feb 00 04:47:10 -0500 Received: from engtanlk.nus.edu.sg ([137.132.204.165]) by leonis.nus.edu.sg (8.9.3/8.9.3) with SMTP id PAA28647; Tue, 29 Feb 2000 15:06:20 +0800 (SST) Message-ID: <028401bf8284$44618940$a5cc8489@engtanlk.nus.edu.sg> From: "ICON'2000 Secretariat" To: Subject: 14 days to countdown! Have you submitted your papers??? Date: Tue, 29 Feb 2000 15:06:17 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0281_01BF82C7.5284C940" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0281_01BF82C7.5284C940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All =20 * Kindly ignore this email if you have received this before.=20 Thanks you for your kind attention. =20 The 8th IEEE International Conference On Networks will be held from=20 September 5- 8, 2000 in Singapore. The aim of the conference is to = provide=20 an international forum for experts to promote, share and discuss various = issues and developments in the broad field of computer and communication = networks. We thus seek and solicit your contributions in the form of original/unpublished papers, tutorials, and topics for=20 special sessions/panel discussions. More information on the scope of the = conference and the guidelines for the submission of contributions can be obtained at this web site :http://www.comp.nus.edu.sg/~icon/ We look forward to your participation. Thank you. Icon 2000 organizing Committee ------=_NextPart_000_0281_01BF82C7.5284C940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear All
 
*=20 Kindly ignore this email if you have received this before.=20
Thanks you for your kind = attention.
 

The 8th IEEE International Conference On Networks will be held from =

September 5- 8, 2000 in Singapore. The aim of the conference is to = provide=20

an international forum for experts to promote, share and discuss = various

issues and developments in the broad field of computer and = communication

networks. We thus seek and solicit your contributions

in the form of original/unpublished papers, tutorials, and topics for =

special sessions/panel discussions. More information on the scope of = the

conference and the guidelines for the submission of contributions = can

be obtained at this web site :http://www.comp.nus.edu.sg/~icon/

 

We look forward to your participation. Thank you.

Icon 2000 organizing Committee

 

= ------=_NextPart_000_0281_01BF82C7.5284C940-- From owner-pilc@lerc.nasa.gov Tue Feb 29 07:07:03 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15399 for ; Tue, 29 Feb 2000 07:07:02 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA05893 for pilc-outgoing; Tue, 29 Feb 2000 05:30: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 ESMTP id FAA05889 for ; Tue, 29 Feb 2000 05:30:47 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id FAA10856; Tue, 29 Feb 2000 05:30:46 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.0) id xma010852; Tue, 29 Feb 00 05:30:21 -0500 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.194.130]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id LAA01607; Tue, 29 Feb 2000 11:30:17 +0100 (MET) Received: from eifel.eed.ericsson.se (eifel [164.48.194.242]) by chapelle.eed.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA12810; Tue, 29 Feb 2000 11:30:14 +0100 (MET) Message-Id: <4.2.0.58.20000229110944.00ab21d0@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 29 Feb 2000 11:30:01 +0100 To: gorry@erg.abdn.ac.uk From: Reiner Ludwig Subject: Re: Draft on Advice for Internet Subnetwork Designers Cc: "'pilc@grc.nasa.gov'" , "Phil Karn (E-mail)" In-Reply-To: <38BA7E19.CB9D89B1@erg.abdn.ac.uk> References: <8046A317B5F4D21186610008C7EBB696F055EE@grnexch1.panamsat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk to throw in some papers from our side ... ;-) At 15:06 2/28/00 , Dr G Fairhurst wrote: >PAGE 13: Link ARQ > >I think it may be wise to note that there are two approaches to TCP >friendly link ARQ. One has been put forward by Balakrishnan: > >"H. Balakrishnan, V.N. Padmanabhan, S Seshan, and R H Katz, A >Comparison of Mechanisms for Improving TCP Performance over >Wireless Links. IEEE Trans Net, 1997. 5(6): p. 756-759." > >In this case, TCP headers are read and the information used to tune >the link protocol. > >The other approach is to bound link behaviour to match TCP >"requirements" i.e. A receiver may calculate the variation >of the recovery delay and then give up, if the variation >which will be introduced is more than that can be tolerated >by the TCP transport layer. This latter >approach was summarised in one of our papers: > >"N Samaraweera and G Fairhurst Robust Data Link Protocols for >Connection-less Service over Satellite Links. Int J. Sat Coms, >1996. 14(5): p. 427-437." I third approach is to have the link layer 1. distinguish between flow types by using the protocol-id field in the IP header or the ds-field (if appropriate codepoints were defined which is not the case today). See http://iceberg.cs.berkeley.edu/papers/Ludwig-Infocom99/index.html 2. Do little or no link layer ARQ for real-time flows 3. Do highly persistent link layer ARQ (delaying packets up to 2 minutes (MSL) !) for reliable flows such as TCP-based flows. See http://iceberg.cs.berkeley.edu/papers/Ludwig-WINET99/ The latter paper shows that this approach: A. Leads to optimal e2e performance B. Renders obsolete any effort to make TCP/IP compression more robust Also note that: i. this approach rarely causes spurious timeouts See http://iceberg.cs.berkeley.edu/papers/Ludwig-Sigmetrics99/index.html which is due to TCP's overly conservative retransmission timer See http://iceberg.cs.berkeley.edu/papers/Ludwig-Eifel-Xmit/index.html ii. TCP can easily be made robust against spurious timeouts and packet re-orderings should they occur See http://iceberg.cs.berkeley.edu/papers/Ludwig-Eifel-Alg/index.html ///Reiner From owner-pilc@lerc.nasa.gov Tue Feb 29 14:17:51 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29894 for ; Tue, 29 Feb 2000 14:17:50 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA04750 for pilc-outgoing; Tue, 29 Feb 2000 13:20:43 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA04704 for ; Tue, 29 Feb 2000 13:20:40 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA06048; Tue, 29 Feb 2000 13:20:40 -0500 (EST) Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma005881; Tue, 29 Feb 00 13:19:54 -0500 Received: (from touch@localhost) by boreas.isi.edu (8.8.7/8.8.6) id KAA04170; Tue, 29 Feb 2000 10:19:49 -0800 (PST) Date: Tue, 29 Feb 2000 10:19:49 -0800 (PST) From: Joe Touch Message-Id: <200002291819.KAA04170@boreas.isi.edu> To: gorry@erg.abdn.ac.uk Subject: Re: Draft on Advice for Internet Subnetwork Designers Cc: karn@qualcomm.com, pilc@grc.nasa.gov, touch@ISI.EDU Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From owner-pilc@lerc.nasa.gov Mon Feb 28 08:05:06 2000 > Date: Mon, 28 Feb 2000 15:06:57 +0100 > From: Dr G Fairhurst > CC: "'pilc@grc.nasa.gov'" , > "Phil Karn (E-mail)" > Subject: Re: Draft on Advice for Internet Subnetwork Designers > > Here are some comments on Link Level Issues: > > "Falk, Aaron" wrote: > > > Folks-- > > > > A very important piece of work for PILC is the LINK draft that Phil Karn is > > editing. > > http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-01.txt > > PAGE 4: MTU Size > > It may be useful to note that using IPSEC in tunnel mode can increase > the size of a packet as it travels across the network. This can result > in a smaller MTU. Doesn't IPSEC in any mode do this? (tunnel or transport?) (provided it's added after the source - and, in the case of overlay networks, [paradoxically] transport may be more useful) > The IPv4 packet header contains a header checksum that verifies the integrity > of the header. This checksum was originally design to protect from router > software errors, however this function is no longer necessary. Not so much necessary, as not worth the cost. > IPv6 does > not therefore implement a network level integrity checksum. The role of the > IP checksum has therefore been subsumed into the TCP and UDP > checksums. More into IPSEC than into TCP and UDP, no? Joe