From tcplw-relay@services.BSDI.COM Thu Oct 30 15:52:52 1997 Delivery-Date: Thu, 30 Oct 1997 15:52:58 -0500 Return-Path: tcplw-relay@services.BSDI.COM Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id PAA17991 for ; Thu, 30 Oct 1997 15:52:52 -0500 (EST) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA15456 for ; Thu, 30 Oct 1997 15:55:54 -0500 (EST) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.7) id NAA04746 for tcplw-list@bsdi.com; Thu, 30 Oct 1997 13:47:23 -0700 (MST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by services.BSDI.COM (8.8.7/8.8.7) with ESMTP id NAA04741 for ; Thu, 30 Oct 1997 13:47:20 -0700 (MST) Received: from rsm.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.8.8/8.8.8) with SMTP id VAA09321 for ; Thu, 30 Oct 1997 21:46:45 +0100 Received: from albemuth by rsm.enst-bretagne.fr (4.1/SMI-4.1) id AA20389; Thu, 30 Oct 97 21:46:44 +0100 Sender: Hossam.Afifi@enst-bretagne.fr Message-Id: <3458F230.7637@rennes.enst-bretagne.fr> Date: Thu, 30 Oct 1997 21:46:40 +0100 From: Hossam Afifi X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4m) Mime-Version: 1.0 To: tcplw@bsdi.com Subject: TCP-SACK versus Source Quench messages Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit TCP Sack as a way for Negative acknowledgements I have made some simulations with ns (TCP-SACK) by using the SACK options to report for explicit losses in routers instead of IP source quench messages. The result improves the TCP goodput. There are however some questions that have to be answered like: -- whether it is permitted to report empty blocks in the sack options: ie the left and right edges are equal. (a way to announce an explicit segment loss in the router)? -- Can a router modify the IP checksum? Hossam Afifi -- *Address ENST de Bretagne RSM * * BP 78-35512 Cesson Sevigne CEDEX * *Email afifi@rennes.enst-bretagne.fr * -------------------------------------------------------- From tcplw-relay@services.BSDI.COM Wed Nov 12 09:45:33 1997 Delivery-Date: Wed, 12 Nov 1997 09:45:52 -0500 Return-Path: tcplw-relay@services.BSDI.COM Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA18960 for ; Wed, 12 Nov 1997 09:44:58 -0500 (EST) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA10129 for ; Wed, 12 Nov 1997 09:47:57 -0500 (EST) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.7) id HAA04485 for tcplw-list@bsdi.com; Wed, 12 Nov 1997 07:39:52 -0700 (MST) Received: from janus.unik.no (janus.unik.no [193.156.96.46]) by services.BSDI.COM (8.8.7/8.8.7) with ESMTP id HAA04477 for ; Wed, 12 Nov 1997 07:39:46 -0700 (MST) Received: from unik.no (ask.unik.no [193.156.96.167]) by janus.unik.no (8.8.5/8.7.3) with ESMTP id PAA15555; Wed, 12 Nov 1997 15:26:11 +0100 (MET) Sender: plageman@unik.no Message-ID: <3469BBFA.E95F587B@unik.no> Date: Wed, 12 Nov 1997 15:23:54 +0100 From: Thomas Plagemann Organization: University of Oslo X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: alg@comm.toronto.edu, apc@ee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, cellular@comnets.rwth-aachen.de, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, end2end-interest@isi.edu, enternet@bbn.com, f-troup@codex.cis.upenn.edu, fokus-user@fokus.gmd.de, g-troup@ccrc.wustl.edu, giga@tele.pitt.edu, hipparch@sophia.inria.fr, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, isadsoc@fokus.gmd.de, itc@fokus.gmd.de, modern-heuristics@uk.ac.mailbase, multicomm@cc.bellcore.com, osimcast@bbn.com, rem-conf@es.net, reres@laas.fr, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sigmedia@bellcore.com, tccc@ieee.org, xtp-relay@cs.concordia.ca, cost237-teleservices@comp.lancs.ac.uk, tcplw@bsdi.com CC: idms98@unik.no Subject: CfP IDMS'98 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by services.BSDI.COM id HAA04483 Dear Collegues, please find below the Call for papers for IDMS'98: 5th International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services 8. - 11. September 1998, Oslo, Norway Online information for IDMS'98 (including the CfP) can be found at: http://www.unik.no/~idms98 You will be doing us a great favor if you disseminate the this Call for papers among your interested colleagues. Please accept our apologies if you receive multiple copies of this announcement. Best regards, Vera Goebel Thomas Plagemann __________________________________________________________________________ | | Organization Committee IDMS'98 | | 5th International Workshop on Interactive Distributed Multimedia | Systems and Telecommunication Services | Oslo, Norway, 1998 | | UniK - Center for Technology at Kjeller | University of Oslo | P.O. Box 70, N-2007 Kjeller, Norway | | e-mail: idms98@unik.no | WWW: http://www.unik.no/~idms98 |__________________________________________________________________________ Call for Papers IDMS'98 5th International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services 8. - 11. September 1998, Oslo, Norway The Fifth International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services follows the successful IDMS workshops held 1997 in Darmstadt and 1996 in Berlin. The purpose of this workshop is to bring together researchers, developers, and practitioners from academia and industry. The workshop serves as a forum for discussion, presentation, and exploration of technologies and their advances in the broad field of interactive distributed multimedia systems and telecommunication services -- ranging from basic system technologies such as networking and operating system support to all kinds of teleservices and distributed multimedia applications. Case studies and papers describing experimental work are especially welcome. Relevant topics include, but are not limited to · High-speed/ATM networks · Mobile multimedia systems · Multimedia over sattelite · Multimedia middelware · Quality of service issues · Media scaling · Resource management · Protocol design and implementation · Distributed multimedia database systems · Development tools for distributed multimedia applications · Multimedia-specific intelligent agents · Computer supported collaborative work · Distributed virtual reality systems · Distance education · Conferencing · Digital libraries · Interactive television · Video-on-demand systems · Compression algorithms IDMS'98 will consist of a three day technical program, a full day of tutorials, and demonstrations during the workshop. In order to keep the flavour of a workshop, the number of participants will be restricted. Furthermore, we encurage contributions in form of full papers and position papers. Full papers are expected to describe innovative and significant work. The purpose of position papers is to provide a seed for debate and discussion. Position papers enable researchers to present exciting ongoing work in early stages, suggestions for future directions, and concerns about current developments. Both types of papers will be reviewed by the program committee and printed in the workshop proceedings. The proceedings will be published in the Springer LNCS series and will be available during the workshop. It is intended to forward selected papers to a special issue of the "Computer Communications" Journal. Information for authors: Authors are invited to submit full papers and position papers for review. Submitted manuscripts must describe original work (not submitted or published elsewhere). Full papers must not be longer than 20 double spaced pages and position papers must not be longer than 8 double spaced pages. Both types of papers should contain an abstract of approximately 300 words, and include title, authors and affiliations. The submission process of papers will be handled electronically. Detailed description of the electronic submission procedures is available on the IDMS'98 web page: http://www.unik.no/~idms98. Authors without web access may send mail to idms98@unik.no requesting electronic submission information. Authors unable to submit electronically are invited to send 5 copies of their contribution to one of the workshops chairs ATTN: IDMS'98. Important dates: Submission due: February 1, 1998 Notification of acceptance: April 15, 1998 Camera ready version: May 15, 1998 Workshop: September 9 - 11, 1998 Program co-chairs: Vera Goebel and Thomas Plagemann UniK - Center for Technology at Kjeller, University of Oslo, P.O. Box 70, N-2007 Kjeller, Norway Email: {goebel; plageman}@unik.no, Phone: +47/63.81.45.70, Fax: +47/63.81.81.46 Program Committee: F. A. Aagesen, NTNU Trondheim, Norway H. Affifi, ENST Bretagne, France E. Biersack, Institut Eurécom, France G. Bochmann, University of Montreal, Canada B. Butscher, DeTeBerkom, Germany A. T. Campbell, Columbia University, USA S. Chanson, Hong Kong University of Science & Technology, HK L. Delgrossi, University Cattolica Piacenza, Italy M. Diaz, LAAS-CNRS, France F. Eliassen, University of Tromsø, Norway W. Effelsberg, University Mannheim, Germany D. Ferrari, University Cattolica Piacenza, Italy J.-P. Hubaux, EPFL Lausanne, Switzerland D. Hutchison, Lancaster University, UK W. Kalfa, TU Chemnitz, Germany T. D. C. Little, Boston University, USA E. Moeller, GMD FOKUS, Germany K. Nahrstedt, University of Illinois, USA G. Parulkar, Washington University St. louis, USA B. Pehrson, KTH Stockholm, Sweden S. Pink, SICS, Sweden B. Plattner, ETH Zurich, Switzerland H. Scholten, University of Twente, Netherlands R. Steinmetz, GMD, Germany H. Tokuda, Keio University, Japan L. Wolf, TH Darmstadt, Germany M. Zitterbart, TU Braunschweig, Germany From tcplw-relay@services.BSDI.COM Mon Nov 17 00:25:37 1997 Delivery-Date: Mon, 17 Nov 1997 00:25:38 -0500 Return-Path: tcplw-relay@services.BSDI.COM Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id AAA10554 for ; Mon, 17 Nov 1997 00:25:36 -0500 (EST) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA01701 for ; Mon, 17 Nov 1997 00:28:32 -0500 (EST) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.7) id WAA28675 for tcplw-list@bsdi.com; Sun, 16 Nov 1997 22:17:59 -0700 (MST) Received: from owl.ee.lbl.gov (owl.ee.lbl.gov [131.243.1.50]) by services.BSDI.COM (8.8.7/8.8.7) with ESMTP id WAA28672 for ; Sun, 16 Nov 1997 22:17:57 -0700 (MST) Received: by owl.ee.lbl.gov (8.8.8/8.8.5) id VAA03794; Sun, 16 Nov 1997 21:17:55 -0800 (PST) Message-Id: <199711170517.VAA03794@owl.ee.lbl.gov> To: tcplw@bsdi.com cc: kkrama@research.att.com Subject: Internet Draft on Explicit Congestion Notification (ECN) Date: Sun, 16 Nov 1997 21:17:55 PST From: Sally Floyd K. K. Ramakrishnan and I have submitted an Internet draft on "A Proposal to add Explicit Congestion Notification (ECN) to IPv6 and to TCP" today. A copy of the draft is attached. We would welcome comments. While the proposal involves the domain of several working groups (ipng, tcplw), and we are therefore sending this announcement to the mailing lists of several working groups, we are assuming that general discussion will happen on the end2end-interest mailing list. (Subscription information for end2end-interest: "http://www.irtf.org/irtf/charters/end2end.htm".) Thanks very much, Sally Floyd and K. K. Ramakrishnan. ----------------------------------------------------------------------- Internet Engineering Task Force K. K. Ramakrishnan INTERNET DRAFT AT&T Labs Research draft-kksjf-ecn-00.txt Sally Floyd LBNL November 1997 Expires: May 1998 A Proposal to add Explicit Congestion Notification (ECN) to IPv6 and to TCP Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This note describes a proposed addition of ECN (Explicit Congestion Notification) to IPv6 and to TCP. First we describe TCP's use of packet drops as an indication of congestion. Next we argue that with the addition of active queue management (e.g., RED) to the Internet infrastructure, where routers detect congestion before the queue overflows, routers are no longer limited to packet drops as an indication of congestion, but could instead set an ECN bit in the packet header, for ECN-capable transport protocols. We describe when the ECN bit would be set in the routers, and describe what modifications would be needed to TCP to make it ECN-capable. Modifications to other transport protocols (e.g., unreliable unicast or multicast, reliable multicast, other reliable unicast transport protocols) could be considered as those protocols advance through the standards process. Ramakrishnan and Floyd Informational [Page 1] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 TCP's congestion control and avoidance algorithms are based on the notion that the network is a black-box [Jacobson88, Jacobson90]. The network's state of congestion or otherwise is determined by end- systems probing for the network state, by gradually increasing the load on the network (by increasing the window of packets that are outstanding in the network) until the network becomes congested and a packet is lost. Treating the network as a "black-box" and treating loss as an indication of congestion in the network is appropriate for pure best-effort data carried by TCP that has little or no sensitivity to delay or loss of individual packets. In addition, TCP's congestion management algorithms have techniques built-in (such as fast retransmit and fast recovery) to minimize the impact of losses from a throughput perspective. However, these mechanisms are not intended to help applications that are in fact sensitive to the delay or loss of one or more individual packets. Interactive traffic such as telnet, web-browsing, and transfer of audio and video data ("real-audio" and "real-video") can be sensitive to packet losses (for unreliable data delivery such as UDP) or to the increased latency of the packet caused by the need to retransmit the packet after a loss (for reliable data delivery such as TCP). Since TCP determines the appropriate congestion window to use by gradually increasing the window size until it experiences a dropped packet, this causes the queues at the bottleneck router to build up. With most packet drop policies at the router that are not sensitive to the load placed by each individual flow, this means that some of the packets of latency-sensitive flows are going to be dropped. Active queue management mechanisms that detect congestion before the queue overflows, and provide an indication of this congestion to TCP, is desirable because it avoids some bad properties of dropping on queue overflow, especially with drop-tail schemes. Drop tail introduces synchronization of loss across multiple flows which is undesirable. Indicating incipient congestion means that TCP does not have to increase its window size up to the point where a router's buffer is filled up. This can reduce queuing delays and avoid synchronization, which are desirable characteristics. 2. Random Early Detection (RED) Random Early Detection (RED) is a mechanism for active queue management that has been proposed to detect incipient congestion [FJ93], and is currently being deployed in the Internet backbone [RED-ietf-draft]. Although RED is meant to be a general mechanism using one of several alternatives for congestion indication, in the current environment of the Internet RED is restricted to using packet drops as a mechanism for congestion indication. By dropping packets Ramakrishnan and Floyd Informational [Page 2] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 based on the average queue length exceeding a threshold, rather than only when the queue overflows, RED maintains the average queue at a smaller level, and improves the delay experienced by the flows. However, when RED drops packets before the queue actually overflows, RED is not forced by memory limitations to discard the packet. RED could set an Explicit Congestion Notification bit in the packet header instead of dropping the packet, if such a bit was provided in the IP header and understood by the transport protocol. The use of the Explicit Congestion Notification bit would allow the receiver(s) to receive the packet, avoiding the potential for excessive delays due to retransmissions after packet losses. 3. Explicit Congestion Notification We propose that the Internet provide a congestion indication for incipient congestion (as in RED and earlier work [RJ90]) where the notification can sometimes be through marking packets rather than dropping them. This would require an ECN field in the IP header with two bits. The ECN-Capable bit would be set by the data sender to indicate an ECN-capable transport protocol. The ECN bit would be set by the router to indicate congestion to the end nodes. ([Floyd94] outlines a scheme where a single bit could be overloaded to serve the function of both the ECN-Capable bit and the ECN bit, but the two-bit scheme is more straightforward to explain). We expect that routers would provide the congestion indication on incipient congestion as indicated by the average queue size, using the RED algorithms suggested in [FJ93, RED-ietf-draft]. Routers that have a packet arriving at a full queue would drop the packet, just as they do now. The congestion control algorithms followed at the end-systems would be essentially the same as the congestion control response to a *single* dropped packet, for a transport protocol where a dropped packet is used as an indication of congestion. For TCP in particular, the source TCP would halve its congestion window "cwnd" in response to an ECN indication received by the data receiver. However, this action is done only once per window of data (i.e., at most once per roundtrip time), to avoid reacting multiple times to multiple indications of congestion within a roundtrip time. 4. Proposed Algorithm at the Router We describe the proposed algorithm at the router in the context of current router implementations. We assume that the router is capable of implementing the probability computation for RED and uses a pure packet drop mechanism (e.g., drop from front, drop from tail, or random drop) whenever a packet arrives at a full queue. When the router's buffer is not yet full and the router is prepared Ramakrishnan and Floyd Informational [Page 3] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 to drop a packet to inform end nodes of incipient congestion, the router should first check to see if the ECN-Capable bit is set in that packet's IP header. If so, then instead of dropping the packet, the router could instead set the ECN bit in the IP header. When more severe congestion has occurred and the router's queue is full, then the router has no choice but to drop some packet when a new packet arrives. The router determines it is congested if the AVERAGE length of any of its queues where packets are waiting to be processed or transmitted exceeds a threshold. We believe that the router should use the ECN bit to notify that it is congested only when the *average* queue length, rather than the instantaneous queue length, exceeds a threshold. There are potentially several alternatives for estimating the average queue length and marking the ECN bit. Since there is considerable effort involved already in implementing RED, we believe it is best to leverage these efforts for ECN as well. One potential mechanism for the averaging and marking is to perform functions similar to RED queue management: RED uses an exponential moving average of the queue size. When the average queue size goes above a lower threshold, packets are marked with a probability of marking that increases with the average queue size. (Packets that are not ECN-capable are dropped instead of marked.) When the average queue size gets up to or above a high threshold, all incoming packets should be dropped (assuming that the router intends to control the average queue size even in the presence of unresponsive traffic). It is anticipated that when all of the source end-systems participate in TCP's congestion management mechanisms or other compatible congestion control, and respond to ECN by reducing their offered load, packet losses would be relatively infrequent. Packet losses in this case would occur primarily during transients and in the presence of non-cooperating entities. When a packet is received by a router with the ECN bit set indicating that congestion was encountered upstream, then the bit is left unchanged, and the packet transmitted as usual. 5. Support from the Transport Protocol ECN requires support from the transport protocol, in addition to the ECN field in the IPv6 packet header. For TCP, ECN requires two new mechanisms: negotiation between the endpoints during setup to determine if they are both ECN-capable, and an ECN-Notify bit in the TCP header so that the data receiver can inform the data sender when a packet has been received with the ECN bit set. The support Ramakrishnan and Floyd Informational [Page 4] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 required from other transport protocols is likely to be different, particular for unreliable or reliable multicast transport protocols, and will have to be determined as other transport protocols are brought to the IETF for standardization. The following sections describe in detail the proposed TCP use of ECN. This is also described in [Floyd94]. We assume that the source TCP uses the current set of congestion control algorithms of Slow-start, Fast Retransmit and Fast Recovery [RFC 2001]. 5.1. TCP Initialization Initially, the source and destination TCPs exchange the desire and/or capability to use ECN in the TCP connection setup phase. As a result of the negotiation, the TCP sender indicates using the ECN-Capable bit in the IPv6 header that the transport is capable and willing to participate in ECN. This will indicate to the routers that they may mark packets with the ECN bit, if they would like to use that as a method of congestion notification. If the TCP connection does not wish to use ECN notification, the sending TCP sets the ECN-Capable bit equal to 0 (i.e., not set), and the TCP receiver ignores the ECN bit in received packets. 5.2. The TCP Sender For a connection that expects to use ECN, packets are transmitted with the ECN-Capable bit set in the IP header (set to a "1"). If the sender receives a TCP acknowledgement with the ECN-Notify bit set in the TCP header, then the sender knows that congestion was encountered in the network on the path from the sender to the receiver. The indication of congestion should be treated just as a congestion loss in non-ECN-Capable TCP. That is, the TCP source halves the congestion window "cwnd" and reduces the slow start threshold "ssthresh". The sending TCP does NOT increase the congestion window in response to the receipt of an ACK packet with the ECN-Notify bit set. However, a very important difference is that TCP does not react to ECN congestion indications more than once every window of data (or more loosely, more than once every round-trip time). If a response to the ECN-Notify bit was made over the last round-trip time, based on the window of packets, then the sending TCP doesn't respond to any further ECN messages. If at time "t", the source TCP reacted to an ECN, then it notes the packets that are outstanding at that time and have not yet been acknowledged. Until all these packets are acknowledged, say at time "u", the source TCP does not react to another ECN indication of congestion. In addition, when a TCP sender receives duplicate acks during the time interval between "t" and "u", it does not reduce the congestion window. The result is that decreases in the congestion window occur Ramakrishnan and Floyd Informational [Page 5] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 at most once per roundtrip time. When the TCP sender receives a packet with the ECN-Notify bit set, and therefore reduces its congestion window, the sender does not need to slow-start (as is done in Tahoe TCP in response to a packet drop) or to stop sending packets for a period of time to allow the queue to dissipate (as is done by Reno TCP for roughly half a round-trip time in response to a packet drop). The ECN-Notify bit being set does not indicate the urgent transient congestion state of a buffer overflow. Incoming acknowledgements will still arrive to "clock out" outgoing packets when allowed by the congestion window. TCP follows existing algorithms for sending data packets in response to incoming ACKs, multiple duplicate acknowledgements, or retransmit timeouts [RFC2001]. 5.3. The TCP Receiver At the destination end-system, when TCP receives a packet with the ECN bit set in the IP header, TCP sets the ECN-Notify bit in the TCP header in the returning ACK packet. We do not provide here any notion of destination congestion, because this is already being indicated in the receiver's advertised window. The destination TCP continues to perform the duplicate ACK procedure already specified - to generate a duplicate ACK when an out-of- sequence packet is received. If there is any ACK withholding implemented, as in current TCP implementations where the TCP receiver often sends an ACK for two arriving data packets, then the TCP destination will send the OR of all the ECN bits of packets that the ACK is acknowledging. That is, if any packet is received with the ECN bit set, then the ACK carries the ECN-Notify bit set. 5.4. Congestion on the ACK-path For the current generation of TCP congestion control algorithms, pure acknowledgement packets (e.g., packets that do not contain any accompanying data) should be sent with the ECN-capable bit off. Current TCP receivers have no mechanisms for reducing traffic on the ACK-path in response to congestion notification. Mechanisms for responding to congestion on the ACK-path can be relegated as an area for future research. (One simple possibility would be for the sender to reduce its congestion window when it receives a pure ACK packet with the ECN bit set). For current TCP implementations, a single dropped ACK generally has only a very small effect on the TCP's sending rate. Ramakrishnan and Floyd Informational [Page 6] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 6. Summary of changes required in IPv6 and TCP Two bits need to be specified in the IPv6 header, the ECN-Capable bit and the ECN bit. The ECN-Capable bit set to "0" indicates that the transport protocol will ignore the ECN bit. This is the default value. The ECN-Capable bit set to "1" indicates that the transport protocol is willing and able to participate in ECN. The default value for the ECN bit is "0". The router sets the ECN bit to "1" to indicate congestion to the end nodes. The ECN bit in a packet header should never be reset by a router from "1" to "0". TCP requires two changes, a negotiation phase during setup to determine if both end nodes are ECN-capable, and a bit in the TCP header (possibly one of the "reserved" bits in the TCP flags field) as an ECN-Notify bit so that the receiver can inform the sender of a packet received with the ECN bit set. 7. Non-relationship to ATM's EFCI indicator or Frame Relay's FECN Since these ATM and Frame Relay mechanisms typically have been defined without any notion of average queue size as the basis for concluding that there is congestion, we believe that they provide a very noisy signal. The interpretation we have here for ECN is NOT the appropriate reaction for such a noisy signal of congestion notification. It is our belief that such mechanisms would be phased out over time within the ATM network. However, if the routers that interface to the ATM network have a way of maintaining the average queue at the interface, and use it to come to a conclusion that the ATM subnet is congested or otherwise, they may use the ECN notification that is defined here. 8. Non-compliance by the End Nodes We believe that, for the most part, the fairness properties of TCP will not be changed with the introduction of ECN. A key issue concerns the vulnerability of ECN to non-compliant end- nodes (i.e., end nodes that set the ECN-capable bit in packets, but do not respond to the ECN bit itself). These concerns exist even in non-ECN environments. An end-node could "turn off congestion control" by not reducing its congestion window in response to packet drops. We recognize that this is a concern for the current Internet. It has been argued that routers will have to deploy mechanisms to detect and differentially treat packets from non-compliant flows. It is likely that techniques such as end-to-end per-flow scheduling and isolation of one flow from another, potentially accompanied by end- to-end reservations, could mitigate such effects. Such isolation Ramakrishnan and Floyd Informational [Page 7] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 mechanisms could remove some of the more egregious effects of non- compliance. However, even in networks just restricted to packet losses as an indication of congestion, several methods have been proposed to identify and treat non-compliant or unresponsive flows. These mechanisms would be equally applicable for identifying flows that do not respond to ECN. If anything, routers would have a slightly easier time identifying flows that do not respond to ECN. For example, routers can observe packets arriving at the router with the ECN bit set, as well as keeping note of packets that have the ECN bit set at that router itself. It has been argued that dropping packets in itself may be considered a deterrrent for non-compliance. However, we believe that the packet drop rates are likely to be reasonably low in environments where ECN is deployed. The reduction in load due to packet drops to deal with non-compliant nodes is likely to be small. The control of congestion is more likely to come from end-nodes reacting to congestion - either from responding to dropped packets or ECN Notify indications and halving the window. ECN should be used at a router when the average queue size is below some high threshold; when the average queue size exceeds the high threshold, and therefore packet drop/marking rates are higher, our recommendation is that routers drop packets, rather then setting the ECN bit in packet headers. Thus, in scenarios with low packet drop rates, the fact that the congestion control indications are in the form of packet drops rather than ECN bits does not significantly change the negative consequences on the compliant flows because of some flow "turning off" congestion control. We also do not believe that packet dropping itself is an effective deterrent for non-compliance. Many flows that retransmit dropped packets could have an incentive to maintain or even increase their sending rate in response to packet drops, rather than decreasing their sending rate, in the absence of mechanisms at the router to provide a negative deterrance for such behavior. For example, flows that use unreliable transport protocols could simply increase their use of FEC in response to an increased packet drop rate, and might choose increased FEC and no congestion control. We believe that the effect of packet dropping as a deterrence for non-compliance with congestion control mechanisms is quite small. The possibility of non-compliant flows does not offer a compelling reason not to deploy ECN. 9. Additional Considerations Some care is required to handle the ECN and ECN-Capable bits appropriately when packets are encapsulated and un-encapsulated for Ramakrishnan and Floyd Informational [Page 8] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 tunnels. When the router at the end of the tunnel decapsulates the packet, then the ECN bit in the encapsulating ('outside') header should be ORed with the ECN bit in the encapsulated ('inside') header that remains. Basically, a 1 in the encapsulating header should be copied into the encapsulated header. An additional issue concerns packets that have the ECN bit set at one router, and are later dropped at another router. For the proposed use for ECN in this paper (that is, for data packets for TCP), this is not a concern, because end nodes detect dropped data packets, and the congestion response of the end nodes to a dropped data packet is at least as strong as the congestion response to a packet received with the ECN bit set. This issue will have to be addressed if ECN and ECN-Capable bits are used on pure ACK packets, because in current implementations of TCP the drop of an ACK packet is not explicitly detected by the end nodes. If a packet with the ECN bit is later dropped due to corruption (bit errors), the end node should still invoke congestion control, just as TCP would today, to a dropped data packet. This issue would also have to be addressed in future proposals for distinguishing between packets dropped due to corruption and packets dropped due to congestion. 10. Conclusions Given the current effort to implement RED, we believe this is the right time for router vendors to examine how to also implement congestion avoidance mechanisms that do not depend on packet drops alone. With the growth of applications and transports that are sensitive to delay and loss of a single packet, depending on packet loss as a normal congestion notification mechanism appears to be insufficient (or at the very least, non-optimal). Ramakrishnan and Floyd Informational [Page 9] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 REFERENCES [FJ93] Floyd, S., and Jacobson, V., "Random Early Detection gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, p. 397-413. URL "ftp://ftp.ee.lbl.gov/papers/early.pdf". [Floyd94] Floyd, S., "TCP and Explicit Congestion Notification", ACM Computer Communication Review, V. 24 N. 5, October 1994, p. 10-23. URL "ftp://ftp.ee.lbl.gov/papers/tcp_ecn.4.ps.Z". [Floyd97] Floyd, S., and Fall, K., "Router Mechanisms to Support End-to-End Congestion Control", Technical report, February 1997. URL "ftp://ftp.ee.lbl.gov/papers/collapse.ps". [FRED] Lin, D., and Morris, R., "Dynamics of Random Early Detection", SIGCOMM '97, September 1997. URL "http://www.inria.fr/rodeo/sigcomm97/program.html#ab078". [Jacobson88] V. Jacobson, "Congestion Avoidance and Control", Proc. ACM SIGCOMM '88, pp. 314-329. URL "ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z". [Jacobson90] V. Jacobson, "Modified TCP Congestion Avoidance Algorithm", Message to end2end-interest mailing list, April 1990. URL "ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt". [RED-ietf-draft] B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", Internet draft draft-irtf-e2e-queue-mgt-00.txt, March 25, 1997. [RFC2001] W. Stevens, "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997. [RJ90] K. K. Ramakrishnan and Raj Jain, "A Binary Feedback Scheme for Congestion Avoidance in Computer Networks", ACM Transactions on Computer Systems, Vol.8, No.2, pp. 158-181, May 1990. SECURITY CONSIDERATIONS Security issues are not discussed in this document. Ramakrishnan and Floyd Informational [Page 10] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 AUTHORS' ADDRESSES K. K. Ramakrishnan AT&T Labs. Research Phone: +1 (973) 360-8766 Email: kkrama@research.att.com URL: http://www.research.att.com/info/kkrama Sally Floyd Lawrence Berkeley National Laboratory Phone: +1 (510) 486-7518 Email: floyd@ee.lbl.gov URL: http://www-nrg.ee.lbl.gov/floyd/ This draft was created in November 1997. It expires May 1998. Ramakrishnan and Floyd Informational [Page 11] From tcplw-relay@services.BSDI.COM Mon Jan 5 08:53:47 1998 Delivery-Date: Mon, 05 Jan 1998 08:54:02 -0500 Return-Path: tcplw-relay@services.BSDI.COM Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA15182 for ; Mon, 5 Jan 1998 08:53:07 -0500 (EST) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA01813 for ; Mon, 5 Jan 1998 08:55:54 -0500 (EST) Received: (from daemon@localhost) by services.BSDI.COM (8.8.8+ESF/8.8.8) id GAA00443 for tcplw-list@bsdi.com; Mon, 5 Jan 1998 06:48:03 -0700 (MST) Received: from janus.unik.no (janus.unik.no [193.156.96.46]) by services.BSDI.COM (8.8.8+ESF/8.8.8) with ESMTP id GAA00380 for ; Mon, 5 Jan 1998 06:47:45 -0700 (MST) Received: from [193.156.96.38] (atlantis.unik.no [193.156.96.38]) by janus.unik.no (8.8.5/8.7.3) with SMTP id OAA20058; Mon, 5 Jan 1998 14:34:37 +0100 (MET) Date: Mon, 5 Jan 1998 14:34:37 +0100 (MET) X-Sender: goebel@janus.unik.no Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" To: alg@comm.toronto.edu, apc@ee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, cellular@comnets.rwth-aachen.de, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, end2end-interest@isi.edu, enternet@bbn.com, f-troup@codex.cis.upenn.edu, fokus-user@fokus.gmd.de, g-troup@ccrc.wustl.edu, giga@tele.pitt.edu, hipparch@sophia.inria.fr, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, isadsoc@fokus.gmd.de, itc@fokus.gmd.de, modern-heuristics@uk.ac.mailbase, multicomm@cc.bellcore.com, osimcast@bbn.com, rem-conf@es.net, reres@laas.fr, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sigmedia@bellcore.com, tccc@ieee.org, xtp-relay@cs.concordia.ca, cost237-teleservices@comp.lancs.ac.uk, tcplw@bsdi.com From: goebel@unik.no (Vera Goebel) Subject: CfP - IDMS'98 (reminder) Cc: idms98@unik.no Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by services.BSDI.COM id GAA00440 Please accept our apologies if you receive multiple copies of this announcement. You will be doing us a great favor if you disseminate the this Call for papers among your interested colleagues. Thanks. **************************************************************************** REMINDER: Call for Papers IDMS'98 5th International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services 8. - 11. September 1998, Oslo, Norway The Fifth International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services follows the successful IDMS workshops held 1997 in Darmstadt and 1996 in Berlin. The purpose of this workshop is to bring together researchers, developers, and practitioners from academia and industry. The workshop serves as a forum for discussion, presentation, and exploration of technologies and their advances in the broad field of interactive distributed multimedia systems and telecommunication services -- ranging from basic system technologies such as networking and operating system support to all kinds of teleservices and distributed multimedia applications. Case studies and papers describing experimental work are especially welcome. Relevant topics include, but are not limited to · High-speed/ATM networks · Mobile multimedia systems · Multimedia over sattelite · Multimedia middelware · Quality of service issues · Media scaling · Resource management · Protocol design and implementation · Distributed multimedia database systems · Development tools for distributed multimedia applications · Multimedia-specific intelligent agents · Computer supported collaborative work · Distributed virtual reality systems · Distance education · Conferencing · Digital libraries · Interactive television · Video-on-demand systems · Compression algorithms IDMS'98 will consist of a three day technical program, a full day of tutorials, and demonstrations during the workshop. In order to keep the flavour of a workshop, the number of participants will be restricted. Furthermore, we encurage contributions in form of full papers and position papers. Full papers are expected to describe innovative and significant work. The purpose of position papers is to provide a seed for debate and discussion. Position papers enable researchers to present exciting ongoing work in early stages, suggestions for future directions, and concerns about current developments. Both types of papers will be reviewed by the program committee and printed in the workshop proceedings. The proceedings will be published in the Springer LNCS series and will be available during the workshop. It is intended to forward selected papers to a special issue of the "Computer Communications" Journal. Information for authors: Authors are invited to submit full papers and position papers for review. Submitted manuscripts must describe original work (not submitted or published elsewhere). Full papers must not be longer than 20 double spaced pages and position papers must not be longer than 8 double spaced pages. Both types of papers should contain an abstract of approximately 300 words, and include title, authors and affiliations. The submission process of papers will be handled electronically. Detailed description of the electronic submission procedures is available on the IDMS'98 web page: http://www.unik.no/~idms98. Authors without web access may send mail to idms98@unik.no requesting electronic submission information. Authors unable to submit electronically are invited to send 5 copies of their contribution to one of the workshops chairs ATTN: IDMS'98. Important dates: Submission due: February 1, 1998 Notification of acceptance: April 15, 1998 Camera ready version: May 15, 1998 Workshop: September 9 - 11, 1998 Program co-chairs: Vera Goebel and Thomas Plagemann UniK - Center for Technology at Kjeller, University of Oslo, P.O. Box 70, N-2007 Kjeller, Norway Email: {goebel; plageman}@unik.no, Phone: +47/63.81.45.70, Fax: +47/63.81.81.46 Program Committee: F. A. Aagesen, NTNU, Norway H. Affifi, ENST Bretagne, France E. Biersack, Institut Eurécom, France G. Bochmann, U. Montreal, Canada B. Butscher, DeTeBerkom, Germany A. T. Campbell, Columbia U., USA S. Chanson , Hongkong U., HK L. Delgrossi, U. Piacenza, Italy M. Diaz, LAAS-CNRS, France F. Eliassen, U. Tromsø, Norway W. Effelsberg, U. Mannheim, Germany D. Ferrari, U. Cattolica Piacenza, Italy J.-P. Hubaux, EPFL, Switzerland D. Hutchison, Lancaster U., UK W. Kalfa, TU Chemnitz, Germany T. D. C. Little, Boston U., USA E. Moeller, GMD FOKUS, Germany K. Nahrstedt, U. Illinois, USA G. Parulkar, Washington U., USA B. Pehrson, KTH Stockholm, Sweden S. Pink, SICS, Sweden B. Plattner, ETH Zurich, Switzerland H. Scholten, U. Twente, Netherlands R. Steinmetz, GMD, Germany H. Tokuda, Keio U., Japan L. Wolf, TH Darmstadt, Germany M. Zitterbart, TU Braunschweig, Germany ACM Multimedia'98 takes place in Bristol (UK) in the week following IDMS'98: http://www.acm.org/sigmm/MM98. ------------------------------------------------------------------------- Dr. Vera Goebel Tel. +47/63.81.45.71.219 (direct) Associate Professor or Tel. +47/63.81.45.70 (swichboard) UNIK Center for Technology at Kjeller University of Oslo Fax. +47/63.81.81.46 PO BOX 70 N-2007 Kjeller email: goebel@unik.no Norway http://www.unik.no/~goebel/ ------------------------------------------------------------------------- From tcplw-relay@services.BSDI.COM Thu Jan 22 13:54:35 1998 Delivery-Date: Thu, 22 Jan 1998 13:54:36 -0500 Return-Path: tcplw-relay@services.BSDI.COM Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA15207 for ; Thu, 22 Jan 1998 13:54:35 -0500 (EST) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA14559 for ; Thu, 22 Jan 1998 13:57:19 -0500 (EST) Received: (from daemon@localhost) by services.BSDI.COM (8.8.8+ESF/8.8.8) id LAA02782 for tcplw-list@bsdi.com; Thu, 22 Jan 1998 11:41:51 -0700 (MST) Received: from ns.owlseye.com (owl@ns.owlseye.com [199.173.193.212]) by services.BSDI.COM (8.8.8+ESF/8.8.8) with ESMTP id LAA02773 for ; Thu, 22 Jan 1998 11:41:49 -0700 (MST) Received: (from owl@localhost) by ns.owlseye.com (8.8.8/8.7.3) id NAA08578; Thu, 22 Jan 1998 13:24:09 -0500 (EST) Date: Thu, 22 Jan 1998 13:24:09 -0500 (EST) Message-Id: <199801221824.NAA08578@ns.owlseye.com> From: owl@owlseye.com To: tcplw@bsdi.com Reply-To: owl@owlseye.com Subject: OK to send e-mail? X-Spam-I-Am: services.BSDI.COM 1000/200000 OK to send an e-mail to tcplw@bsdi.com? From tcplw-relay@services.BSDI.COM Tue Jan 27 23:51:05 1998 Delivery-Date: Tue, 27 Jan 1998 23:51:05 -0500 Return-Path: tcplw-relay@services.BSDI.COM Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA25421 for ; Tue, 27 Jan 1998 23:51:05 -0500 (EST) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA09779 for ; Tue, 27 Jan 1998 23:53:48 -0500 (EST) Received: (from daemon@localhost) by services.BSDI.COM (8.8.8+ESF/8.8.8) id VAA14593 for tcplw-list@bsdi.com; Tue, 27 Jan 1998 21:48:22 -0700 (MST) Received: from ns.owlseye.com (owl@ns.owlseye.com [199.173.193.212]) by services.BSDI.COM (8.8.8+ESF/8.8.8) with ESMTP id VAA14562 for ; Tue, 27 Jan 1998 21:48:21 -0700 (MST) Received: (from owl@localhost) by ns.owlseye.com (8.8.8/8.7.3) id XAA23057; Tue, 27 Jan 1998 23:30:48 -0500 (EST) Date: Tue, 27 Jan 1998 23:30:48 -0500 (EST) Message-Id: <199801280430.XAA23057@ns.owlseye.com> From: owl@owlseye.com To: tcplw@bsdi.com Reply-To: owl@owlseye.com Subject: Is Your Web Site A Secret? X-Spam-I-Am: services.BSDI.COM 1000/200000 To: tcplw@bsdi.com Is your web site the best kept secret on the Internet? We'll promote it to 50 search engines and indexes for $85 and complete the job in 2 business days. Satisfaction is guaranteed! If you have a great product, but are not getting many inquiries from your Web site, you may not be adequately listed on the Web's search engines and indexes. Millions of viewers daily use these facilities to find the products and services they are looking for. But if your site is not listed, no one will see it. Listings on most of these services are free. However, locating and filling out the forms required to get a listing can take several days, and most people just don't have the time to do it. That is why we offer a web site promotion service. WHAT'S THE DEAL? We will submit your site to 50 indexes and search engines for $85. We will accept the return of this E-mail, with the form below filled out, as an order. We will bill you upon completion of the promotion. Our terms are net 15 days from date of invoice. Satisfaction guaranteed! HOW LONG WILL IT TAKE? Generally, we complete the submissions within 48 hours of receiving your order. It can take any individual search engine or index up to three weeks to process your submission, although most are much faster. WHAT SEARCH ENGINES AND INDEXES ARE INCLUDED IN THE PROMOTION? The list changes from time to time. This is our current list: Alta Vista, BC Internet, BizCardz Business Directory, BizWeb, Excite, Galaxy, HotBot, Infoseek, InfoSpace, Jayde Online Directory, JumpCity JumpLink, Linkcentre Directory, LinkMonster, Lycos, Magellan, Manufacturers Information Network, Net Happenings, Net Mall, Net-Announce, New Page List, New Riders WWW Yellow Pages, Northern Light, One World Plaza, Open Text Web Index, PageHost A-Z, PeekABoo, Project Cool, Scrub The Web, Seven Wonders, Sserv, Starting Point, The Galactic Galaxy, The Weekly Bookmark, True North,TurnPike, Unlock:The Information Exchange, Web 100, Web Crawler, Web Walker, Web World Internet Directory, WebVenture Hotlist, What's New, WhatUSeek, Where2Go, World Wide Business Yellow Pages, Wow! Web Wonders!, WWW Worm, YelloWWWeb, Your WebScout HOW WILL I KNOW THAT YOU HAVE PROMOTED MY SITE? When we have completed the promotion, we will send you an HTML file as an attachment to your E-mail bill. Save this file to your disk, and view it through your Web browser. It provides links to the search engine we submitted your site to, plus any comments we received from them when we did it. ARE THERE ANY GUARANTEES? We do not require prepayment. Your satisfaction is guaranteed or you don't pay the bill. WHO IS OWL'S EYE PRODUCTIONS? We are a web site promotion company located at: Owl's Eye Productions, Inc. 260 E. Main Street Brewster, NY 10509 Phone: (914) 278-4933 Fax: (914) 278-4507 Email: owl@secretwebsite.com HOW DO I ORDER? The easiest way to order is by e-mail. Just hit the REPLY button on your e-mail program and fill out the following information. (This information will be posted to the search engines/indexes): Your name: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: URL: http:// Site Title: Description (about 25 words): Key words (maximum of 25, in descending order of importance): Proofs (Where shall we e-mail proofs): If billing a different address, please complete the following: Addressee: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: We will bill via Email. (SE7N09) Terms: By returning this document via Email, you agree as follows: You have the authority to purchase this service on behalf of your company. Terms are net 15 days. Accounts sent to collections will be liable for collection costs. You agree to protect and indemnify Owl's Eye Productions, Inc. in any claim for libel, copyright violations, plagiarism, or privacy and other suits or claims based on the content or subject matter of your site. WHAT HAPPENS NEXT? When we receive your order, we will input the information into our system. Then we will run your promotion, capturing any comments from search engines as we go. We will incorporate these into an HTML-formatted report to you, which we will attach to your bill. ===================================================================== Owl's Eye Productions, Inc. 260 E. Main Street Brewster, NY 10509 Ph: 914-278-4933 Fx: 914-278-4507 E-mail: owlseye@secretwebsite.com From tcplw-relay@services.BSDI.COM Wed Feb 18 03:20:11 1998 Delivery-Date: Wed, 18 Feb 1998 03:20:12 -0500 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id DAA24634 for ; Wed, 18 Feb 1998 03:20:11 -0500 (EST) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA11275 for ; Wed, 18 Feb 1998 03:22:49 -0500 (EST) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id BAA16601 for tcplw-list@bsdi.com; Wed, 18 Feb 1998 01:17:02 -0700 (MST) Received: from mailfilter.BSDI.COM (root@mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id BAA16589 for ; Wed, 18 Feb 1998 01:16:58 -0700 (MST) From: info@cigi.com Received: from dfw-ix16.ix.netcom.com (dfw-ix16.ix.netcom.com [206.214.98.16]) by mailfilter.BSDI.COM (8.8.8+ESF/8.8.8) with ESMTP id BAA16464 for ; Wed, 18 Feb 1998 01:16:45 -0700 (MST) Received: (from smap@localhost) by dfw-ix16.ix.netcom.com (8.8.4/8.8.4) id CAA09819 for ; Wed, 18 Feb 1998 02:16:09 -0600 (CST) Date: Wed, 18 Feb 1998 02:16:09 -0600 (CST) Message-Id: <199802180816.CAA09819@dfw-ix16.ix.netcom.com> Received: from dd44-159.dub.compuserve.com(199.174.176.159) by dfw-ix16.ix.netcom.com via smap (V1.3) id rma006541; Wed Feb 18 02:16:02 1998 To: tcplw@bsdi.com Subject: Shopping Cart - Free Demo Hello, Thought you may be interested in installing a shopping cart to help better service your customers. If you are interested in seeing how this works you can go to my demo store at: http://205.147.208.119/cashcart/index.html This cart is packed with every possible feature you could ever want. It even comes with a built in search engine. If you would like to find out more about the carts features, you can go to: http://205.147.208.119/cashcart/features.html It won't cost you anything but some time and your commitment to get started. We do not ask for any payments up front, all we ask is that you meet the following requirements: 1) Your pages must be hosted on a UNIX type server. 2) You are serious about purchasing a Shopping Cart to enhance your website. Thats it. If you meet the above requirements, and are ready to add a Shopping Cart to your website, contact us today so we can get started on your working demo. This demo will be created from your own online catalog and will be used as your templates. When you are satisfied with the performance of your working demo and are ready to transfer it over to your server, that is when we ask for payment. PRICES Shopping Cart Program and Manual. $250.00 Shopping Cart Program, Manual, Installation and Tech Support. $425.00 Once we receive payment we will install the Shopping Cart on your server, or provide you with detailed instructions on how to do it yourself, the choice is yours. You will also receive your templates and instructions on how to use them. If you get stuck along the way, we offer tech support via phone or e-mail, for as long as you need it. If you are interested in taking your website to the "next level", or if you have any questions, please, contact me at info@cigi.com Thanks, Eric From tcplw-relay@services.BSDI.COM Tue Mar 17 13:20:49 1998 Delivery-Date: Tue, 17 Mar 1998 13:20:49 -0500 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA12088 for ; Tue, 17 Mar 1998 13:20:49 -0500 (EST) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA09636 for ; Tue, 17 Mar 1998 13:23:21 -0500 (EST) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id LAA04936 for tcplw-list@bsdi.com; Tue, 17 Mar 1998 11:17:59 -0700 (MST) Received: from mailfilter.BSDI.COM (mfadmin@mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id LAA04933 for ; Tue, 17 Mar 1998 11:17:58 -0700 (MST) Received: from hugo.int-evry.fr (hugo.int-evry.fr [157.159.100.81]) by mailfilter.BSDI.COM (8.8.8-ESF/8.8.5) with ESMTP id LAA23666 for ; Tue, 17 Mar 1998 11:17:21 -0700 (MST) env-from (tabouri@hugo.int-evry.fr) Received: from asterix.int-evry.fr (asterix [157.159.100.23]) by hugo.int-evry.fr (8.8.0/8.8.0) with ESMTP id TAA16624 for ; Tue, 17 Mar 1998 19:17:19 +0100 (MET) From: Marine TABOURIER Received: (tabouri@localhost) by asterix.int-evry.fr (8.8.0/8.6.4) id TAA16651 for tcplw@bsdi.com; Tue, 17 Mar 1998 19:17:15 +0100 (MET) Date: Tue, 17 Mar 1998 19:17:15 +0100 (MET) Message-Id: <199803171817.TAA16651@asterix.int-evry.fr> To: tcplw@bsdi.com Subject: CfP: Estelle'98 - Int. Workshop on the FDT Estelle Please accept our apologies in case you receive multiple copies. CALL FOR PAPERS ______ _ _ _ _ ___ ___ | ____| | | | | | ( ) _ \ / _ \ | |__ ___| |_ ___| | | ___|/ (_) | (_) | | __| / __| __/ _ \ | |/ _ \ \__, |> _ < | |____\__ \ || __/ | | __/ / /| (_) | |______|___/\__\___|_|_|\___| /_/ \___/ International Workshop on the Formal Description Technique Estelle November 2, 1998 Institut National des Telecommunications Evry, France http://www.informatik.uni-mannheim.de/informatik/pi4/events/estelle98/ Estelle'98 is a satellite workshop of FORTE/PSTV'98 Estelle is a Formal Description Technique for open distributed systems, in particular for communication protocols, and is an international standard since 1989. By today, Estelle has been successfully applied to specify communication standards, to serve as a basis for system analysis and as a starting point for the automatic generation of implementations directly from formal specifications. For these purposes, commercial and academic tool environments are readily available. The Estelle'98 workshop shall be a forum for industry and academia to present and discuss ongoing and planned activities related to Estelle, to demonstrate tools, to share ideas and experiences, and to develop a joint strategy for future actions. Estelle'98 will be held on November 2, 1998, the day before the start of FORTE/PSTV'98. The workshop will be located at the Institut National des Telecommunications (INT) in Evry, close to Paris. Contents: ~~~~~~~ For the one-day workshop, presentations and tool demonstrations from academia as well as from industry are invited on the following (non-exclusive) Estelle-related list of topics: - Estelle language enhancements, e.g. - Graphical syntax - Open Estelle - Real Time Estelle - Language support for data referencing - Estelle tool development, e.g. - graphical editors - simulators - validation tools - tools for parallel implementation - tools for efficient implementation - Estelle (real-life) applications, e.g. - protocols - standards - distributed systems Workshop Organization: ~~~~~~~~~~~~~~~~~~~~ Estelle'98 will be a satellite workshop of FORTE/PSTV'98, the Joint International Conference of Formal Description Techniques and Protocol Specification, Testing, and Verification, to be held in Paris the same week. Its working language is English. In order to enable in-depth discussions, the workshop proceedings will be published electronically ahead of the event. Evaluation and Publication of Submitted Papers: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Contributions will be evaluated on the basis of an extended abstract. In order to preserve the workshop character, the submission of full papers is optional. The workshop proceedings will be published electronically ahead of the workshop. Also, printed proceedings will be available at the workshop. Instructions to Authors: ~~~~~~~~~~~~~~~~~~~~~~ Extended abstracts (up to 3 pages) and proposals for tool demonstrations should be submitted to: Dr. Stefan Fischer Universitaet Mannheim Lehrstuhl fuer Praktische Informatik IV D-68131 Mannheim, Germany Tel: (+49) 621/292-1407 Fax: (+49) 621/292-5745 Email: stefis@pi4.informatik.uni-mannheim.de Electronic submission in postscript is preferred. Alternatively, also the submission of 4 copies of your manuscript is possible. It should include the name and postal, fax and e-mail addresses of the contact person. Notification of acceptance will be done via e-mail. Further information: ~~~~~~~~~~~~~~~~~~ Please contact Dr. Stefan Fischer, Tel: (+49) 621/292-1407, Fax: (+49) 621/292-5745, Email: stefis@pi4.informatik.uni-mannheim.de Important Dates: ~~~~~~~~~~~~~~ May 31, 1998 Submission deadline June 30, 1998 Notification of acceptance September 1, 1998 Final version for electronic proceedings due September 1, 1998 Proposals for tool demonstrations due October 15, 1998 Electronic proceedings available Workshop Organization Chair: ~~~~~~~~~~~~~~~~~~~~~~~~~~ Jean-Luc Raffy (Institut National des Telecommunications (INT), France) ======================================================================= estelle@cs.umb.edu is an unmoderated mailing list for topics related to Estelle (IS 9074), a Formal Description Technique for distributed systems. Mail sent to "estelle@cs.umb.edu" reaches all subscribers to the list. To subscribe or unsubscribe, mail a message with just that word as its body to "estelle-request@cs.umb.edu". For archives or more information, mail a message with just the word "help" to "estelle-request@cs.umb.edu". Workshop Co-Chairs: ~~~~~~~~~~~~~~~~~ Stanislaw Budkowski (Institut National des Telecommunications (INT), France) Stefan Fischer (University of Mannheim, Germany) Reinhard Gotzhein (University of Kaiserslautern, Germany) Program Committee: ~~~~~~~~~~~~~~~~ Paul Amer (University of Delaware, USA) Eugen Borcoci (University of Bucharest, Romania) Jan Bredereke (McMaster University, Hamilton, Canada) Jean-Pierre Courtiat (LAAS-CNRS, France) Piotr Dembinski (IPIPAN, Poland) Roland Groz (CNET, France) Richard Tenney (University of Massachusetts, Boston, USA) Workshop Organization Chair: ~~~~~~~~~~~~~~~~~~~~~~~~~~ Jean-Luc Raffy (Institut National des Telecommunications (INT), France) ======================================================================= estelle@cs.umb.edu is an unmoderated mailing list for topics related to Estelle (IS 9074), a Formal Description Technique for distributed systems. Mail sent to "estelle@cs.umb.edu" reaches all subscribers to the list. To subscribe or unsubscribe, mail a message with just that word as its body to "estelle-request@cs.umb.edu". For archives or more information, mail a message with just the word "help" to "estelle-request@cs.umb.edu". From tcplw-relay@services.BSDI.COM Tue Mar 17 13:20:56 1998 Delivery-Date: Tue, 17 Mar 1998 13:20:56 -0500 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA12095 for ; Tue, 17 Mar 1998 13:20:56 -0500 (EST) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA09640 for ; Tue, 17 Mar 1998 13:23:28 -0500 (EST) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id LAA04875 for tcplw-list@bsdi.com; Tue, 17 Mar 1998 11:16:46 -0700 (MST) Received: from mailfilter.BSDI.COM (mfadmin@mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id LAA04870 for ; Tue, 17 Mar 1998 11:16:45 -0700 (MST) Received: from hugo.int-evry.fr (hugo.int-evry.fr [157.159.100.81]) by mailfilter.BSDI.COM (8.8.8-ESF/8.8.5) with ESMTP id LAA23624 for ; Tue, 17 Mar 1998 11:16:09 -0700 (MST) env-from (tabouri@hugo.int-evry.fr) Received: from asterix.int-evry.fr (asterix [157.159.100.23]) by hugo.int-evry.fr (8.8.0/8.8.0) with ESMTP id TAA16334 for ; Tue, 17 Mar 1998 19:15:58 +0100 (MET) From: Marine TABOURIER Received: (tabouri@localhost) by asterix.int-evry.fr (8.8.0/8.6.4) id TAA16295 for tcplw@bsdi.com; Tue, 17 Mar 1998 19:15:54 +0100 (MET) Date: Tue, 17 Mar 1998 19:15:54 +0100 (MET) Message-Id: <199803171815.TAA16295@asterix.int-evry.fr> To: tcplw@bsdi.com Subject: CFP - Special session in FORTE/PSTV'98 CALL FOR PAPERS (http://www.res.enst.fr/~najm/FORTE_PSTV98/ECASP.html) A special session on *EDUCATIONAL CASE STUDIES IN PROTOCOLS* is to be held at FORTE/PSTV'98 FORMAL DESCRIPTION TECHNIQUES (FORTE XI) - PROTOCOL SPECIFICATION, TESTING, AND VERIFICATION (PSTV XVIII) PARIS, 3-6 November 1998 http://alix.int-evry.fr/~stan/FORTE_PSTV98/ The special session will be devoted to presenting educational case studies on protocols and distributed systems. The case studies may include various tutorial aspects such as animation, formal specification, debugging and automated verification. In the past few years a large number of tool supported case studies have been developed in an educational context (e.g. as a University course, or industrial training package) and the aim of this session is to report on the experience that has been capitalized in this important domain. During this special session, authors may include in their presentations an on-line, notebook based, demonstration of the case study. The chosen case studies may be also demonstrated during the conference. The session will take place either in the first tutorial day or during the conference itself. We invite contributors to present a description of their case study including, for example: * the objectives * the chosen protocol or distributed application * the chosen formal technique and tool the educational scenario: the different steps involved and the work to be performed by the students. Important Dates: * now -- It is recommended to send an intention to contribute * 15 May, 1998 -- Submission deadline for papers * 15 June, 1998 -- Notification of acceptance * July 10, 1998 -- Final Postscript version for Proceedings due Session Co-Chairs: John DERRICK UKC - UK (J.Derrick@ukc.ac.uk) Elie NAJM ENST - France (Elie.Najm@Email.ENST.fr) Submission policy: Full papers or Extended abstracts should be up to 16 pages, 12 point, single spaced, including an informative abstract as well as names and affiliations of all authors. Authors should indicate a contact author (including postal and E-mail address). Authors are strongly encouraged to use A4 size papers and to make sure that their submissions are easy to print on a variety of postscript printers (e.g. by using standard fonts). Authors are encouraged to submit their papers electronically. Submissions should be made to the following address: ecasp-98@inf.enst.fr in two separate e-mails: * an e-mail with your paper in postscript format (uuencoded and compressed with 'compress' or 'gzip'); * an e-mail in plain text (ASCII) with the title of your paper, the name of the authors and their institutions, a list of keywords, an abstract of your paper and the name and postal, fax and e-mail addresses of the contact person. From tcplw-relay@services.BSDI.COM Tue Mar 17 13:20:57 1998 Delivery-Date: Tue, 17 Mar 1998 13:20:57 -0500 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA12101 for ; Tue, 17 Mar 1998 13:20:57 -0500 (EST) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA09643 for ; Tue, 17 Mar 1998 13:23:29 -0500 (EST) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id LAA04734 for tcplw-list@bsdi.com; Tue, 17 Mar 1998 11:14:10 -0700 (MST) Received: from mailfilter.BSDI.COM (mfadmin@mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id LAA04730 for ; Tue, 17 Mar 1998 11:14:10 -0700 (MST) Received: from hugo.int-evry.fr (hugo.int-evry.fr [157.159.100.81]) by mailfilter.BSDI.COM (8.8.8-ESF/8.8.5) with ESMTP id LAA23568 for ; Tue, 17 Mar 1998 11:13:27 -0700 (MST) env-from (tabouri@hugo.int-evry.fr) Received: from asterix.int-evry.fr (asterix [157.159.100.23]) by hugo.int-evry.fr (8.8.0/8.8.0) with ESMTP id TAA15599 for ; Tue, 17 Mar 1998 19:13:20 +0100 (MET) From: Marine TABOURIER Received: (tabouri@localhost) by asterix.int-evry.fr (8.8.0/8.6.4) id TAA15319 for tcplw@bsdi.com; Tue, 17 Mar 1998 19:13:15 +0100 (MET) Date: Tue, 17 Mar 1998 19:13:15 +0100 (MET) Message-Id: <199803171813.TAA15319@asterix.int-evry.fr> To: tcplw@bsdi.com Subject: Reminder: FORTE/PSTV'98 call for papers [Apologies for any duplicates] Due to numerous requests, the FORTE/PSTV'98 Program Committee has decided to extend the deadline for paper submissions till 30st March 1998. If you have submitted a paper, you should have received an acknowledgement which includes a ticket number of the form "FORTE/PSTV'98-XXX", where XXX is a 3 digit number. You should quote this number in all future correspondence. If you have NOT received an acknowledgement, it probably means that your paper submission did not include a valid email address, that your electronic submission was corrupted or that your e-mail was lost (very unlikely but still possible). Please contact us at forte-pstv@hugo.int-evry.fr to resolve such issues. Please find below un updated Second Call for Papers. Thank you for your attention FORTE/PSTV'98 Program Committee ========================================================================== Second Call for Papers 1998 IFIP TC6/WG6.1 Joint International Conference FORTE/PSTV'98 FORMAL DESCRIPTION TECHNIQUES (FORTE XI) & PROTOCOL SPECIFICATION, TESTING, AND VERIFICATION (PSTV XVIII) PARIS, 3-6 November 1998 General WWW page: http://www.res.enst.fr/~najm/FORTE_PSTV98/ Program Committee WWW page: http://www-lor.int-evry.fr/~stan/FORTE_PSTV98/ Satellite & Associated events: SPIN 98 Workshop - Paris, 2 November 1998 Estelle 98 Workshop - Evry, 2 November 1998 EDUCATIONAL CASE STUDIES ON PROTOCOLS - A special session at the conference, November 3 - 6, 1998 The two separate conferences FORTE and PSTV have been combined, since 1996, into a joint edition FORTE/PSTV. FORTE/PSTV'98 will address Formal Description Techniques (FDTs) applicable to Distributed Systems and Communication Protocols. FDTs include different approaches, based on Process Algebras (CCS, pi-calculus, LOTOS, stochastic, etc.), Extended Automata, (SDL, Estelle, timed automata, statecharts, reactive, etc.), Set Theory (B, Z, VDM, etc.), Logics (temporal, TLA, etc.), ADTs (OBJ, Larch, etc.) and other standard notations (MSCs, ASN.1, TTCN, etc.). FORTE/PSTV will consider the entire development cycle of communication protocols, distributed systems and applications (specification, verification, testing, performance analysis, and implementation). The conference will be a forum for presentation of the state of the art in theory, application, tools and industrialization of FDTs, and will provide an excellent orientation for newcomers. Research papers and industrial usage reports as well as proposals for tutorials (advanced technology seminars), poster displays and tool demonstrations are solicited, particularly in the following areas: FDT applications to the development cycle of network protocols and distributed systems engineering: * Requirements capture, specification and verification/validation * Simulation, implementation, debugging and tuning * Testing, test selection, test generation and test coverage * Performance analysis and modelling * Quality of Service modelling and verification * Real time and probability modelling and verification * Integration of FDTs and development methodologies * Case studies FDT applications in the areas of: * Multicast and multimedia protocols * Distributed platforms and middleware protocols * Internet protocols * High speed protocols * Mobile communication * Network security protocols * Medium access control protocols, local loop protocols * Factory communication protocols * Field Bus protocols * Case studies FDT applications to telecommunication services and distributed applications: * Architectures for telecommunication services (Intelligent Network architecture, TINA, object based architectures, CORBA, COM-DCOM, ActiveX, internet,...) * Service creation, service composition, service and feature interaction * Reusable components architectures * Workflow and Groupware * Case studies Development of Formal Description Techniques, methods and tools: * Semantic foundations * Formal support to object modelling * Extensions of FDTs * Real-time and probability aspects * Consistency and refinement relations * Practical algorithms and tool support * Case studies Industrial and business focus: * Corporate strategic and financial consequences of FDT use * Corporate experiences in FDT based developments * Tools and training cases for protocols teaching * Case studies Important dates (modified): * March 30, 1998 -- Submission deadline * June 8, 1998 -- Notification of acceptance * July 6, 1998 -- Camera-ready copy for final proceedings due General Chair: Elie NAJM - ENST - Elie.Najm@Email.ENST.fr Program Committee Co-Chairs: Stanislaw BUDKOWSKI - INT - Stanislaw.Budkowski@int-evry.fr Ana CAVALLI - INT - Ana.Cavalli@int-evry.fr Local Arrangment Chair: Sylvie Vignes - ENST - Sylvie.Vignes @Email.ENST.fr Submission policy: Full original research papers and industrial usage reports should be up to 16 pages, 12 point, single spaced, including an informative abstract as well as names and affiliations of all authors, and a list of keywords facilitating the assignment of papers to referees. For industrial usage reports, short papers up to 8 pages are also welcome. Authors should indicate a contact author (including postal and E-mail address) and the preferred category (research paper or industrial usage report) in which the paper should be considered. Authors are strongly encouraged to use A4 size papers and to make sure that their submissions are easy to print on a variety of postscript printers (e.g. by using standard fonts). Authors are required not to submit papers that have been submited to another conference or a journal. Authors are encouraged to submit their full original research papers and industrial usage reports electronically. Submissions should be made to the following address: forte-pstv@hugo.int-evry.fr in two separate e-mails: * an e-mail with your paper in postscript format (uuencoded and compressed with 'compress' or 'gzip'); * an e-mail in plain text (ASCII) with the title of your paper, the name of the authors and their institutions, a list of keywords, an abstract of your paper and the name and postal, fax and e-mail addresses of the contact person. Late submissions or papers which are too long or require substantial revision will not be considered. Authors unable to submit electronically are invited to send 5 copies of a paper (report) to: Stanislaw BUDKOWSKI , Ana CAVALLI Institut National des Telecommunications (INT) Software-Networks Department 9, rue Charles Fourier, 91011 Evry Cedex, FRANCE Phone : +33 (0)1 60 76 47 20 Fax : +33 (0)1 60 76 47 11 Email:stan@int-evry.fr, Ana.Cavalli@int-evry.fr Please consult Program Committee WWW page to access current information: http://www-lor.int-evry.fr/~stan/FORTE_PSTV98/ For tutorials and tool demonstrations authors are invited to send their proposals (electronically, if possible), before 15th April, to the following address: Elie NAJM Ecole Nationale Superieure des Telecommunications (ENST) 46, Rue Barrault, 75013 - Paris, FRANCE Phone : +33 (0)1 45 81 77 09 Fax : +33 (0)1 45 89 16 64 Email : Elie.Najm@Email.ENST.fr ====================================================================== Program Committee: P. Amer (Univ. of Delaware, USA), J.W Atwood (Concordia Univ., Canada), G. v. Bochmann (Univ. of Ottawa, Canada), T. Bolognesi (IEI, Italy), H. Bowman (Univ. of Kent at Canterbury, UK), E. Brinksma (Univ. of Twente, Netherlands), R. Castanet (Univ. of Bordeaux, France), O. Catrina (Univ. of Bucharest,Romania), S. T. Chanson (Univ. of Sci. and Tech., Hong Kong), J.-P. Courtiat (LAAS-CNRS, France), P. Dembinski (IPIPAN, Poland), M. Diaz (LAAS, France), R. Dssouli (Univ. of Montreal, Canada), S. Fischer (Univ. of Mannheim, Germany), R. Gorrieri (Univ. of Bologna, Italy), R. Gotzhein (Univ. of Kaiserslautern, Germany), R. Groz (CNET, France), T. Higashino ( Osaka Univ. Japan), D. Hogrefe (Univ. of Luebeck, Germany), S. P. Iyer (North Carolina State Univ.), M. C. Kim (IC Univ., Korea), P. Kritzinger (Univ. of Cape Town, South Africa), R. Lai (La Trobe Univ. Australia), G. Leduc (Univ. of Liege, Belgium), D. Lee (Bell Lab., USA), S. Leue (Univ. of Waterloo, Canada), L. Logrippo (Univ. of Ottawa, Canada), O. Rafiq (Univ. of Pau, France), T. Mizuno (Shizuoka Univ., Japan), A. Petrenko (CRIM, Canada), J. Quemada (ETSI Telecom., Spain), H. Rudin (IBM, Switzerland), A. Shaff (LORIA, France), D. Sidhu (Univ. of Maryland-BC, USA), N. Shiratori (Tohuku Univ., Japan), J.B. Stefani(CNET, France), K. Suzuki (KDD, Japan), K. Tarnay (Univ. of Budapest, Hungary), R. Tenney (Univ. of Massachusetts, Boston, USA), A. Togashi (Shizuoka Univ., Japan), K. Turner (Univ. of Stirling, UK), S. T. Vuong (Univ. of British Columbia, Canada), N. Yevtuchenko (Tomsk Univ., Russia), J. Wu (Tsinghua Univ., China) From tcplw-relay@services.BSDI.COM Sat Apr 11 07:16:51 1998 Delivery-Date: Sat, 11 Apr 1998 07:16:51 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id HAA12143 for ; Sat, 11 Apr 1998 07:16:50 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id HAA13167 for ; Sat, 11 Apr 1998 07:19:19 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id FAA21201 for tcplw-list@bsdi.com; Sat, 11 Apr 1998 05:10:40 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id FAA21198 for ; Sat, 11 Apr 1998 05:10:39 -0600 (MDT) Received: from mr.tuwien.ac.at (mr.tuwien.ac.at [128.130.2.10]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id FAA16996 for env-from (Harmen.R.van-As@tuwien.ac.at); Sat, 11 Apr 1998 05:10:28 -0600 (MDT) Received: from logo (actually logo.ikn.tuwien.ac.at) by mr.tuwien.ac.at with SMTP (PP); Sat, 11 Apr 1998 13:10:35 +0200 Message-Id: <3.0.3.32.19980411130332.009f9e50@mail.zserv.tuwien.ac.at> X-Sender: vanas@mail.zserv.tuwien.ac.at X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 11 Apr 1998 13:03:32 +0200 To: tcplw@bsdi.com From: "Harmen R. van As" Subject: 8th IFIP Conference on High Performance Networking (HPN'98) Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear member of the TCP Large Windows community We still are looking for some papers for the HPN'98 Conference in Vienna. Would there be any change that you or somebody else would be able to submit a contribution within the next two weeks? Please notify coming submission With best regards Harmen R. van As
CALL FOR TUTORIALS CALL FOR PAPERS DEADLINE EXTENDED BUT NOTIFY COMING SUBMISSION ----------------------------------------------------------- 8th IFIP Conference on High Performance Networking (HPN'98) The Millennium Push of Internet =20 Vienna University of Technology, Vienna, Austria September 21-25, 1998 ------------------------------------------------------------ http://www.ikn.tuwien.ac.at/IKN/events/hpn-cfp.html March 15, 1998: Tutorial proposal March 15, 1998: Paper submission April 15, 1998: Notification May 15, 1998: Camera-ready paper =20 Conference book published by Chapman & Hall
Paper submission: preferably postscript file attached to email=20 otherwise 5 copies of paper by postal mail Topics of interest:=20 - Trends of Internet/Intranet Technologies=20 - Next Generation Internet, Evolutionary approaches=20 - Fast Internet (ADSL, HDSL, VHDSL, PONs)=20 - Cable Network, Wireless and Satellite Access=20 - Next Generation Routers, Tag Switching=20 - Bypass Tunneling (SDH, Photonics) =20 - Network/System Architecture and Design=20 - Cache Server Allocation and Interconnection=20 - Network Availability, Automatic Reconfiguration=20 - Coporate Networks, Global Networking =20 - Security in Internet, Network/System Security=20 - Network Management using Internet=20 - WWW and Java Network Service Management=20 - Distributed Systems Management in Internet=20 - Interworking with ATM, ISDN, and LANs=20 - System Interoperability =20 - Internet Mobility Support, Mobility Management=20 - Mobile-IP, Mobile-IPv6=20 - Mobile Agents, Intelligent/Smart Agents=20 - Flow Control, Traffic Monitoring and Control=20 - Adressing and Routing =20 - Advanced Internet Protocols (RTP, RSVP)=20 - Multicast Protocols=20 - Protocol Design, Combined ATM and IP=20 - Secure Protocols (S-HTTP, SSL, SET)=20 - Internet Tunneling =20 - Quality of Service, Service Level Guarantees=20 - Resource Management=20 - Real-Time Services over Internet=20 - IP Telephony, Voice over Internet=20 - Teleconferencing, Broadband Internet=20 - Integrated Services Internet=20 - Internet in Multimedia Environments=20 - Heterogenous Distributed Environments =20 - Internet Groupware and Cooperative Work=20 - Information Management over Internet=20 - Electronic Commerce, Online-Marketing=20 - Internet Payment Systems, Webcasting=20 - WWW Servers, Tele-Service-Systems=20 - Internet Servers (Data-Base, Cache, Archive)=20 - High-Performance Tele-Activities=20 - Social Impacts, Opportunities and Threats=20 INTERNATIONAL PROGRAM COMMITTEE:=20 General Chair:=20 Harmen R. van As, Vienna University of Technology, Austria=20 Ian Akyildiz, Georgia Tech, USA=20 Torsten Braun, Univ. of Berne, CH=20 Augusto Casaca, INESC, Portugal=20 Andre Danthine, Univ. Liege, Belgium=20 Michel Diaz, Univ. Toulouse, France=20 Christophe Diot, INRIA, France=20 Otto Duarte, Univ. Fed. Rio de Janeiro, Brazil=20 J=F6rg Ebersp=E4cher, Techn. Univ. Munich, Germany=20 Serge Fdida, Univ. Paris VI, France=20 Zygmunt Haas, Cornell University, USA=20 Marjory Johnson, NASA-RIACS, USA=20 Paul K=FChn, Univ. Stuttgart, Germany=20 Ralf Lehnert, Dresden Univ. of Technology, Germany=20 Helmut Leopold, Alcatel, Austria=20 Kurt Maly, Old Dominion Univ., USA=20 Olli Martikainen, Helsinki Univ. of Technology, Finland=20 Georg Mittenecker, Vienna Univ. of Technology, Austria=20 Hussein Mouftah, Queens Univ., Canada=20 Ignas Niemegeers, Univ. of Twente, The Netherlands=20 Guru Parulkar, Washington U. St. Louis, USA=20 Stephen Pink, SICS, Sweden=20 Radu Popescu-Zeletin, GMD Fokus, Germany=20 Ramon Puigjanier, Univ. Illes Balears, Spain=20 Guy Pujolle, Univ. Versailles, France=20 Doug Shepherd, Univ. Lancaster, UK=20 Thomas Sommer, Vienna Univ. of Technology, Austria=20 Otto Spaniol, Univ. Aachen, Germany=20 Ralf Steinmetz, Techn. Univ. Darmstadt, Germany=20 Ahmed Tantawi, IBM Res., Yorktown Heights, USA=20 Fouad Tobagi, Stanford Univ., USA=20 Samir Tohm=E9, ENST, France=20 Giorgio Ventre, Univ. Napoli, Italy=20 Martina Zitterbart, Univ. Braunschweig, Germany=20 ---------------------------------------------------------------------------- Prof.Dr. Harmen R. van As Institute of Communication Networks Vienna University of Technology Tel +43-1-58801-5246 Gusshausstrasse 25/388 Fax +43-1-5870583 A-1040 Vienna, Austria email: Harmen.R.van-As@tuwien.ac.at http://www.ikn.tuwien.ac.at=20 ---------------------------------------------------------------------------- From tcplw-relay@services.BSDI.COM Tue Apr 21 11:47:36 1998 Delivery-Date: Tue, 21 Apr 1998 11:47:37 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id LAA27959 for ; Tue, 21 Apr 1998 11:47:36 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA08247 for ; Tue, 21 Apr 1998 11:50:02 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id JAA22825 for tcplw-list@bsdi.com; Tue, 21 Apr 1998 09:40:00 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id JAA22819 for ; Tue, 21 Apr 1998 09:40:00 -0600 (MDT) Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id JAA07431 for env-from (dab@frantic.bsdi.com); Tue, 21 Apr 1998 09:39:10 -0600 (MDT) Received: (from dab@localhost) by frantic.bsdi.com (8.8.8/8.8.8) id KAA06364; Tue, 21 Apr 1998 10:39:21 -0500 (CDT) Date: Tue, 21 Apr 1998 10:39:21 -0500 (CDT) From: David Borman Message-Id: <199804211539.KAA06364@frantic.bsdi.com> To: tcplw@BSDI.COM Subject: RFC-1323.bis Cc: Internet-Drafts@ns.ietf.org All right, I let this fell on the floor (again...). I'm attaching the revision to RFC 1323. This is the same document that I sent out last Feburary. I briefly looked back over the mail archives from that time (look in ftp://ftp.ietf.org/ietf-mail-archive/tcplw), and I think that I responded to all the concerns raised, without the need to make any changes to the document. The purpose is to advance RFC 1323 from Proposed to Draft, and to fix the issues that have been discovered since RFC 1323 was published. It is *not* my intent to open up RFC 1323 for complete discussion and revision. We are now about 5 years overdue with getting this done. So, consider this a working group last-call for this document. If you have any objections or comments, please first look over the mailing list archives to see if your issues have already been addressed. Otherwise, I *will* send this off to the IESG with a request that it be published as an RFC, and advanced to DRAFT status. Also, one of the requirements for advancement to DRAFT status is to have multiple interoperable implemenations. To save me time in putting together the list, please send me a short blurb about your implementation, and please indicate whether or not you have implemented the changes since RFC 1323 (see Appendix C for a list of differences). -David Borman, dab@bsdi.com ----- Cut Here ---- Network Working Group Network Working Group Internet-Draft V. Jacobson Obsoletes: 1323 LBL R. Braden ISI D. Borman BSDI February 1997 TCP Extensions for High Performance Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequences). Selective acknowledgments are not included in this memo. This memo updates and obsoletes RFC-1323, a Proposed Standard, with small clarifications and corrections. TABLE OF CONTENTS Network Working Group Expires August 1997 [Page 1] Internet-Draft TCP Extensions for High Performance February 1997 1. Introduction 2 2. TCP Window Scale Option 8 3. RTTM -- Round-Trip Time Measurement 11 4. PAWS -- Protect Against Wrapped Sequence Numbers 17 5. Conclusions and Acknowledgments 24 6. References 25 APPENDIX A: Implementation Suggestions 27 APPENDIX B: Duplicates from Earlier Connection Incarnations 27 APPENDIX C: Changes from RFC-1072, RFC-1185, RFC-1323 30 APPENDIX D: Summary of Notation 32 APPENDIX E: Pseudo-code Summary 33 APPENDIX F: Event Processing 35 APPENDIX G: TCP Options and MSS 40 Security Considerations 41 Authors' Addresses 41 1. INTRODUCTION The TCP protocol [Postel81] was designed to operate reliably over almost any transmission medium regardless of transmission rate, delay, corruption, duplication, or reordering of segments. Production TCP implementations currently adapt to transfer rates in the range of 100 bps to 10**7 bps and round-trip delays in the range 1 ms to 100 seconds. Recent work on TCP performance has shown that TCP can work well over a variety of Internet paths, ranging from 800 Mbit/sec I/O channels to 300 bit/sec dial-up modems [Jacobson88a]. The introduction of fiber optics is resulting in ever-higher transmission speeds, and the fastest paths are moving out of the domain for which TCP was originally engineered. This memo defines a set of modest extensions to TCP to extend the domain of its application to match this increasing network capability. It is based upon and obsoletes RFC-1072 [Jacobson88b] and RFC-1185 [Jacobson90b]. There is no one-line answer to the question: "How fast can TCP go?". There are two separate kinds of issues, performance and reliability, and each depends upon different parameters. We discuss each in turn. 1.1 TCP Performance TCP performance depends not upon the transfer rate itself, but rather upon the product of the transfer rate and the round-trip delay. This "bandwidth*delay product" measures the amount of data that would "fill the pipe"; it is the buffer space required at sender and receiver to obtain maximum throughput on the TCP connection over the path, i.e., the amount of unacknowledged data that TCP must handle in order to keep the pipeline full. TCP performance problems arise when the bandwidth*delay product is large. We refer to an Internet path operating in this region as a Network Working Group Expires August 1997 [Page 2] Internet-Draft TCP Extensions for High Performance February 1997 "long, fat pipe", and a network containing this path as an "LFN" (pronounced "elephan(t)"). High-capacity packet satellite channels (e.g., DARPA's Wideband Net) are LFN's. For example, a DS1-speed satellite channel has a bandwidth*delay product of 10**6 bits or more; this corresponds to 100 outstanding TCP segments of 1200 bytes each. Terrestrial fiber-optical paths will also fall into the LFN class; for example, a cross-country delay of 30 ms at a DS3 bandwidth (45Mbps) also exceeds 10**6 bits. There are three fundamental performance problems with the current TCP over LFN paths: (1) Window Size Limit The TCP header uses a 16 bit field to report the receive window size to the sender. Therefore, the largest window that can be used is 2**16 = 65K bytes. To circumvent this problem, Section 2 of this memo defines a new TCP option, "Window Scale", to allow windows larger than 2**16. This option defines an implicit scale factor, which is used to multiply the window size value found in a TCP header to obtain the true window size. (2) Recovery from Losses Packet losses in an LFN can have a catastrophic effect on throughput. Until recently, properly-operating TCP implementations would cause the data pipeline to drain with every packet loss, and require a slow-start action to recover. Recently, the Fast Retransmit and Fast Recovery algorithms [Jacobson90c] have been introduced. Their combined effect is to recover from one packet loss per window, without draining the pipeline. However, more than one packet loss per window typically results in a retransmission timeout and the resulting pipeline drain and slow start. Expanding the window size to match the capacity of an LFN results in a corresponding increase of the probability of more than one packet per window being dropped. This could have a devastating effect upon the throughput of TCP over an LFN. In addition, if a congestion control mechanism based upon some form of random dropping were introduced into gateways, randomly spaced packet drops would become common, possible increasing the probability of dropping more than one packet per window. Network Working Group Expires August 1997 [Page 3] Internet-Draft TCP Extensions for High Performance February 1997 To generalize the Fast Retransmit/Fast Recovery mechanism to handle multiple packets dropped per window, selective acknowledgments are required. Unlike the normal cumulative acknowledgments of TCP, selective acknowledgments give the sender a complete picture of which segments are queued at the receiver and which have not yet arrived. Some evidence in favor of selective acknowledgments has been published [NBS85], and selective acknowledgments have been included in a number of experimental Internet protocols -- VMTP [Cheriton88], NETBLT [Clark87], and RDP [Velten84], and proposed for OSI TP4 [NBS85]. However, in the non-LFN regime, selective acknowledgments reduce the number of packets retransmitted but do not otherwise improve performance, making their complexity of questionable value. However, selective acknowledgments are expected to become much more important in the LFN regime. RFC-1072 defined a new TCP "SACK" option to send a selective acknowledgment. However, due to important technical issues that had to be worked out concerning both the format and semantics of the SACK option, it was omitted from RFC-1323. SACK has now been published as a separate document, RFC-2018 [Mathis96]. (3) Round-Trip Measurement TCP implements reliable data delivery by retransmitting segments that are not acknowledged within some retransmission timeout (RTO) interval. Accurate dynamic determination of an appropriate RTO is essential to TCP performance. RTO is determined by estimating the mean and variance of the measured round-trip time (RTT), i.e., the time interval between sending a segment and receiving an acknowledgment for it [Jacobson88a]. Section 4 introduces a new TCP option, "Timestamps", and then defines a mechanism using this option that allows nearly every segment, including retransmissions, to be timed at negligible computational cost. We use the mnemonic RTTM (Round Trip Time Measurement) for this mechanism, to distinguish it from other uses of the Timestamps option. 1.2 TCP Reliability Now we turn from performance to reliability. High transfer rate enters TCP performance through the bandwidth*delay product. However, high transfer rate alone can threaten TCP reliability by violating the assumptions behind the TCP mechanism for duplicate detection and sequencing. Network Working Group Expires August 1997 [Page 4] Internet-Draft TCP Extensions for High Performance February 1997 An especially serious kind of error may result from an accidental reuse of TCP sequence numbers in data segments. Suppose that an "old duplicate segment", e.g., a duplicate data segment that was delayed in Internet queues, is delivered to the receiver at the wrong moment, so that its sequence numbers falls somewhere within the current window. There would be no checksum failure to warn of the error, and the result could be an undetected corruption of the data. Reception of an old duplicate ACK segment at the transmitter could be only slightly less serious: it is likely to lock up the connection so that no further progress can be made, forcing an RST on the connection. TCP reliability depends upon the existence of a bound on the lifetime of a segment: the "Maximum Segment Lifetime" or MSL. An MSL is generally required by any reliable transport protocol, since every sequence number field must be finite, and therefore any sequence number may eventually be reused. In the Internet protocol suite, the MSL bound is enforced by an IP-layer mechanism, the "Time-to-Live" or TTL field. Duplication of sequence numbers might happen in either of two ways: (1) Sequence number wrap-around on the current connection A TCP sequence number contains 32 bits. At a high enough transfer rate, the 32-bit sequence space may be "wrapped" (cycled) within the time that a segment is delayed in queues. (2) Earlier incarnation of the connection Suppose that a connection terminates, either by a proper close sequence or due to a host crash, and the same connection (i.e., using the same pair of sockets) is immediately reopened. A delayed segment from the terminated connection could fall within the current window for the new incarnation and be accepted as valid. Duplicates from earlier incarnations, Case (2), are avoided by enforcing the current fixed MSL of the TCP spec, as explained in Section 5.3 and Appendix B. However, case (1), avoiding the reuse of sequence numbers within the same connection, requires an MSL bound that depends upon the transfer rate, and at high enough rates, a new mechanism is required. More specifically, if the maximum effective bandwidth at which TCP is able to transmit over a particular path is B bytes per second, then the following constraint must be satisfied for error-free operation: Network Working Group Expires August 1997 [Page 5] Internet-Draft TCP Extensions for High Performance February 1997 2**31 / B > MSL (secs) [1] The following table shows the value for Twrap = 2**31/B in seconds, for some important values of the bandwidth B: Network B*8 B Twrap bits/sec bytes/sec secs _______ _______ ______ ______ ARPANET 56kbps 7KBps 3*10**5 (~3.6 days) DS1 1.5Mbps 190KBps 10**4 (~3 hours) Ethernet 10Mbps 1.25MBps 1700 (~30 mins) DS3 45Mbps 5.6MBps 380 FDDI 100Mbps 12.5MBps 170 Gigabit 1Gbps 125MBps 17 It is clear that wrap-around of the sequence space is not a problem for 56kbps packet switching or even 10Mbps Ethernets. On the other hand, at DS3 and FDDI speeds, Twrap is comparable to the 2 minute MSL assumed by the TCP specification [Postel81]. Moving towards gigabit speeds, Twrap becomes too small for reliable enforcement by the Internet TTL mechanism. The 16-bit window field of TCP limits the effective bandwidth B to 2**16/RTT, where RTT is the round-trip time in seconds [McKenzie89]. If the RTT is large enough, this limits B to a value that meets the constraint [1] for a large MSL value. For example, consider a transcontinental backbone with an RTT of 60ms (set by the laws of physics). With the bandwidth*delay product limited to 64KB by the TCP window size, B is then limited to 1.1MBps, no matter how high the theoretical transfer rate of the path. This corresponds to cycling the sequence number space in Twrap= 2000 secs, which is safe in today's Internet. It is important to understand that the culprit is not the larger window but rather the high bandwidth. For example, consider a (very large) FDDI LAN with a diameter of 10km. Using the speed of light, we can compute the RTT across the ring as (2*10**4)/(3*10**8) = 67 microseconds, and the delay*bandwidth product is then 833 bytes. A TCP connection across this LAN using a window of only 833 bytes will run at the full 100mbps and can wrap the sequence space in about 3 minutes, very close to the MSL of TCP. Thus, high speed alone can cause a reliability problem with sequence number wrap-around, even without extended windows. Network Working Group Expires August 1997 [Page 6] Internet-Draft TCP Extensions for High Performance February 1997 Watson's Delta-T protocol [Watson81] includes network-layer mechanisms for precise enforcement of an MSL. In contrast, the IP mechanism for MSL enforcement is loosely defined and even more loosely implemented in the Internet. Therefore, it is unwise to depend upon active enforcement of MSL for TCP connections, and it is unrealistic to imagine setting MSL's smaller than the current values (e.g., 120 seconds specified for TCP). A possible fix for the problem of cycling the sequence space would be to increase the size of the TCP sequence number field. For example, the sequence number field (and also the acknowledgment field) could be expanded to 64 bits. This could be done either by changing the TCP header or by means of an additional option. Section 5 presents a different mechanism, which we call PAWS (Protect Against Wrapped Sequence numbers), to extend TCP reliability to transfer rates well beyond the foreseeable upper limit of network bandwidths. PAWS uses the TCP Timestamps option defined in Section 4 to protect against old duplicates from the same connection. 1.3 Using TCP options The extensions defined in this memo all use new TCP options. We must address two possible issues concerning the use of TCP options: (1) compatibility and (2) overhead. We must pay careful attention to compatibility, i.e., to interoperation with existing implementations. The only TCP option defined previously, MSS, may appear only on a SYN segment. Every implementation should (and we expect that most will) ignore unknown options on SYN segments. However, some buggy TCP implementation might be crashed by the first appearance of an option on a non-SYN segment. Therefore, for each of the extensions defined below, TCP options will be sent on non-SYN segments only after an exchange of options on the the SYN segments has indicated that both sides understand the extension. Furthermore, an extension option will be sent in a segment only if the corresponding option was received in the initial segment. A question may be raised about the bandwidth and processing overhead for TCP options. Those options that occur on SYN segments are not likely to cause a performance concern. Opening a TCP connection requires execution of significant special-case code, and the processing of options is unlikely to increase that cost significantly. On the other hand, a Timestamps option may appear in any data or ACK segment, adding 12 bytes to the 20-byte TCP header. We Network Working Group Expires August 1997 [Page 7] Internet-Draft TCP Extensions for High Performance February 1997 believe that the bandwidth saved by reducing unnecessary retransmissions will more than pay for the extra header bandwidth. There is also an issue about the processing overhead for parsing the variable byte-aligned format of options, particularly with a RISC-architecture CPU. Appendix A contains a recommended layout of the options in TCP headers to achieve reasonable data field alignment. In the spirit of Header Prediction, a TCP can quickly test for this layout and if it is verified then use a fast path. Hosts that use this canonical layout will effectively use the options as a set of fixed-format fields appended to the TCP header. However, to retain the philosophical and protocol framework of TCP options, a TCP must be prepared to parse an arbitrary options field, albeit with less efficiency. Finally, we observe that most of the mechanisms defined in this memo are important for LFN's and/or very high-speed networks. For low-speed networks, it might be a performance optimization to NOT use these mechanisms. A TCP vendor concerned about optimal performance over low-speed paths might consider turning these extensions off for low-speed paths, or allow a user or installation manager to disable them. 2. TCP WINDOW SCALE OPTION 2.1 Introduction The window scale extension expands the definition of the TCP window to 32 bits and then uses a scale factor to carry this 32-bit value in the 16-bit Window field of the TCP header (SEG.WND in RFC-793). The scale factor is carried in a new TCP option, Window Scale. This option is sent only in a SYN segment (a segment with the SYN bit on), hence the window scale is fixed in each direction when a connection is opened. (Another design choice would be to specify the window scale in every TCP segment. It would be incorrect to send a window scale option only when the scale factor changed, since a TCP option in an acknowledgement segment will not be delivered reliably (unless the ACK happens to be piggy-backed on data in the other direction). Fixing the scale when the connection is opened has the advantage of lower overhead but the disadvantage that the scale factor cannot be changed during the connection.) The maximum receive window, and therefore the scale factor, is determined by the maximum receive buffer space. In a typical modern implementation, this maximum buffer space is set by default but can be overridden by a user program before a TCP connection is opened. This determines the scale factor, and therefore no new user interface is needed for window scaling. Network Working Group Expires August 1997 [Page 8] Internet-Draft TCP Extensions for High Performance February 1997 2.2 Window Scale Option The three-byte Window Scale option may be sent in a SYN segment by a TCP. It has two purposes: (1) indicate that the TCP is prepared to do both send and receive window scaling, and (2) communicate a scale factor to be applied to its receive window. Thus, a TCP that is prepared to scale windows should send the option, even if its own scale factor is 1. The scale factor is limited to a power of two and encoded logarithmically, so it may be implemented by binary shift operations. TCP Window Scale Option (WSopt): Kind: 3 Length: 3 bytes +---------+---------+---------+ | Kind=3 |Length=3 |shift.cnt| +---------+---------+---------+ This option is an offer, not a promise; both sides must send Window Scale options in their SYN segments to enable window scaling in either direction. If window scaling is enabled, then the TCP that sent this option will right-shift its true receive-window values by 'shift.cnt' bits for transmission in SEG.WND. The value 'shift.cnt' may be zero (offering to scale, while applying a scale factor of 1 to the receive window). This option may be sent in an initial segment (i.e., a segment with the SYN bit on and the ACK bit off). It may also be sent in a segment, but only if a Window Scale option was received in the initial segment. A Window Scale option in a segment without a SYN bit should be ignored. The Window field in a SYN (i.e., a or ) segment itself is never scaled. 2.3 Using the Window Scale Option A model implementation of window scaling is as follows, using the notation of RFC-793 [Postel81]: * All windows are treated as 32-bit quantities for storage in the connection control block and for local calculations. This includes the send-window (SND.WND) and the receive- window (RCV.WND) values, as well as the congestion window. Network Working Group Expires August 1997 [Page 9] Internet-Draft TCP Extensions for High Performance February 1997 * The connection state is augmented by two window shift counts, Snd.Wind.Scale and Rcv.Wind.Scale, to be applied to the incoming and outgoing window fields, respectively. * If a TCP receives a segment containing a Window Scale option, it sends its own Window Scale option in the segment. * The Window Scale option is sent with shift.cnt = R, where R is the value that the TCP would like to use for its receive window. * Upon receiving a SYN segment with a Window Scale option containing shift.cnt = S, a TCP sets Snd.Wind.Scale to S and sets Rcv.Wind.Scale to R; otherwise, it sets both Snd.Wind.Scale and Rcv.Wind.Scale to zero. * The window field (SEG.WND) in the header of every incoming segment, with the exception of SYN segments, is left-shifted by Snd.Wind.Scale bits before updating SND.WND: SND.WND = SEG.WND << Snd.Wind.Scale (assuming the other conditions of RFC793 are met, and using the "C" notation "<<" for left-shift). * The window field (SEG.WND) of every outgoing segment, with the exception of SYN segments, is right-shifted by Rcv.Wind.Scale bits: SEG.WND = RCV.WND >> Rcv.Wind.Scale. TCP determines if a data segment is "old" or "new" by testing whether its sequence number is within 2**31 bytes of the left edge of the window, and if it is not, discarding the data as "old". To insure that new data is never mistakenly considered old and vice- versa, the left edge of the sender's window has to be at most 2**31 away from the right edge of the receiver's window. Similarly with the sender's right edge and receiver's left edge. Since the right and left edges of either the sender's or receiver's window differ by the window size, and since the sender and receiver windows can be out of phase by at most the window size, the above constraints imply that 2 * the max window size must be less than 2**31, or max window < 2**30 Since the max window is 2**S (where S is the scaling shift count) times at most 2**16 - 1 (the maximum unscaled window), the maximum Network Working Group Expires August 1997 [Page 10] Internet-Draft TCP Extensions for High Performance February 1997 window is guaranteed to be < 2*30 if S <= 14. Thus, the shift count must be limited to 14 (which allows windows of 2**30 = 1 Gbyte). If a Window Scale option is received with a shift.cnt value exceeding 14, the TCP should log the error but use 14 instead of the specified value. The scale factor applies only to the Window field as transmitted in the TCP header; each TCP using extended windows will maintain the window values locally as 32-bit numbers. For example, the "congestion window" computed by Slow Start and Congestion Avoidance is not affected by the scale factor, so window scaling will not introduce quantization into the congestion window. 3. RTTM: ROUND-TRIP TIME MEASUREMENT 3.1 Introduction Accurate and current RTT estimates are necessary to adapt to changing traffic conditions and to avoid an instability known as "congestion collapse" [Nagle84] in a busy network. However, accurate measurement of RTT may be difficult both in theory and in implementation. Many TCP implementations base their RTT measurements upon a sample of one packet per window or less. While this yields an adequate approximation to the RTT for small windows, it results in an unacceptably poor RTT estimate for an LFN. If we look at RTT estimation as a signal processing problem (which it is), a data signal at some frequency, the packet rate, is being sampled at a lower frequency, the window rate. This lower sampling frequency violates Nyquist's criteria and may therefore introduce "aliasing" artifacts into the estimated RTT [Hamming77]. A good RTT estimator with a conservative retransmission timeout calculation can tolerate aliasing when the sampling frequency is "close" to the data frequency. For example, with a window of 8 packets, the sample rate is 1/8 the data frequency -- less than an order of magnitude different. However, when the window is tens or hundreds of packets, the RTT estimator may be seriously in error, resulting in spurious retransmissions. If there are dropped packets, the problem becomes worse. Zhang [Zhang86], Jain [Jain86] and Karn [Karn87] have shown that it is not possible to accumulate reliable RTT estimates if retransmitted segments are included in the estimate. Since a full window of data will have been transmitted prior to a retransmission, all of the segments in that window will have to be ACKed before the next RTT sample can be taken. This means at least an additional window's worth of time between RTT measurements and, as the error rate approaches one per window of data (e.g., 10**-6 errors per Network Working Group Expires August 1997 [Page 11] Internet-Draft TCP Extensions for High Performance February 1997 bit for the Wideband satellite network), it becomes effectively impossible to obtain a valid RTT measurement. A solution to these problems, which actually simplifies the sender substantially, is as follows: using TCP options, the sender places a timestamp in each data segment, and the receiver reflects these timestamps back in ACK segments. Then a single subtract gives the sender an accurate RTT measurement for every ACK segment (which will correspond to every other data segment, with a sensible receiver). We call this the RTTM (Round-Trip Time Measurement) mechanism. It is vitally important to use the RTTM mechanism with big windows; otherwise, the door is opened to some dangerous instabilities due to aliasing. Furthermore, the option is probably useful for all TCP's, since it simplifies the sender. 3.2 TCP Timestamps Option TCP is a symmetric protocol, allowing data to be sent at any time in either direction, and therefore timestamp echoing may occur in either direction. For simplicity and symmetry, we specify that timestamps always be sent and echoed in both directions. For efficiency, we combine the timestamp and timestamp reply fields into a single TCP Timestamps Option. TCP Timestamps Option (TSopt): Kind: 8 Length: 10 bytes +-------+-------+---------------------+---------------------+ |Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)| +-------+-------+---------------------+---------------------+ 1 1 4 4 The Timestamps option carries two four-byte timestamp fields. The Timestamp Value field (TSval) contains the current value of the timestamp clock of the TCP sending the option. The Timestamp Echo Reply field (TSecr) is only valid if the ACK bit is set in the TCP header; if it is valid, it echos a timestamp value that was sent by the remote TCP in the TSval field of a Timestamps option. When TSecr is not valid, its value must be zero. The TSecr value will generally be from the most recent Timestamp option that was received; however, there are exceptions that are explained below. A TCP may send the Timestamps option (TSopt) in an initial Network Working Group Expires August 1997 [Page 12] Internet-Draft TCP Extensions for High Performance February 1997 segment (i.e., a segment containing a SYN bit and no ACK bit), and may send a TSopt in other segments only if it received a TSopt in the initial segment for the connection. 3.3 The RTTM Mechanism RTTM places a Timestamps option in every segment, with a TSval that is obtained from a (virtual) "timestamp clock". Values of this clock values must be at least approximately proportional to real time, in order to measure actual RTT. These TSval values are echoed in TSecr values in the reverse direction. The difference between a received TSecr value and the current timestamp clock value provides an RTT measurement. When timestamps are used, every segment that is received will contain a TSecr value; however, these values cannot all be used to update the measured RTT. The following example illustrates why. It shows a one-way data flow with segments arriving in sequence without loss. Here A, B, C... represent data blocks occupying successive blocks of sequence numbers, and ACK(A),... represent the corresponding cumulative acknowledgments. The two timestamp fields of the Timestamps option are shown symbolically as . Each TSecr field contains the value most recently received in a TSval field; these echoed values. labelled "TS.Recent", are shown in parentheses. TCP A TCP B (TS.Recent) (TS.Recent) 1. (120) ---> (1) 2. (125) <--- (1) 3. (125) ---> (6) 4. (130) <--- (6) . . . ( Pause for 60 timestamp clock ticks ) . . . . 5. (130) ---> (1) 6. (125) <--- (1) 4. (127) ---> ... 5. ... <--- (5) Network Working Group Expires August 1997 [Page 13] Internet-Draft TCP Extensions for High Performance February 1997 TCP A TCP B ------> <---- ------> <---- . . . . . . . . . . . . . . . . . . . . . . ------> <---- (etc) The dotted line marks a pause (60 time units long) in which A had nothing to send. Note that this pause inflates the RTT which B could infer from receiving TSecr=131 in data segment C. Thus, in one-way data flows, RTTM in the reverse direction measures a value that is inflated by gaps in sending data. However, the following rule prevents a resulting inflation of the measured RTT: RTTM Rule: A TSecr value received in a segment is used to update the averaged RTT measurement only if the segment acknowledges some new data, i.e., only if it advances the left edge of the send window. Since TCP B is not sending data, the data segment C does not acknowledge any new data when it arrives at B. Thus, the inflated RTTM measurement is not used to update B's RTTM measurement. 3.4 Which Timestamp to Echo If more than one Timestamps option is received before a reply segment is sent, the TCP must choose only one of the TSvals to echo, ignoring the others. To minimize the state kept in the receiver (i.e., the number of unprocessed TSvals), the receiver should be required to retain at most one timestamp in the connection control block. There are three situations to consider: (A) Delayed ACKs. Network Working Group Expires August 1997 [Page 14] Internet-Draft TCP Extensions for High Performance February 1997 Many TCP's acknowledge only every Kth segment out of a group of segments arriving within a short time interval; this policy is known generally as "delayed ACKs". The data-sender TCP must measure the effective RTT, including the additional time due to delayed ACKs, or else it will retransmit unnecessarily. Thus, when delayed ACKs are in use, the receiver should reply with the TSval field from the earliest unacknowledged segment. (B) A hole in the sequence space (segment(s) have been lost). The sender will continue sending until the window is filled, and the receiver may be generating ACKs as these out-of-order segments arrive (e.g., to aid "fast retransmit"). The lost segment is probably a sign of congestion, and in that situation the sender should be conservative about retransmission. Furthermore, it is better to overestimate than underestimate the RTT. An ACK for an out-of-order segment should therefore contain the timestamp from the most recent segment that advanced the window. The same situation occurs if segments are re-ordered by the network. (C) A filled hole in the sequence space. The segment that fills the hole represents the most recent measurement of the network characteristics. On the other hand, an RTT computed from an earlier segment would probably include the sender's retransmit time-out, badly biasing the sender's average RTT estimate. Thus, the timestamp from the latest segment (which filled the hole) must be echoed. An algorithm that covers all three cases is described in the following rules for Timestamps option processing on a synchronized connection: (1) The connection state is augmented with two 32-bit slots: TS.Recent holds a timestamp to be echoed in TSecr whenever a segment is sent, and Last.ACK.sent holds the ACK field from the last segment sent. Last.ACK.sent will equal RCV.NXT except when ACKs have been delayed. (2) If: SEG.TSval >= TSrecent and SEG.SEQ <= Last.ACK.sent then SEG.TSval is copied to TS.Recent; otherwise, it is ignored. Network Working Group Expires August 1997 [Page 15] Internet-Draft TCP Extensions for High Performance February 1997 (3) When a TSopt is sent, its TSecr field is set to the current TS.Recent value. The following examples illustrate these rules. Here A, B, C... represent data segments occupying successive blocks of sequence numbers, and ACK(A),... represent the corresponding acknowledgment segments. Note that ACK(A) has the same sequence number as B. We show only one direction of timestamp echoing, for clarity. o Packets arrive in sequence, and some of the ACKs are delayed. By Case (A), the timestamp from the oldest unacknowledged segment is echoed. TS.Recent -------------------> 1 -------------------> 1 -------------------> 1 <---- (etc) o Packets arrive out of order, and every packet is acknowledged. By Case (B), the timestamp from the last segment that advanced the left window edge is echoed, until the missing segment arrives; it is echoed according to Case (C). The same sequence would occur if segments B and D were lost and retransmitted.. Network Working Group Expires August 1997 [Page 16] Internet-Draft TCP Extensions for High Performance February 1997 TS.Recent -------------------> 1 <---- 1 -------------------> 1 <---- 1 -------------------> 2 <---- 2 -------------------> 2 <---- 2 -------------------> 4 <---- (etc) 4. PAWS: PROTECT AGAINST WRAPPED SEQUENCE NUMBERS 4.1 Introduction Section 4.2 describes a simple mechanism to reject old duplicate segments that might corrupt an open TCP connection; we call this mechanism PAWS (Protect Against Wrapped Sequence numbers). PAWS operates within a single TCP connection, using state that is saved in the connection control block. Section 4.3 and Appendix C discuss the implications of the PAWS mechanism for avoiding old duplicates from previous incarnations of the same connection. 4.2 The PAWS Mechanism PAWS uses the same TCP Timestamps option as the RTTM mechanism described earlier, and assumes that every received TCP segment (including data and ACK segments) contains a timestamp SEG.TSval whose values are monotone non-decreasing in time. The basic idea is that a segment can be discarded as an old duplicate if it is received with a timestamp SEG.TSval less than some timestamp recently received on this connection. In both the PAWS and the RTTM mechanism, the "timestamps" are 32-bit unsigned integers in a modular 32-bit space. Thus, "less Network Working Group Expires August 1997 [Page 17] Internet-Draft TCP Extensions for High Performance February 1997 than" is defined the same way it is for TCP sequence numbers, and the same implementation techniques apply. If s and t are timestamp values, s < t if 0 < (t - s) < 2**31, computed in unsigned 32-bit arithmetic. The choice of incoming timestamps to be saved for this comparison must guarantee a value that is monotone increasing. For example, we might save the timestamp from the segment that last advanced the left edge of the receive window, i.e., the most recent in- sequence segment. Instead, we choose the value TS.Recent introduced in Section 3.4 for the RTTM mechanism, since using a common value for both PAWS and RTTM simplifies the implementation of both. As Section 3.4 explained, TS.Recent differs from the timestamp from the last in-sequence segment only in the case of delayed ACKs, and therefore by less than one window. Either choice will therefore protect against sequence number wrap-around. RTTM was specified in a symmetrical manner, so that TSval timestamps are carried in both data and ACK segments and are echoed in TSecr fields carried in returning ACK or data segments. PAWS submits all incoming segments to the same test, and therefore protects against duplicate ACK segments as well as data segments. (An alternative un-symmetric algorithm would protect against old duplicate ACKs: the sender of data would reject incoming ACK segments whose TSecr values were less than the TSecr saved from the last segment whose ACK field advanced the left edge of the send window. This algorithm was deemed to lack economy of mechanism and symmetry.) TSval timestamps sent on {SYN} and {SYN,ACK} segments are used to initialize PAWS. PAWS protects against old duplicate non-SYN segments, and duplicate SYN segments received while there is a synchronized connection. Duplicate {SYN} and {SYN,ACK} segments received when there is no connection will be discarded by the normal 3-way handshake and sequence number checks of TCP. It is recommended that RST segments NOT carry timestamps, and that RST segments be acceptable regardless of their timestamp. Old duplicate RST segments should be exceedingly unlikely, and their cleanup function should take precedence over timestamps. 4.2.1 Basic PAWS Algorithm The PAWS algorithm requires the following processing to be performed on all incoming segments for a synchronized connection: R1) If there is a Timestamps option in the arriving segment and SEG.TSval < TS.Recent and if TS.Recent is valid (see later discussion), then treat the arriving segment as not Network Working Group Expires August 1997 [Page 18] Internet-Draft TCP Extensions for High Performance February 1997 acceptable: Send an acknowledgement in reply as specified in RFC-793 page 69 and drop the segment. Note: it is necessary to send an ACK segment in order to retain TCP's mechanisms for detecting and recovering from half-open connections. For example, see Figure 10 of RFC-793. R2) If the segment is outside the window, reject it (normal TCP processing) R3) If an arriving segment satisfies: SEG.SEQ <= Last.ACK.sent (see Section 3.4), then record its timestamp in TS.Recent. R4) If an arriving segment is in-sequence (i.e., at the left window edge), then accept it normally. R5) Otherwise, treat the segment as a normal in-window, out- of-sequence TCP segment (e.g., queue it for later delivery to the user). Steps R2, R4, and R5 are the normal TCP processing steps specified by RFC-793. It is important to note that the timestamp is checked only when a segment first arrives at the receiver, regardless of whether it is in-sequence or it must be queued for later delivery. Consider the following example. Suppose the segment sequence: A.1, B.1, C.1, ..., Z.1 has been sent, where the letter indicates the sequence number and the digit represents the timestamp. Suppose also that segment B.1 has been lost. The timestamp in TS.TStamp is 1 (from A.1), so C.1, ..., Z.1 are considered acceptable and are queued. When B is retransmitted as segment B.2 (using the latest timestamp), it fills the hole and causes all the segments through Z to be acknowledged and passed to the user. The timestamps of the queued segments are *not* inspected again at this time, since they have already been accepted. When B.2 is accepted, TS.Stamp is set to 2. This rule allows reasonable performance under loss. A full window of data is in transit at all times, and after a loss a full window less one packet will show up out-of-sequence to be queued at the receiver (e.g., up to ~2**30 bytes of data); the timestamp option must not result in discarding this data. Network Working Group Expires August 1997 [Page 19] Internet-Draft TCP Extensions for High Performance February 1997 In certain unlikely circumstances, the algorithm of rules R1-R4 could lead to discarding some segments unnecessarily, as shown in the following example: Suppose again that segments: A.1, B.1, C.1, ..., Z.1 have been sent in sequence and that segment B.1 has been lost. Furthermore, suppose delivery of some of C.1, ... Z.1 is delayed until AFTER the retransmission B.2 arrives at the receiver. These delayed segments will be discarded unnecessarily when they do arrive, since their timestamps are now out of date. This case is very unlikely to occur. If the retransmission was triggered by a timeout, some of the segments C.1, ... Z.1 must have been delayed longer than the RTO time. This is presumably an unlikely event, or there would be many spurious timeouts and retransmissions. If B's retransmission was triggered by the "fast retransmit" algorithm, i.e., by duplicate ACKs, then the queued segments that caused these ACKs must have been received already. Even if a segment were delayed past the RTO, the Fast Retransmit mechanism [Jacobson90c] will cause the delayed packets to be retransmitted at the same time as B.2, avoiding an extra RTT and therefore causing a very small performance penalty. We know of no case with a significant probability of occurrence in which timestamps will cause performance degradation by unnecessarily discarding segments. 4.2.2 Timestamp Clock It is important to understand that the PAWS algorithm does not require clock synchronization between sender and receiver. The sender's timestamp clock is used to stamp the segments, and the sender uses the echoed timestamp to measure RTT's. However, the receiver treats the timestamp as simply a monotone- increasing serial number, without any necessary connection to its clock. From the receiver's viewpoint, the timestamp is acting as a logical extension of the high-order bits of the sequence number. The receiver algorithm does place some requirements on the frequency of the timestamp clock. (a) The timestamp clock must not be "too slow". It must tick at least once for each 2**31 bytes sent. In fact, in order to be useful to the sender for round trip Network Working Group Expires August 1997 [Page 20] Internet-Draft TCP Extensions for High Performance February 1997 timing, the clock should tick at least once per window's worth of data, and even with the RFC-1072 window extension, 2**31 bytes must be at least two windows. To make this more quantitative, any clock faster than 1 tick/sec will reject old duplicate segments for link speeds of ~8 Gbps. A 1ms timestamp clock will work at link speeds up to 8 Tbps (8*10**12) bps! (b) The timestamp clock must not be "too fast". Its recycling time must be greater than MSL seconds. Since the clock (timestamp) is 32 bits and the worst-case MSL is 255 seconds, the maximum acceptable clock frequency is one tick every 59 ns. However, it is desirable to establish a much longer recycle period, in order to handle outdated timestamps on idle connections (see Section 4.2.3), and to relax the MSL requirement for preventing sequence number wrap-around. With a 1 ms timestamp clock, the 32-bit timestamp will wrap its sign bit in 24.8 days. Thus, it will reject old duplicates on the same connection if MSL is 24.8 days or less. This appears to be a very safe figure; an MSL of 24.8 days or longer can probably be assumed by the gateway system without requiring precise MSL enforcement by the TTL value in the IP layer. Based upon these considerations, we choose a timestamp clock frequency in the range 1 ms to 1 sec per tick. This range also matches the requirements of the RTTM mechanism, which does not need much more resolution than the granularity of the retransmit timer, e.g., tens or hundreds of milliseconds. The PAWS mechanism also puts a strong monotonicity requirement on the sender's timestamp clock. The method of implementation of the timestamp clock to meet this requirement depends upon the system hardware and software. * Some hosts have a hardware clock that is guaranteed to be monotonic between hardware resets. * A clock interrupt may be used to simply increment a binary integer by 1 periodically. * The timestamp clock may be derived from a system clock that is subject to being abruptly changed, by adding a variable offset value. This offset is initialized to zero. When a new timestamp clock value is needed, the offset can be adjusted as necessary to make the new value Network Working Group Expires August 1997 [Page 21] Internet-Draft TCP Extensions for High Performance February 1997 equal to or larger than the previous value (which was saved for this purpose). 4.2.3 Outdated Timestamps If a connection remains idle long enough for the timestamp clock of the other TCP to wrap its sign bit, then the value saved in TS.Recent will become too old; as a result, the PAWS mechanism will cause all subsequent segments to be rejected, freezing the connection (until the timestamp clock wraps its sign bit again). With the chosen range of timestamp clock frequencies (1 sec to 1 ms), the time to wrap the sign bit will be between 24.8 days and 24800 days. A TCP connection that is idle for more than 24 days and then comes to life is exceedingly unusual. However, it is undesirable in principle to place any limitation on TCP connection lifetimes. We therefore require that an implementation of PAWS include a mechanism to "invalidate" the TS.Recent value when a connection is idle for more than 24 days. (An alternative solution to the problem of outdated timestamps would be to send keepalive segments at a very low rate, but still more often than the wrap-around time for timestamps, e.g., once a day. This would impose negligible overhead. However, the TCP specification has never included keepalives, so the solution based upon invalidation was chosen.) Note that a TCP does not know the frequency, and therefore, the wraparound time, of the other TCP, so it must assume the worst. The validity of TS.Recent needs to be checked only if the basic PAWS timestamp check fails, i.e., only if SEG.TSval < TS.Recent. If TS.Recent is found to be invalid, then the segment is accepted, regardless of the failure of the timestamp check, and rule R3 updates TS.Recent with the TSval from the new segment. To detect how long the connection has been idle, the TCP may update a clock or timestamp value associated with the connection whenever TS.Recent is updated, for example. The details will be implementation-dependent. 4.2.4 Header Prediction "Header prediction" [Jacobson90a] is a high-performance transport protocol implementation technique that is most important for high-speed links. This technique optimizes the code for the most common case, receiving a segment correctly Network Working Group Expires August 1997 [Page 22] Internet-Draft TCP Extensions for High Performance February 1997 and in order. Using header prediction, the receiver asks the question, "Is this segment the next in sequence?" This question can be answered in fewer machine instructions than the question, "Is this segment within the window?" Adding header prediction to our timestamp procedure leads to the following recommended sequence for processing an arriving TCP segment: H1) Check timestamp (same as step R1 above) H2) Do header prediction: if segment is next in sequence and if there are no special conditions requiring additional processing, accept the segment, record its timestamp, and skip H3. H3) Process the segment normally, as specified in RFC-793. This includes dropping segments that are outside the window and possibly sending acknowledgments, and queueing in-window, out-of-sequence segments. Another possibility would be to interchange steps H1 and H2, i.e., to perform the header prediction step H2 FIRST, and perform H1 and H3 only when header prediction fails. This could be a performance improvement, since the timestamp check in step H1 is very unlikely to fail, and it requires interval arithmetic on a finite field, a relatively expensive operation. To perform this check on every single segment is contrary to the philosophy of header prediction. We believe that this change might reduce CPU time for TCP protocol processing by up to 5-10% on high-speed networks. However, putting H2 first would create a hazard: a segment from 2**32 bytes in the past might arrive at exactly the wrong time and be accepted mistakenly by the header-prediction step. The following reasoning has been introduced [Jacobson90b] to show that the probability of this failure is negligible. If all segments are equally likely to show up as old duplicates, then the probability of an old duplicate exactly matching the left window edge is the maximum segment size (MSS) divided by the size of the sequence space. This ratio must be less than 2**-16, since MSS must be < 2**16; for example, it will be (2**12)/(2**32) = 2**-20 for an FDDI link. However, the older a segment is, the less likely it is to be retained in the Internet, and under any reasonable model of segment lifetime the probability of an old duplicate exactly at the left window edge must be much smaller than 2**-16. Network Working Group Expires August 1997 [Page 23] Internet-Draft TCP Extensions for High Performance February 1997 The 16 bit TCP checksum also allows a basic unreliability of one part in 2**16. A protocol mechanism whose reliability exceeds the reliability of the TCP checksum should be considered "good enough", i.e., it won't contribute significantly to the overall error rate. We therefore believe we can ignore the problem of an old duplicate being accepted by doing header prediction before checking the timestamp. However, this probabilistic argument is not universally accepted, and the consensus at present is that the performance gain does not justify the hazard in the general case. It is therefore recommended that H2 follow H1. 4.3. Duplicates from Earlier Incarnations of Connection The PAWS mechanism protects against errors due to sequence number wrap-around on high-speed connection. Segments from an earlier incarnation of the same connection are also a potential cause of old duplicate errors. In both cases, the TCP mechanisms to prevent such errors depend upon the enforcement of a maximum segment lifetime (MSL) by the Internet (IP) layer (see Appendix of RFC-1185 for a detailed discussion). Unlike the case of sequence space wrap-around, the MSL required to prevent old duplicate errors from earlier incarnations does not depend upon the transfer rate. If the IP layer enforces the recommended 2 minute MSL of TCP, and if the TCP rules are followed, TCP connections will be safe from earlier incarnations, no matter how high the network speed. Thus, the PAWS mechanism is not required for this case. We may still ask whether the PAWS mechanism can provide additional security against old duplicates from earlier connections, allowing us to relax the enforcement of MSL by the IP layer. Appendix B explores this question, showing that further assumptions and/or mechanisms are required, beyond those of PAWS. This is not part of the current extension. 5. CONCLUSIONS AND ACKNOWLEDGMENTS This memo presented a set of extensions to TCP to provide efficient operation over large-bandwidth*delay-product paths and reliable operation over very high-speed paths. These extensions are designed to provide compatible interworking with TCP's that do not implement the extensions. These mechanisms are implemented using new TCP options for scaled windows and timestamps. The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect Network Working Group Expires August 1997 [Page 24] Internet-Draft TCP Extensions for High Performance February 1997 Against Wrapped Sequences). The Window Scale option was originally suggested by Mike St. Johns of USAF/DCA. The present form of the option was suggested by Mike Karels of UC Berkeley in response to a more cumbersome scheme defined by Van Jacobson. Lixia Zhang helped formulate the PAWS mechanism description in RFC-1185. Finally, much of this work originated as the result of discussions within the End-to-End Task Force on the theoretical limitations of transport protocols in general and TCP in particular. More recently, task force members and other on the end2end-interest list have made valuable contributions by pointing out flaws in the algorithms and the documentation. The authors are grateful for all these contributions. 6. REFERENCES [Braden89] Braden, R., editor, "Requirements for Internet Hosts -- Communication Layers", RFC 1122, October, 1989 [Clark87] Clark, D., Lambert, M., and L. Zhang, "NETBLT: A Bulk Data Transfer Protocol", RFC 998, MIT, March 1987. [Garlick77] Garlick, L., R. Rom, and J. Postel, "Issues in Reliable Host-to-Host Protocols", Proc. Second Berkeley Workshop on Distributed Data Management and Computer Networks, May 1977. [Hamming77] Hamming, R., "Digital Filters", ISBN 0-13-212571-4, Prentice Hall, Englewood Cliffs, N.J., 1977. [Cheriton88] Cheriton, D., "VMTP: Versatile Message Transaction Protocol", RFC 1045, Stanford University, February 1988. [Jacobson88a] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM '88, Stanford, CA., August 1988. [Jacobson88b] Jacobson, V., and R. Braden, "TCP Extensions for Long-Delay Paths", RFC-1072, LBL and USC/Information Sciences Institute, October 1988. [Jacobson90a] Jacobson, V., "4BSD Header Prediction", ACM Computer Communication Review, April 1990. [Jacobson90b] Jacobson, V., Braden, R., and Zhang, L., "TCP Extension for High-Speed Paths", RFC-1185, LBL and USC/Information Sciences Institute, October 1990. [Jacobson90c] Jacobson, V., "Modified TCP congestion avoidance algorithm", Message to end2end-interest mailing list, April 1990. Network Working Group Expires August 1997 [Page 25] Internet-Draft TCP Extensions for High Performance February 1997 [Jain86] Jain, R., "Divergence of Timeout Algorithms for Packet Retransmissions", Proc. Fifth Phoenix Conf. on Comp. and Comm., Scottsdale, Arizona, March 1986. [Karn87] Karn, P. and C. Partridge, "Estimating Round-Trip Times in Reliable Transport Protocols", Proc. SIGCOMM '87, Stowe, VT, August 1987. [Mathis96] Mathis, M., Mahdavi, J., Floyd, S., and Romanow, A., "TCP Selective Acknowledgment Options", RFC 2018, October, 1996. [McKenzie89] McKenzie, A., "A Problem with the TCP Big Window Option", RFC 1110, BBN STC, August 1989. [Nagle84] Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC 896, FACC, January 1984. [NBS85] Colella, R., Aronoff, R., and K. Mills, "Performance Improvements for ISO Transport", Ninth Data Comm Symposium, published in ACM SIGCOMM Comp Comm Review, vol. 15, no. 5, September 1985. [Postel81] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981. [Postel83] Postel, J., "The TCP Maximum Segment Size and Related Topics", RFC 879, ISI, November 1983. [Velten84] Velten, D., Hinden, R., and J. Sax, "Reliable Data Protocol", RFC 908, BBN, July 1984. [Watson81] Watson, R., "Timer-based Mechanisms in Reliable Transport Protocol Connection Management", Computer Networks, Vol. 5, 1981. [Zhang86] Zhang, L., "Why TCP Timers Don't Work Well", Proc. SIGCOMM '86, Stowe, Vt., August 1986. Network Working Group Expires August 1997 [Page 26] Internet-Draft TCP Extensions for High Performance February 1997 APPENDIX A: IMPLEMENTATION SUGGESTIONS The following layouts are recommended for sending options on non-SYN segments, to achieve maximum feasible alignment of 32-bit and 64-bit machines. +--------+--------+--------+--------+ | NOP | NOP | TSopt | 10 | +--------+--------+--------+--------+ | TSval timestamp | +--------+--------+--------+--------+ | TSecr timestamp | +--------+--------+--------+--------+ APPENDIX B: DUPLICATES FROM EARLIER CONNECTION INCARNATIONS There are two cases to be considered: (1) a system crashing (and losing connection state) and restarting, and (2) the same connection being closed and reopened without a loss of host state. These will be described in the following two sections. B.1 System Crash with Loss of State TCP's quiet time of one MSL upon system startup handles the loss of connection state in a system crash/restart. For an explanation, see for example "When to Keep Quiet" in the TCP protocol specification [Postel81]. The MSL that is required here does not depend upon the transfer speed. The current TCP MSL of 2 minutes seems acceptable as an operational compromise, as many host systems take this long to boot after a crash. However, the timestamp option may be used to ease the MSL requirements (or to provide additional security against data corruption). If timestamps are being used and if the timestamp clock can be guaranteed to be monotonic over a system crash/restart, i.e., if the first value of the sender's timestamp clock after a crash/restart can be guaranteed to be greater than the last value before the restart, then a quiet time will be unnecessary. To dispense totally with the quiet time would require that the host clock be synchronized to a time source that is stable over the crash/restart period, with an accuracy of one timestamp clock tick or better. We can back off from this strict requirement to take advantage of approximate clock synchronization. Suppose that the clock is always re-synchronized to within N timestamp clock Network Working Group Expires August 1997 [Page 27] Internet-Draft TCP Extensions for High Performance February 1997 ticks and that booting (extended with a quiet time, if necessary) takes more than N ticks. This will guarantee monotonicity of the timestamps, which can then be used to reject old duplicates even without an enforced MSL. B.2 Closing and Reopening a Connection When a TCP connection is closed, a delay of 2*MSL in TIME-WAIT state ties up the socket pair for 4 minutes (see Section 3.5 of [Postel81]. Applications built upon TCP that close one connection and open a new one (e.g., an FTP data transfer connection using Stream mode) must choose a new socket pair each time. The TIME- WAIT delay serves two different purposes: (a) Implement the full-duplex reliable close handshake of TCP. The proper time to delay the final close step is not really related to the MSL; it depends instead upon the RTO for the FIN segments and therefore upon the RTT of the path. (It could be argued that the side that is sending a FIN knows what degree of reliability it needs, and therefore it should be able to determine the length of the TIME-WAIT delay for the FIN's recipient. This could be accomplished with an appropriate TCP option in FIN segments.) Although there is no formal upper-bound on RTT, common network engineering practice makes an RTT greater than 1 minute very unlikely. Thus, the 4 minute delay in TIME-WAIT state works satisfactorily to provide a reliable full-duplex TCP close. Note again that this is independent of MSL enforcement and network speed. The TIME-WAIT state could cause an indirect performance problem if an application needed to repeatedly close one connection and open another at a very high frequency, since the number of available TCP ports on a host is less than 2**16. However, high network speeds are not the major contributor to this problem; the RTT is the limiting factor in how quickly connections can be opened and closed. Therefore, this problem will be no worse at high transfer speeds. (b) Allow old duplicate segments to expire. To replace this function of TIME-WAIT state, a mechanism would have to operate across connections. PAWS is defined strictly within a single connection; the last timestamp is TS.Recent is kept in the connection control block, and discarded when a connection is closed. Network Working Group Expires August 1997 [Page 28] Internet-Draft TCP Extensions for High Performance February 1997 An additional mechanism could be added to the TCP, a per-host cache of the last timestamp received from any connection. This value could then be used in the PAWS mechanism to reject old duplicate segments from earlier incarnations of the connection, if the timestamp clock can be guaranteed to have ticked at least once since the old connection was open. This would require that the TIME-WAIT delay plus the RTT together must be at least one tick of the sender's timestamp clock. Such an extension is not part of the proposal of this RFC. Note that this is a variant on the mechanism proposed by Garlick, Rom, and Postel [Garlick77], which required each host to maintain connection records containing the highest sequence numbers on every connection. Using timestamps instead, it is only necessary to keep one quantity per remote host, regardless of the number of simultaneous connections to that host. Network Working Group Expires August 1997 [Page 29] Internet-Draft TCP Extensions for High Performance February 1997 APPENDIX C: CHANGES FROM RFC-1072, RFC-1185, RFC-1323 The protocol extensions defined in RFC-1323 document differ in several important ways from those defined in RFC-1072 and RFC-1185. (a) SACK has been split off into a separate document, RFC 2018 [Mathis96]. (b) The detailed rules for sending timestamp replies (see Section 3.4) differ in important ways. The earlier rules could result in an under-estimate of the RTT in certain cases (packets dropped or out of order). (c) The same value TS.Recent is now shared by the two distinct mechanisms RTTM and PAWS. This simplification became possible because of change (b). (d) An ambiguity in RFC-1185 was resolved in favor of putting timestamps on ACK as well as data segments. This supports the symmetry of the underlying TCP protocol. (e) The echo and echo reply options of RFC-1072 were combined into a single Timestamps option, to reflect the symmetry and to simplify processing. (f) The problem of outdated timestamps on long-idle connections, discussed in Section 4.2.2, was realized and resolved. (g) RFC-1185 recommended that header prediction take precedence over the timestamp check. Based upon some scepticism about the probabilistic arguments given in Section 4.2.4, it was decided to recommend that the timestamp check be performed first. (h) The spec was modified so that the extended options will be sent on segments only when they are received in the corresponding segments. This provides the most conservative possible conditions for interoperation with implementations without the extensions. In addition to these substantive changes, the present RFC attempts to specify the algorithms unambiguously by presenting modifications to the Event Processing rules of RFC-793; see Appendix F. There are additional changes in this document from RFC-1323. These changes are: (a) The description of which TSecr values can be used to update the measured RTT has been clarified. Specifically, with Timestamps, the Karn algorithm [Karn87] is disabled. The Karn algorithm Network Working Group Expires August 1997 [Page 30] Internet-Draft TCP Extensions for High Performance February 1997 disables all RTT measurements during retransmission, since it is ambiguous whether the ACK is is for the original packet, or the retransmitted packet. With Timestamps, that ambiguity is removed since the TSecr in the ACK will contain the TSval from which ever data packet made it to the destination. (b) In RFC-1323, section 3.4, step (2) of the algorithm to control which timestamp is echoed was incorrect in two regards: (1) It failed to update TSrecent for a retransmitted segment that resulted from a lost ACK. (2) It failed if SEG.LEN = 0. In the new algorithm, the case of SEG.TSval = TSrecent is included for consistency with the PAWS test. (c) One correction was made to the Event Processing Summary in Appendix F. In SEND CALL/ESTABLISHED STATE, RCV.WND is used to fill in the SEG.WND value, not SND.WND. (d) New pseudo-code summary has been added in Appendix E. (e) A description was added describing the interaction between TCP options and the TCP MSS option in Appendix G. Network Working Group Expires August 1997 [Page 31] Internet-Draft TCP Extensions for High Performance February 1997 APPENDIX D: SUMMARY OF NOTATION The following notation has been used in this document. Options WSopt: TCP Window Scale Option TSopt: TCP Timestamps Option Option Fields shift.cnt: Window scale byte in WSopt. TSval: 32-bit Timestamp Value field in TSopt. TSecr: 32-bit Timestamp Reply field in TSopt. Option Fields in Current Segment SEG.TSval: TSval field from TSopt in current segment. SEG.TSecr: TSecr field from TSopt in current segment. SEG.WSopt: 8-bit value in WSopt Clock Values my.TSclock: Local source of 32-bit timestamp values my.TSclock.rate: Period of my.TSclock (1 ms to 1 sec). Per-Connection State Variables TS.Recent: Latest received Timestamp Last.ACK.sent: Last ACK field sent Snd.TS.OK: 1-bit flag Snd.WS.OK: 1-bit flag Rcv.Wind.Scale: Receive window scale power Snd.Wind.Scale: Send window scale power Start.Time: my.TSclock value when segment being timed was sent (used by pre-1323 code). Procedure Update_SRTT( m ) Procedure to update the smoothed RTT and RTT variance estimates, using the rules of [Jacobson88], given m, a new RTT measurement. Network Working Group Expires August 1997 [Page 32] Internet-Draft TCP Extensions for High Performance February 1997 APPENDIX E: PSEUDO-CODE SUMMARY Create new TCB => { Rcv.wind.scale = MIN( 14, MAX( 0, floor(log2(receive buffer space)) - 15 ) ); Snd.wind.scale = 0; Last.ACK.sent = 0; Snd.TS.OK = Snd.WS.OK = FALSE; } Send initial {SYN} segment => { SEG.WND = MIN( RCV.WND, 65535 ); Include in segment: TSopt(TSval=my.TSclock, TCecr=0); Include in segment: WSopt = Rcv.wind.scale; } Send {SYN, ACK} segment => { SEG.ACK = Last.ACK.sent = RCV.NXT; SEG.WND = MIN( RCV.WND, 65535 ); if (Snd.TS.OK) then Include in segment: TSopt(TSval=my.TSclock, TSecr=TS.Recent); if (Snd.WS.OK) then Include in segment: WSopt = Rcv.wind.scale; } Receive {SYN} or {SYN,ACK} segment => { if (Segment contains TSopt) then { TS.Recent = SEG.TSval; Snd.TS.OK = TRUE; if (is {SYN,ACK} segment) then Update_SRTT( (my.TSclock - SEG.TSecr)*my.TSclock.rate ) ; } if Segment contains WSopt) then { Snd.wind.scale = SEG.WSopt; Snd.WS.OK = TRUE; } else Rcv.wind.scale = Snd.wind.scale = 0; } Network Working Group Expires August 1997 [Page 33] Internet-Draft TCP Extensions for High Performance February 1997 Send non-SYN segment => { SEG.ACK = Last.ACK.sent = RCV.NXT; SEG.WND = MIN( RCV.WND >> Rcv.wind.scale, 65535 ); if (Snd.TS.OK) then Include in segment: TSopt(TSval=my.TSclock, TSecr=TS.Recent); } Receive non-SYN segment in (state >= ESTABLISHED) => { Window = (SEG.WND << Snd.wind.scale); /* Use 32-bit 'Window' instead of 16-bit 'SEG.WND' * in rest of processing. */ if (Segment contains TSopt) then { if (SEG.TSval < TS.Recent && Idle less than 25 days) then { if (Send.TS.OK AND (NOT RST) ) then { /* Timestamp too old => * segment is unacceptable. */ Send ACK segment; Discard segment and return; } } else { if (SEG.SEQ =< Last.ACK.sent) then TS.Recent = SEG.TSval; } } if (SEG.ACK > SND.UNA) then { /* (At least part of) first segment in * retransmission queue has been ACKd */ if (Segment contains TSopt) then Update_SRTT( (my.TSclock - SEG.TSecr)/my.TSclock.rate); else Update_SRTT( /* for compatibility */ (my.TSclock - Start.Time)/my.TSclock.rate); } } Network Working Group Expires August 1997 [Page 34] Internet-Draft TCP Extensions for High Performance February 1997 APPENDIX F: EVENT PROCESSING SUMMARY Event Processing OPEN Call ... An initial send sequence number (ISS) is selected. Send a SYN segment of the form: ... SEND Call CLOSED STATE (i.e., TCB does not exist) ... LISTEN STATE If the foreign socket is specified, then change the connection from passive to active, select an ISS. Send a SYN segment containing the options: and . Set SND.UNA to ISS, SND.NXT to ISS+1. Enter SYN-SENT state. ... SYN-SENT STATE SYN-RECEIVED STATE ... ESTABLISHED STATE CLOSE-WAIT STATE Segmentize the buffer and send it with a piggybacked acknowledgment (acknowledgment value = RCV.NXT). ... If the urgent flag is set ... If the Snd.TS.OK flag is set, then include the TCP Timestamps option in each data segment. Scale the receive window for transmission in the segment header: SEG.WND = (RCV.WND >> Rcv.Wind.Scale). Network Working Group Expires August 1997 [Page 35] Internet-Draft TCP Extensions for High Performance February 1997 SEGMENT ARRIVES ... If the state is LISTEN then first check for an RST ... second check for an ACK ... third check for a SYN if the SYN bit is set, check the security. If the ... ... If the SEG.PRC is less than the TCB.PRC then continue. Check for a Window Scale option (WSopt); if one is found, save SEG.WSopt in Snd.Wind.Scale and set Snd.WS.OK flag on. Otherwise, set both Snd.Wind.Scale and Rcv.Wind.Scale to zero and clear Snd.WS.OK flag. Check for a TSopt option; if one is found, save SEG.TSval in the variable TS.Recent and turn on the Snd.TS.OK bit. Set RCV.NXT to SEG.SEQ+1, IRS is set to SEG.SEQ and any other control or text should be queued for processing later. ISS should be selected and a SYN segment sent of the form: If the Snd.WS.OK bit is on, include a WSopt option in this segment. If the Snd.TS.OK bit is on, include a TSopt in this segment. Last.ACK.sent is set to RCV.NXT. SND.NXT is set to ISS+1 and SND.UNA to ISS. The connection state should be changed to SYN-RECEIVED. Note that any other incoming control or data (combined with SYN) will be processed in the SYN-RECEIVED state, but processing of SYN and ACK should not be repeated. If the listen was not fully specified (i.e., the foreign socket was not fully specified), then the unspecified fields should be filled in now. fourth other text or control Network Working Group Expires August 1997 [Page 36] Internet-Draft TCP Extensions for High Performance February 1997 ... If the state is SYN-SENT then first check the ACK bit ... fourth check the SYN bit ... If the SYN bit is on and the security/compartment and precedence are acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to SEG.SEQ, and any acknowledgements on the retransmission queue which are thereby acknowledged should be removed. Check for a Window Scale option (WSopt); if is found, save SEG.WSopt in Snd.Wind.Scale; otherwise, set both Snd.Wind.Scale and Rcv.Wind.Scale to zero. Check for a TSopt option; if one is found, save SEG.TSval in variable TS.Recent and turn on the Snd.TS.OK bit in the connection control block. If the ACK bit is set, use my.TSclock - SEG.TSecr as the initial RTT estimate. If SND.UNA > ISS (our SYN has been ACKed), change the connection state to ESTABLISHED, form an ACK segment: and send it. If the Snd.Echo.OK bit is on, include a TSopt option in this ACK segment. Last.ACK.sent is set to RCV.NXT. Data or controls which were queued for transmission may be included. If there are other controls or text in the segment then continue processing at the sixth step below where the URG bit is checked, otherwise return. Otherwise enter SYN-RECEIVED, form a SYN,ACK segment: and send it. If the Snd.Echo.OK bit is on, include a TSopt option in this segment. If the Snd.WS.OK bit is on, include a WSopt option in this segment. Last.ACK.sent is set to RCV.NXT. Network Working Group Expires August 1997 [Page 37] Internet-Draft TCP Extensions for High Performance February 1997 If there are other controls or text in the segment, queue them for processing after the ESTABLISHED state has been reached, return. fifth, if neither of the SYN or RST bits is set then drop the segment and return. Otherwise, First, check sequence number SYN-RECEIVED STATE ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATE CLOSE-WAIT STATE CLOSING STATE LAST-ACK STATE TIME-WAIT STATE Segments are processed in sequence. Initial tests on arrival are used to discard old duplicates, but further processing is done in SEG.SEQ order. If a segment's contents straddle the boundary between old and new, only the new parts should be processed. Rescale the received window field: TrueWindow = SEG.WND << Snd.Wind.Scale, and use "TrueWindow" in place of SEG.WND in the following steps. Check whether the segment contains a Timestamps option and bit Snd.TS.OK is on. If so: If SEG.TSval < TS.Recent, then test whether connection has been idle less than 24 days; if both are true, then the segment is not acceptable; follow steps below for an unacceptable segment. If SEG.SEQ is equal to Last.ACK.sent, then save SEG.ECopt in variable TS.Recent. There are four cases for the acceptability test for an incoming segment: ... Network Working Group Expires August 1997 [Page 38] Internet-Draft TCP Extensions for High Performance February 1997 If an incoming segment is not acceptable, an acknowledgment should be sent in reply (unless the RST bit is set, if so drop the segment and return): Last.ACK.sent is set to SEG.ACK of the acknowledgment. If the Snd.Echo.OK bit is on, include the Timestamps option in this ACK segment. Set Last.ACK.sent to SEG.ACK and send the ACK segment. After sending the acknowledgment, drop the unacceptable segment and return. ... fifth check the ACK field. if the ACK bit is off drop the segment and return. if the ACK bit is on ... ESTABLISHED STATE If SND.UNA < SEG.ACK =< SND.NXT then, set SND.UNA <- SEG.ACK. Also compute a new estimate of round-trip time. If Snd.TS.OK bit is on, use my.TSclock - SEG.TSecr; otherwise use the elapsed time since the first segment in the retransmission queue was sent. Any segments on the retransmission queue which are thereby entirely acknowledged... ... Seventh, process the segment text. ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATE ... Send an acknowledgment of the form: If the Snd.TS.OK bit is on, include Timestamps option Network Working Group Expires August 1997 [Page 39] Internet-Draft TCP Extensions for High Performance February 1997 in this ACK segment. Set Last.ACK.sent to SEG.ACK of the acknowledgment, and send it. This acknowledgment should be piggy-backed on a segment being transmitted if possible without incurring undue delay. ... APPENDIX G: TCP OPTIONS AND MSS There has been some confusion as to what value should be filled in the TCP MSS option when using TCP options. RFC-879 [Postel83] stated: The MSS counts only data octets in the segment, it does not count the TCP header or the IP header. which is unclear about what to do about TCP options. RFC-1122 [Braden89] attempted to clarify this in section 4.2.2.6, but there still seems to be confusion. So, the MSS value to be sent in an MSS option should be equal to the effective MTU minus the fixed IP and TCP headers. Since both IP and TCP options are ignored when calculating value for the MSS option, if there are any IP or TCP options to be sent in a packet, then the sender must decrease the size of the TCP data accordingly. The reason for this can be seen in the following table: | MSS is adjusted | MSS is not adjusted | to include options | to include options ----------------+-----------------------+-------------------- Sender adjusts | packets are too | packets are the length for | short | correct length options | | ----------------+-----------------------+-------------------- Sender doesn't | packets are the | packets are too adjust length | correct length | long. for options | | Since the goal is to not send IP datagrams that have to be fragmented, and packets sent with the constraints in the lower right of this grid will cause IP fragmentation, the only way to guarantee that this doesn't happen is for the data sender to decrease the TCP data length by the size of the IP and TCP options. And since the sender will be adjusting the TCP data length when sending IP and TCP options, there is no need to include the IP and TCP option lengths in the MSS value. Network Working Group Expires August 1997 [Page 40] Internet-Draft TCP Extensions for High Performance February 1997 Security Considerations Security issues are not discussed in this memo. Authors' Addresses Van Jacobson University of California Lawrence Berkeley Laboratory Mail Stop 46A Berkeley, CA 94720 Phone: (415) 486-6411 EMail: van@CSAM.LBL.GOV Bob Braden University of Southern California Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Phone: (310) 822-1511 EMail: Braden@ISI.EDU David Borman Berkeley Software Design, Inc. 5575 Tech Center Drive, Suite #110 Colorado Springs, CO 80919 Phone: (612) 405-8194 Email: dab@BSDI.COM Network Working Group Expires August 1997 [Page 41] From tcplw-relay@services.BSDI.COM Tue Apr 21 12:28:56 1998 Delivery-Date: Tue, 21 Apr 1998 12:28:56 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id MAA28714 for ; Tue, 21 Apr 1998 12:28:55 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA08500 for ; Tue, 21 Apr 1998 12:31:21 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id KAA27421 for tcplw-list@bsdi.com; Tue, 21 Apr 1998 10:28:11 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id KAA27418 for ; Tue, 21 Apr 1998 10:28:10 -0600 (MDT) Received: from out4.ibm.net (out4.ibm.net [165.87.194.239]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id KAA07810 for env-from (cannara@ibm.net); Tue, 21 Apr 1998 10:27:37 -0600 (MDT) Received: from ibm.net (slip129-37-21-235.ga.us.ibm.net [129.37.21.235]) by out4.ibm.net (8.8.5/8.6.9) with ESMTP id QAA56448 for ; Tue, 21 Apr 1998 16:28:05 GMT Message-ID: <353CC92D.1396F981@ibm.net> Date: Tue, 21 Apr 1998 09:28:29 -0700 From: Cannara Reply-To: cannara@ibm.net X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: tcplw@bsdi.com Subject: Large win info Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Do you have a document, now that you're complete? Dr. A. Cannara Menlo Park Ca. From tcplw-relay@services.BSDI.COM Thu Apr 23 12:19:08 1998 Delivery-Date: Thu, 23 Apr 1998 12:19:08 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id MAA10056 for ; Thu, 23 Apr 1998 12:19:07 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA17979 for ; Thu, 23 Apr 1998 12:21:33 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id KAA00579 for tcplw-list@bsdi.com; Thu, 23 Apr 1998 10:15:35 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id KAA00576 for ; Thu, 23 Apr 1998 10:15:35 -0600 (MDT) Received: from nemesis.csi.forth.gr (nemesis.csi.forth.gr [139.91.151.3]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id KAA00505 for env-from (spapad@csi.forth.gr); Thu, 23 Apr 1998 10:14:04 -0600 (MDT) Received: from ismene-lane.csi.forth.gr (ismene-lane.csi.forth.gr [139.91.157.51]) by nemesis.csi.forth.gr (8.8.7/ICS-FORTH/V3) with ESMTP id TAA25714 for ; Thu, 23 Apr 1998 19:14:29 +0300 (EET DST) Received: from sappho-lane.ics.forth.gr (sapphoether.csi.forth.gr [139.91.191.50]) by ismene-lane.csi.forth.gr (8.8.8/ICS-FORTH/V3) with ESMTP id TAA25863 for ; Thu, 23 Apr 1998 19:14:21 +0300 (EET DST) From: "Stavros A. Papadakis" Received: (from spapad@localhost) by sappho-lane.ics.forth.gr (8.8.8/ICS-FORTH/C1) id TAA23340; Thu, 23 Apr 1998 19:14:18 +0300 (EET DST) Date: Thu, 23 Apr 1998 19:14:18 +0300 (EET DST) Posted-Date: Thu, 23 Apr 1998 19:14:18 +0300 (EET DST) Message-Id: <199804231614.TAA23340@sappho-lane.ics.forth.gr> Organization: Institute of Computer Science, Foundation for Research and Technology-Hellas (FORTH) Science and Technology Park of Crete Vassilika Vouton, P.O.Box 1385 GR 711 10 Heraklion, Crete, Greece tel.: +30 (81) 39 16 00, fax: +30 (81) 39 16 01 To: tcplw@bsdi.com Subject: ECDL98 - Final Call For Papers _______________________________________________________________________________ CALL for PAPERS Second European Conference on Research and Advanced Technology for Digital Libraries European European ICS-FORTH University of Union Research Crete Consortium for Informatics and Mathematics 19 - 23 September, 1998 Heraklion, Crete, Greece http://www.csi.forth.gr/2EuroDL ecdl@cc.uch.gr _______________________________________________________________________________ Be sure to check the following categories: Papers, Posters, Accepted Tutorials, Panels and Demos, Invited Speakers, Special Sessions _______________________________________________________________________________ - Objectives This conference is the second of a series of European conferences on research and technology for digital libraries funded by the European Commission's TMR Programme. Its objectives are: to bring together researchers from multiple disciplines whose science relates to the development of digital libraries; to provide an opportunity for these scientists to form a research community in Europe specific to digital library development and to enable them to discuss issues and strategies specific to the European context; to assist young researchers in establishing relationships with senior scientists in their areas of interest; to enable review and discussion of research under way in Europe, the US, Japan and other countries on digital libraries; to stimulate researchers, especially young scientists, to explore new areas of interest in digital library development; to establish a forum for discussion of issues specific to Europe such as interoperability, multilinguality, intellectual property policy, and information commerce; to provide an opportunity for researchers in the relevant enabling technologies and information sciences, to discuss issues related to interoperability between world wide distributed digital libraries. >From a technical point of view, the European Conferences series aims to contribute to the definition of those digital library parameters which especially influence issues of access, retrieval, and interaction with information; to identify key problems which must be solved to make digital library services an effective reality; to identify a general structure or framework for integrating research and solutions; and to propose and encourage specific, high priority research directions within such a framework. _______________________________________________________________________________ - Topics The conference organisers solicit papers on topics related to digital libraries, including but not limited to the following list: o Digital Library Models, Frameworks, and System Requirements o Metadata o System Integration and Architecture Issues o Interoperability, Scalability o Networked Information Discovery, Agent Technologies o Information Retrieval, Organisation, Navigation - Tools and Paradigms o Multilinguality o Role of Knowledge Representation Systems in Digital Library Interactions o Collecting, Capturing, Filtering, Cataloging, Indexing, o Preserving o Intellectual Property Rights, Terms and Conditions, Rights Management o Authoring, Electronic Publishing, Electronic Commerce and Information Economies o Economic and Social Implications and Issues o User Interfaces o Handling of Graphics, GIS, Medical Data, Multimedia Information, Experimental Data and o Scientific Models _______________________________________________________________________________ - Conference Programme The conference will be held in Heraklion, Crete, Greece. Tutorials will be organised on the 19th and 20th of September 1998 (for a list of accepted tutorials please consult the relevant section below). The opening session will take place at 9.00a.m. on Monday the 21th of September 1998 and the final session will take place on Wednesday afternoon, the 23th of September 1998. Full details on the scientific programme of the Conference will be published on our Web site by the 1st of July 1998. _______________________________________________________________________________ - Important Dates 15 May 1998 Papers and proposals for posters deadline 25 June 1998 Notification of paper and poster acceptance 1 July 1998 Scientific Programme on the Web 25 July 1998 Final papers due 19,20 September 1998 Tutorials 21-23 September 1998 Conference _______________________________________________________________________________ - Posters During the conference a space will be reserved for poster sessions. Research projects of any scale are invited to illustrate innovative concepts and prototype systems. Poster proposals should include title, names of presenters and outline (max. 500 words). Electronic submissions are obligatory; proposals should be submitted by e-mail to the Conference Secretariat, ecdl@cc.uch.gr. _______________________________________________________________________________ - Papers - Submission Details Papers (max 20 pages, double spaced) should be submitted electronically in HTML format, either by e-mail to the Conference Secretariat, ecdl@cc.uch.gr, or to our ftp site, ftp://ftp.ics.forth.gr/2EuroDL. In either case please follow the guidelines below: 1. in your submission there should be exaclty one HTML file containing the paper text, suitable for review printing 2. each figure (or other material except text) should be in a separate file 3. all files consisting your paper should be gathered in a single file (zip or tar format) 4. submit your paper (please note that electronic submissions are obligatory) either by e-mail or ftp 5. send a separate e-mail message to ecdl@cc.uch.gr containing the title, abstract, keywords for the paper and the relevant contact information. - The deadline for paper submissions is May 15, 1998. - Important Information - Best papers will be proposed for publication in a special issue of the IJODL The best papers of the conference will be proposed for publication (after a new revision and refereeing process) in a special issue of the International Journal on Digital Libraries ( http://link.springer.de/link/service/journals/00799/index.htm ) - Accepted papers will be published by Springer All accepted papers for the conference will be published by Springer. Upon selection of your paper you are also obliged to provide us another copy of your paper, in LaTeX2e or MS Word format, following the guidelines provided by Springer. The final date for the preparation of the accepted papers will be July 15, 1998. Detailed information on preparing accepted papers for publishing can be found at the Springer-Verlag web site, http://www.springer.de. Please be sure to read the "Information for Authors" ( http://www.springer.de/comp/lncs/authors.html ), as well as the new version of the "Authors's Instructions" (you may retrieve this file in PDF format from http://www.springer.de/comp/lncs/instruct/typeinst.pdf or in Postscript format from http://www.springer.de/comp/lncs/instruct/typeinst.ps; you may also retrieve all related files from our web site; information will be available from our web pages shortly). _______________________________________________________________________________ - PANELS, TUTORIALS AND DEMOS Detailed information regarding tutorials, demos and panels can be found at the conference web page http://www.ics.forth.gr/2EuroDL/highlights.html. In brief, accepted tutorials for the conference are the following (http://www.ics.forth.gr/2EuroDL/highlights/tutorials.html): 1. Standards for interfacing with a digital library by Larry Masinter 2. Thesauri for knowledge-based assistance in searching digital libraries by Dagobert Soergel 3. Visual Information System by Babu M. Mehtre 4. Multimedia Information Retrieval, categorisation, and filtering by Pasquale Savino and Fabrizio Sebastiani 5. Designing Content for the Web of Tomorrow, World Wide Web Consortium sponsored Tutorial by Bert Bos 6. Metadata on the Web: the Resource Description Framework (RDF), World Wide Web Consortium sponsored Tutorial by Janne Saarela 7. Metadata for Networked Resources by Renato Iannella, Carl Lagoze and Stuart Weibel A tutorial registration form will be available shortly from our web pages. Accepted panels for the conference (http://www.ics.forth.gr/2EuroDL/highlights/panels.html): 1. Interaction Design in Digital Libraries Panelists: Constantine Stephanidis, David Benyon, Mark Maybury, Daniel Dardailler, Dan Diaper 2. Digital Video Libraries: Providing Access to the Moving Image Panelists: Richard Paterson, Rachel Hughes, Robin Wright, Bruce Tonkin 3. Digital Library Technologies in Health Care Panel Coordinator: Prof. Stelios Orphanoudakis 4. Architectures and services for cultural heritage information Panel Coordinator: Panos Constantopoulos 5. Metadata and content-based approaches to resource discovery Panel Organizers: Thomas Baker and Judith Klavans Accepted demos for the conference (http://www.ics.forth.gr/2EuroDL/highlights/demos.html): 1. Liberation by Robert Stubenrauch 2. Aquarelle by Vassilis Christophides 3. Aontas: The CaberNet Technical Report and Abstracts Service by Frank Siqueira 4. The Low-Cost Digital Library by Philip Konomos 5. Multilingual Informedia: A Demonstration of Speech Recognition and Information Retrieval across Multiple Languages by Howard Wactlar 6. ARHON: A Multimedia Database Design for Image Documents by Kostas Chandrinos 7. Nara Institute of Science and Technology (NAIST) Digital Library System by Hideki Sunahara 8. The Document Management System SAROS/Mezzanine by Norbert Lossau 9. Unicode-based Digital Library Interface by Sarantos Kapidakis 10. ERCIM Technical Reference Digital Library by Stefania Biagioni 11. CiBIT: Biblioteca Telematica Italiana. A Digital Library for the Italian Cultural Heritage by Eugenio Picchi 12. INTEX: Searching Information in Full Text by Maurice Gross 13. Calliope: an experiment in Digital Libraries by Catherine Alauzun _______________________________________________________________________________ - Invited Speakers http://www.ics.forth.gr/2EuroDL/highlights.html#speakers * Dr. Donald F. Ferguson Senior Manager IBM T.J Watson Reseach Center, IBM Academy, USA Software Systems and Middleware for Information Economies and Digital Libraries * Dr. James J. O'Donnell Professor of classical studies, Vice Provost for Computing University of Pennsylvania, USA The Digital Library in the University: How We Use it * Dr. Amy Friedlander CNRI, Editor of the D-Lib Magazine Dr. William Y. Arms CNRI, Publisher of the D-Lib Magazine Publishing at the Speed of Web-Light; Experiences from D-Lib Magazine * Mark T. Maybury Advanced Information Systems Center, The MITRE Corporation Intelligent Multimedia Information Access _______________________________________________________________________________ - Special Sessions http://www.ics.forth.gr/2EuroDL/highlights.html#sessions A special session on "Digital Library Technologies for Libraries" will be held during the conference. Detailed information can be found at the conference web site. Session organiser: Ann Okerson Speakers: Diann Rusch-Feja, John Price-Wilkin, Chris Rusbridge _______________________________________________________________________________ - Proceedings The Proceedings will be published by Springer as a volume in their Lecture Notes in Computer Science series and will be distributed at the Conference. _______________________________________________________________________________ - Fellowship for Young Researchers A limited number of fellowships for the Conference and also for Tutorials are available for young researchers who are citizens of European Union countries or Liechtenstein, Norway and Iceland. The fellowship offers free registration for the participants and, in special cases where necessary and appropriately justified, may pay for or reimburse travel and lodging expenses. _______________________________________________________________________________ - Programme Chair Christos Nikolaou, University of Crete & ICS-FORTH Leoforos Knossou, GR-71110 Heraklion, Crete, Greece Tel: +30 81 393199, Fax: +30 81 210106 E-mail: nikolau@cc.uch.gr _______________________________________________________________________________ - Programme Committee Serge Abiteboul INRIA, France Robert B. Allen Bellcore, USA Thomas Baker Asian Institute of Technology, Thailand William Birmingham University of Michigan, USA Panos Constantopoulos University of Crete & ICS-FORTH, Greece Bruce Croft University of Massachusetts, USA Costis Dallas Hellenic Ministry of Foreign Affairs, Greece Edward A. Fox Virginia Technical University, USA Norbert Fuhr University of Dortmund, Germany Hector Garcia-Molina Stanford University, USA Keith Jeffery RAL-CLRC, UK Martin Kersten CWI, Netherlands Judith Klavans Columbia University, USA Carl Lagoze Cornell University, USA Clifford A. Lynch Coalition for Networked Information, USA Jeff MacKie-Mason University of Michigan, USA A. Desai Narasimhalu National University of Singapore, Singapore Ann Okerson Yale University, USA Olle Olsson SICS, Sweden Andreas Paepcke Stanford University, USA Nicholas Patrikalakis MIT, USA Carol Peters IEI-CNR, Italy Jakka Sairamesh IBM-T.J. Watson Research Center, USA Peter Schauble ETH Zurich, Switzerland Hans Joerg Schek ETH Zurich, Switzerland Eric Simon INRIA, France Ingeborg T. Solvberg University of Science and Technology, Norway Constantine Stephanidis ICS-FORTH, Greece Shigeo Sugimoto University of Library and Information Science,Japan Costantino Thanos IEI-CNR, Italy Ulrich Thiel GMD-IPSI, Germany Stuart Weibel OCLC, USA _______________________________________________________________________________ - Local Organising Committee Sarantos Kapidakis ICS-FORTH, Greece Penelope Constanta ICS-FORTH, Greece Spyros Lalis University of Crete, Greece Gioylh Koraoy University of Crete, Greece Stella Vourou University of Crete & ICS-FORTH, Greece Mixalhs Tzekakhs University of Crete, Greece Maria Stavrakaki University of Crete, Greece Rena Kalaitzaki University of Crete, Greece Maria Prevelianaki ICS-FORTH, Greece Liana Kefalaki ICS-FORTH, Greece Dimitris Papadakis University of Crete, Greece Manolis Marazakis University of Crete, Greece Anastasia Anastasiadi ICS-FORTH, Greece Stavros Papadakis University of Crete, Greece _______________________________________________________________________________ - Contact Info For more information regarding this conference contact the conference secretariat, Rena Kalaitzaki and Maria Stavrakaki University of Crete, Computer Science Department, Tel: +30 81 393504 Fax: +30 81 393501 E-mail: ecdl@cc.uch.gr _______________________________________________________________________________ You can subscribe to the announcement list of the "Second European Conference on Research and Advanced Technology for Digital Libraries" by sending electronic mail to 'majordomo@csi.forth.gr' with body 'subscribe ecdl2-announce ' From tcplw-relay@services.BSDI.COM Mon Apr 27 16:53:57 1998 Delivery-Date: Mon, 27 Apr 1998 16:53:57 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id QAA11448 for ; Mon, 27 Apr 1998 16:53:56 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04990 for ; Mon, 27 Apr 1998 16:56:24 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id OAA23967 for tcplw-list@bsdi.com; Mon, 27 Apr 1998 14:48:57 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id OAA23964 for ; Mon, 27 Apr 1998 14:48:57 -0600 (MDT) Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id OAA04850 for env-from (dab@frantic.bsdi.com); Mon, 27 Apr 1998 14:48:08 -0600 (MDT) Received: (from dab@localhost) by frantic.bsdi.com (8.8.8/8.8.8) id PAA15364; Mon, 27 Apr 1998 15:48:47 -0500 (CDT) Date: Mon, 27 Apr 1998 15:48:47 -0500 (CDT) From: David Borman Message-Id: <199804272048.PAA15364@frantic.bsdi.com> To: tcplw@BSDI.COM Subject: RFC 1323 implementation Cc: tcp-impl@cthulhu.engr.sgi.com Hi, I've not had any responses to my request for vendor implementations of RFC 1323, needed for advancing RFC 1323 in the standards process. So, 1) I've dredged up the list of implementations from July, 1993, and attached it to the end of this message, and 2) I've added "tcp-impl@cthulhu.engr.sgi.com" to the Cc: list, hopefully to find more vendors that have RFC 1323 implemented. Please send me updates, I'm sure there are many. To make things easier, here is an implementation checklist, with some specific items of interest. (Additions to this checklist are welcome.) _ Section 2.2 1. |_| Window Scale Option 2. |_| Only send in SYN/ACK if received in SYN 3. |_| Window Scale size based on receive buffer size _ Section 2.3 4. |_| Shift values > 14 are logged and treated as 14. _ Section 3.2 5. |_| Timestamps Option 6. |_| Only send in SYN/ACK if received in SYN 7. |_| RTT calculations based on Timestamps _ Section 3.4 *8. |_| Update TS.Recent if: SEG.TSval >= TSrecent and SEG.SEQ <= Last.ACK.sent _ Section 4.x 9. |_| PAWS 10. |_| "invalidate" TS.Recent if idle > 24 days. _ Appendix A: *11. |_| TCP Maxseg option: MSS = MTU - fixed IP/TCP header *12. |_| On output: adjust TCP data length for TCP options *13. |_| adjust TCP data length for IP options _ Appendix C: *14. |_| Disable Karn algorithm w/RTTM * New/changed items from RFC 1323. I'll start the ball rolling by adding: Vendor: Berkeley Software Design, Inc. Product: BSD/OS Version: 4.0 Checklist items: 1-14 Version: 3.0+patches/3.1 Checklist items: 1-12, 14 Version: 2.1 & earlier Checklist items: 1-7, 9-12, 14 Contact: David Borman, dab@bsdi.com So, please send me your updates. I'd rather not depend on an implementation list that is 5 years old. -David Borman, dab@bsdi.com > From tcplw-relay@cray.com Tue Jul 27 13:54:53 1993 > Received: by hemlock.cray.com > id AA08715; 4.1/CRI-5.6; Tue, 27 Jul 93 13:54:56 CDT > Received: from cray.com (timbuk.cray.com) by hemlock.cray.com > id AA08711; 4.1/CRI-5.6; Tue, 27 Jul 93 13:54:53 CDT > Received: from frenzy.cray.com by cray.com (4.1/CRI-MX 2.19) > id AA15875; Tue, 27 Jul 93 13:54:51 CDT > Received: by frenzy.cray.com > id AA05161; 4.1/CRI-5.6; Tue, 27 Jul 93 13:55:45 CDT > Date: Tue, 27 Jul 93 13:55:45 CDT > From: dab@berserkly.cray.com (David A. Borman) > Message-Id: <9307271855.AA05161@frenzy.cray.com> > To: tcplw@cray.com > Subject: 1323 implementations > Status: R > > > I had an action item from the TCPLW WG meeting in Amsterdam to update > the list of implementations of the TCP Extensions in RFC 1323. > Attached is what I have currently, based on the survey that I did > last December. If your implementation is not here, please send me > the relevent information. If you have updated information on your > implementation, please send me that information also. Thanks. > > -David Borman, dab@cray.com > > ---------- > TCP extensions implementations as of 12/18/92 > > Cray Research, Inc > > Product: Unicos > Window Scale > Timestamps w/ RTT caluculations (7.0 & later) > PAWS (7.0 and later) > Obsolete Echo and Echo Reply (6.0 & 6.1) > > Status: Supported Product > > Availability: > Mods available for UNICOS 6.0 > Unicos 6.1, 7.0, 7.C > > Tested with: > Van Jacobson's code and > many others (see below) > > Caveats/Problems: > The 6.0 and 6.1 versions do not support Timestamps, > RTT calculations or PAWS. They use the obsoleted > Echo and Echo Reply options defined in RFC 1072. > > The 7.0 and 7.C versions will send both a Timestamp > and an Echo option in SYN packets. SYN/ACK packets > will contain either a Timestamp or an Echo, but not > both, depending on what was received in the SYN packet. > > Support for the Echo/Echo Reply options will go away > in a future release. > > The window scale must be set with an explicit > setsockopt() call, and the use of Timestamps is > tied to the Window Scale option. > > If a Window Scale is received in a SYN packet, and > the application hasn't specified otherwise, the > Window Scale is automatically turned around in the > SYN/ACK with the same value. > > 6.1 has no applications (other than nettest) that > take advantage of expanded windows. > > Ftp and ftpd are the only additional applications that > have been enhanced in 7.0 and 7.C to use expanded windows. > > Contact: David Borman, dab@cray.com > > Interlink Computer Sciences > > Product: SNSTCP/access 1.0.1 > Window Scale > Timestamps > PAWS > > Status: Supported Product > > Availability: > PTF MP10497 or PTF MP10498 for 1.1 > > Tested with: Cray UNICOS > > Caveats/Problems: > The code is enabled for port 21 and other ports if they > specify > 64k of buffer space. Some implementations do > not like this option and fail. We provide a patch to > turn off this option for all cases. > > > Contact: Fred Bohle, fab@interlink.com (301)-317-6600 > > > Silicon Graphics, Inc > > Product: a future release of IRIX > Window Scale > Timestamps w/ RTT calculations > PAWS > > Status: Supported Product > > Availability: > "Real Soon Now" (probably spring '93) > > Tested with: Cray UNICOS > > Caveats/Problems: > Time-stamps are tied to window scaling and window scaling > options will only be used on connections when a send or > receive buffer is explicitely set to >64K. All other > connections will not use any of the options. > > Old style (RFC 1072) echo/echo-reply options will be > ignored. Only the RFC 1323 combined time-stamp/reply > option is supported. > > > Contact: Thomas Skibo, skibo@sgi.com > > > University of Illinois > > Product: Patch to 4.3BSD Net-2 release > Window Scale > Timestamps w/ RTT calculations > PAWS > > Status: Experimental/research/prototype > > Availability: > Anonymous ftp from uxc.cso.uiuc.edu:/pub/tcplw.shar.Z > > Tested with: Cray UNICOS > > Caveats/Problems: > Protocol control blocks are held in mbuf clusters. This > is very inefficient. Should probably use kmem_alloc() to > allocate pcbs. > > There are problems with handling of options when a socket > in TIME_WAIT gets a new connection request (i.e. the other > side is using SOREUSEADDR). This can cause the window > scaling options to be ignored in those cases. > > FINs aren't taken into account when deciding to update > TS.recent (for the echo reply). A fix for this is mentioned > in the README file with the patch. > > The PAWS check shouldn't drop segments when ts_recent is > zero (i.e. invalid). > > > Contact: Thomas Skibo, skibo@sgi.com > > > Sandia National Laboratories > > Contact: Doug Brown, cdbrown@sandia.gov (505)845-8699 > > Product: Patch to SunOS 4.1.1, 4.1.2 > Window Scale > Timestamps w/ RTT calculations > PAWS > > Status: Experimental/research/prototype > > Availability: > Contact cdbrown@sandia.gov for availability > > Caveats/Problems: > For window sizes above approx 160K bytes, the throughput > drops off noticably. I suspect some kind of memory > management problems in SunOS, but don't know for sure. > > Tested with: Cray UNICOS 6.0 (Window Scaling only) > > > Information Sciences Institute (ISI) > > Contact: Bob Braden & Liming Wei, braden@isi.edu & lwei@isi.ed > > Product: Patch to Sun OS 4.1 > > Window Scale > Timestamps w/ RTT calculations > PAWS > > Status: > Contact braden@isi.edu or lwei@isi.ed > > > Sun Microsystems Computer Corporations > > Contact: Jim Fiori, jim.fiori@east.sun.com > > Product: SunOS 4.1.X > Window Scale > Timestamps w/ RTT calculations > PAWS > > Status: Product, available for purchase > > Availability: > This is available as a Sun Consulting Special. These are > software specials that are purchased on an "as-is" basis. > For more information contact your Sun sales rep. The name > of the product is CONSULT-TCPLFN. > > Caveats/Problems: > The timestamps/PAWS must be turned on per application > via setsockopt calls. The large windows can > be turned on per application via setsockopt calls. > There are new options for both. In addition, the > default send and receive space (kernel variables) can > be set to use the large windows. > > > From tcplw-relay@services.BSDI.COM Tue Apr 28 10:33:43 1998 Delivery-Date: Tue, 28 Apr 1998 10:33:43 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id KAA06471 for ; Tue, 28 Apr 1998 10:33:43 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA07541 for ; Tue, 28 Apr 1998 10:36:10 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id IAA18535 for tcplw-list@bsdi.com; Tue, 28 Apr 1998 08:28:05 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id IAA18527; Tue, 28 Apr 1998 08:28:03 -0600 (MDT) Received: from ausmail.austin.ibm.com (ausmail.austin.ibm.com [192.35.232.19]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id IAA11145 env-from (marquard@austin.ibm.com); Tue, 28 Apr 1998 08:27:14 -0600 (MDT) Received: from netmail1.austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96]) by ausmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id JAA15874; Tue, 28 Apr 1998 09:27:59 -0500 Received: from taklimakan.austin.ibm.com (taklimakan.austin.ibm.com [9.53.150.247]) by netmail1.austin.ibm.com (8.8.5/8.8.5) with ESMTP id JAA74482; Tue, 28 Apr 1998 09:28:30 -0500 Received: from mojave.austin.ibm.com (localhost.austin.ibm.com [127.0.0.1]) by taklimakan.austin.ibm.com (AIX4.3/UCB 8.8.8/8.7-client1.01) with ESMTP id JAA23412; Tue, 28 Apr 1998 09:27:58 -0500 Message-Id: <199804281427.JAA23412@taklimakan.austin.ibm.com> X-Mailer: exmh version 2.0.2 2/24/98 To: David Borman cc: tcplw@bsdi.com, tcp-impl@cthulhu.engr.sgi.com Subject: Re: RFC 1323 implementation In-reply-to: <199804272048.PAA15364@frantic.bsdi.com> X-URL: http://www.zilker.net/~marquard Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Apr 1998 09:27:57 -0500 From: Dave Marquardt On Mon, 27 Apr 1998 15:48:47 -0500 (CDT) David Borman wrote: > I've not had any responses to my request for vendor implementations > of RFC 1323, needed for advancing RFC 1323 in the standards process. > So, 1) I've dredged up the list of implementations from July, 1993, > and attached it to the end of this message, and 2) I've added > "tcp-impl@cthulhu.engr.sgi.com" to the Cc: list, hopefully to find > more vendors that have RFC 1323 implemented. Please send me updates, > I'm sure there are many. Hi. Here's the information for Vendor: IBM Product: AIX Version: 4 AIX has a network option (like a sysctl on BSD systems) to turn RFC 1323 on or off systemwide. AIX also has a TCP level socket option TCP_RFC1323 to turn RFC 1323 on or off per socket. When RFC 1323 processing is "on" for a socket, we implement these checklist items: 1-3,5-6,8-12,14 Contact: Dave Marquardt, marquard@austin.ibm.com -- Dave Marquardt SMTP: marquard@austin.ibm.com VNET: MARQUARD at AUSTIN T/L 678-1139 +1 512 838-1139 From tcplw-relay@services.BSDI.COM Tue Apr 28 10:53:40 1998 Delivery-Date: Tue, 28 Apr 1998 10:53:41 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id KAA07145 for ; Tue, 28 Apr 1998 10:53:39 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA07662 for ; Tue, 28 Apr 1998 10:56:07 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id IAA21366 for tcplw-list@bsdi.com; Tue, 28 Apr 1998 08:53:31 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id IAA21361; Tue, 28 Apr 1998 08:53:26 -0600 (MDT) Received: from ntrlink.hq.interlink.com (ntrlink.hq.interlink.com [138.42.128.44]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id IAA11581 env-from (fab@md.interlink.com); Tue, 28 Apr 1998 08:52:37 -0600 (MDT) Received: from fab.md.interlink.com by ntrlink.hq.interlink.com (8.8.5/SMI-SVR4) id IAA11779; Tue, 28 Apr 1998 08:01:02 -0700 (PDT) Received: by fab.md.interlink.com (SMI-8.6/SMI-SVR4) id KAA06104; Tue, 28 Apr 1998 10:56:05 -0400 Date: Tue, 28 Apr 1998 10:56:05 -0400 From: Fred Bohle Message-Id: <199804281456.KAA06104@fab.md.interlink.com> To: dab@bsdi.com Subject: Re: RFC 1323 implementation Cc: tcplw@bsdi.com, tcp-impl@cthulhu.engr.sgi.com X-Sun-Charset: US-ASCII Dave, For TCPaccess release 4.1 for MVS: We have a configuration value for Window Scaling. If it is zero, we will not send Window Scaling nor Timestamp options. If it is not zero, we support 1,2,4,5,6,8,9,10,11,12,13,14. For TCPaccess release 5.2 for MVS: The remarks about configuration are the same. For nonzero scaling, we support 1,2,4,5,6,7,8,9,10,11,12,13,14. In other words, we added support for 7 in release 5.2 We control Window Scaling from configuration control, not from buffer sizes, so we do not support item 3 in either release. Fred ------------------------------------------------------------------------ Fred Bohle EMAIL: fab@interlink.com Interlink Computer Sciences AT&T : 410-992-7750 x314 9250 Rumsey Road, Suite 200 Columbia, MD 21045-1946 ------------------------------------------------------------------------ From tcplw-relay@services.BSDI.COM Tue Apr 28 11:35:40 1998 Delivery-Date: Tue, 28 Apr 1998 11:35:41 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id LAA08675 for ; Tue, 28 Apr 1998 11:35:40 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA07901 for ; Tue, 28 Apr 1998 11:38:08 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id JAA25235 for tcplw-list@bsdi.com; Tue, 28 Apr 1998 09:34:50 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id JAA25231; Tue, 28 Apr 1998 09:34:46 -0600 (MDT) Received: from zippy.psc.edu (zippy.psc.edu [128.182.61.149]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id JAA12144 env-from (mathis@psc.edu); Tue, 28 Apr 1998 09:33:57 -0600 (MDT) Received: from zippy.psc.edu (localhost [127.0.0.1]) by zippy.psc.edu (8.8.5/8.8.2) with ESMTP id LAA22196; Tue, 28 Apr 1998 11:34:42 -0400 (EDT) Message-Id: <199804281534.LAA22196@zippy.psc.edu> To: David Borman cc: tcplw@bsdi.com, tcp-impl@engr.sgi.com Subject: Re: RFC-1323.bis In-reply-to: Your message of "Tue, 21 Apr 1998 10:39:21 EDT." <199804211539.KAA06364@frantic.bsdi.com> Date: Tue, 28 Apr 1998 11:34:41 -0400 From: "Matt Mathis" We maintain a list of operating system support for various high performance features, including RFC1323, RFC1191 (pMTU discovery) and default socket buffer size limits, etc. See: http://www.psc.edu/networking/perf_tune.html . --MM-- From tcplw-relay@services.BSDI.COM Tue Apr 28 12:18:49 1998 Delivery-Date: Tue, 28 Apr 1998 12:18:49 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id MAA10222 for ; Tue, 28 Apr 1998 12:18:49 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA08116 for ; Tue, 28 Apr 1998 12:21:17 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id KAA29267 for tcplw-list@bsdi.com; Tue, 28 Apr 1998 10:18:37 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id KAA29261; Tue, 28 Apr 1998 10:18:34 -0600 (MDT) Received: from VNET.IBM.COM (vnet.ibm.com [204.146.168.194]) by mailfilter.bsdi.com (BSDI-MF 1.0) with SMTP id KAA12777 env-from (romney@VNET.IBM.COM); Tue, 28 Apr 1998 10:17:45 -0600 (MDT) Received: from GDLVM7 by VNET.IBM.COM (IBM VM SMTP V2R4) with BSMTP id 8475; Tue, 28 Apr 98 12:18:30 EDT Date: Tue, 28 Apr 98 12:08:35 EDT From: Romney White Organization: IBM Corp. Subject: Re: RFC 1323 implementation To: David Borman , tcplw@bsdi.com, owner-tcp-impl@cthulhu.engr.sgi.com cc: tcp-impl@cthulhu.engr.sgi.com In-Reply-To: <199804272048.PAA15364@frantic.bsdi.com> X-Mailer: MailBook 98.01.000 Message-Id: <980428.121719.EDT.ROMNEY@GDLVM7> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7BIT TCP/IP Level 310 for IBM's VM/ESA supports RFC 1323. It is controlled for all TCP connections globally. A parameter can be set to turn off The maximum window sizes per connection are initiation of window scaling and related functions. The window sizes for send and receive are specified as separate parameters. We support the following from your checklist: 1, 2, 3, 4, 5, 6, 7, 8, 11, 12, 13 Romney White VM TCP/IP Development IBM Corp. From tcplw-relay@services.BSDI.COM Thu Apr 30 20:31:41 1998 Delivery-Date: Thu, 30 Apr 1998 20:31:42 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA11747 for ; Thu, 30 Apr 1998 20:31:41 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA19327 for ; Thu, 30 Apr 1998 20:34:07 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id SAA27546 for tcplw-list@bsdi.com; Thu, 30 Apr 1998 18:26:56 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id SAA27539; Thu, 30 Apr 1998 18:26:39 -0600 (MDT) Received: from wd40.ftp.com (ftp.com [128.127.2.123]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id SAA19848 env-from (craigb@ftp.com); Thu, 30 Apr 1998 18:25:45 -0600 (MDT) Received: from mailserv-2high (ms1.ftp.com [128.127.2.93]) by wd40.ftp.com (8.8.8/8.8.8) with SMTP id UAA25396; Thu, 30 Apr 1998 20:26:31 -0400 (EDT) Received: from CLYDE.ftp.com by mailserv-2high (SMI-8.6/SMI-SVR4) id UAA20044; Thu, 30 Apr 1998 20:26:30 -0400 Message-Id: <199805010026.UAA20044@mailserv-2high> X-MAPI-MessageClass: IPM Priority: Normal To: dab@bsdi.com, tcplw@bsdi.com Cc: tcp-impl@cthulhu.engr.sgi.com X-Mailer: FTP Software Internet Mail 2.0 MIME-Version: 1.0 From: Craig Buffinton Sender: Craig Buffinton Subject: RE: RFC 1323 implementation Date: Thu, 30 Apr 1998 20:27:25 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit >>Reply to your message of 4/27/98 5:00 PM > The FTP Software OnNet Kernel for Windows 95 includes support for all but #13 on the check list. It also implements RFC 2001 and 2018. Craig Buffinton Senior Software Engineer FTP Software 978-684-6653 _ Section 2.2 1. |x| Window Scale Option 2. |x| Only send in SYN/ACK if received in SYN 3. |x| Window Scale size based on receive buffer size --> receive buffer size can be set by registry or app. _ Section 2.3 4. |x| Shift values > 14 are logged and treated as 14. --> Shift values > 14 are not logged _ Section 3.2 5. |x| Timestamps Option 6. |x| Only send in SYN/ACK if received in SYN 7. |x| RTT calculations based on Timestamps _ Section 3.4 *8. |x| Update TS.Recent if: SEG.TSval >= TSrecent and SEG.SEQ <= Last.ACK.sent _ Section 4.x 9. |x| PAWS 10. |x| "invalidate" TS.Recent if idle > 24 days. _ Appendix A: *11. |x| TCP Maxseg option: MSS = MTU - fixed IP/TCP header *12. |x| On output: adjust TCP data length for TCP options *13. |_| adjust TCP data length for IP options --> TCP data length not adjusted for IP options _ Appendix C: *14. |x| Disable Karn algorithm w/RTTM >>End of message From tcplw-relay@services.BSDI.COM Fri May 1 19:01:19 1998 Delivery-Date: Fri, 01 May 1998 19:01:19 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA13928 for ; Fri, 1 May 1998 19:01:08 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA23016 for ; Fri, 1 May 1998 19:03:34 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id QAA17697 for tcplw-list@bsdi.com; Fri, 1 May 1998 16:59:39 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id QAA17690; Fri, 1 May 1998 16:59:35 -0600 (MDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mailfilter.bsdi.com (BSDI-MF 1.0) with SMTP id QAA28579 env-from (Jerry.Chu@eng.Sun.COM); Fri, 1 May 1998 16:58:39 -0600 (MDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA13572; Fri, 1 May 1998 15:59:32 -0700 Received: from jurassic.eng.sun.com by sunmail1.Sun.COM (SMI-8.6/SMI-4.1) id PAA18412; Fri, 1 May 1998 15:59:29 -0700 Received: from taipei.eng.sun.com (taipei [129.146.86.158]) by jurassic.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with ESMTP id PAA23154; Fri, 1 May 1998 15:59:30 -0700 (PDT) Received: (from hkchu@localhost) by taipei.eng.sun.com (8.8.8+Sun/8.8.8) id PAA22730; Fri, 1 May 1998 15:59:05 -0700 (PDT) Date: Fri, 1 May 1998 15:59:05 -0700 (PDT) From: Hsiao-keng Jerry Chu Message-Id: <199805012259.PAA22730@taipei.eng.sun.com> To: dab@bsdi.com Subject: Re: RFC 1323 implementation Cc: tcplw@bsdi.com, tcp-impl@cthulhu.engr.sgi.com X-Sun-Charset: US-ASCII Vendor: Sun Microsystems, Inc. Product: Solaris Version: 2.6 Checklist items: 1-14 (except for a couple of minor known bugs described below) By default the active open side will NOT initiate any window scale/ timestamp options unless necessary (e.g. app specifying a >= 64k receive buffer size). The can be overridden by some system tunables. ------------------------------------------------ _ Section 2.2 1. |X| Window Scale Option 2. |X| Only send in SYN/ACK if received in SYN 3. |X| Window Scale size based on receive buffer size _ Section 2.3 4. |X| Shift values > 14 are logged and treated as 14. => We treat values > 14 as 14 but don't log an error. _ Section 3.2 5. |x| Timestamps Option 6. |x| Only send in SYN/ACK if received in SYN 7. |x| RTT calculations based on Timestamps _ Section 3.4 *8. |x| Update TS.Recent if: SEG.TSval >= TSrecent and SEG.SEQ <= Last.ACK.sent _ Section 4.x 9. |X| PAWS 10. |X| "invalidate" TS.Recent if idle > 24 days. _ Appendix A: *11. |X| TCP Maxseg option: MSS = MTU - fixed IP/TCP header => We just discovered a bug, although minor, when some IP option is => enabled. The size of the IP option gets subtracted from MSS by mistake. => Since we implemented 12/13 correctly, this only unnecessarily reduces => the effective usable payload size. The bug will be fixed asap. *12. |X| On output: adjust TCP data length for TCP options *13. |X| adjust TCP data length for IP options _ Appendix C: *14. |X| Disable Karn algorithm w/RTTM * New/changed items from RFC 1323. From tcplw-relay@services.BSDI.COM Mon May 4 03:25:18 1998 Delivery-Date: Mon, 04 May 1998 03:25:18 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA20047 for ; Mon, 4 May 1998 03:25:17 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA01923 for ; Mon, 4 May 1998 03:27:43 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id BAA23412 for tcplw-list@bsdi.com; Mon, 4 May 1998 01:20:12 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id BAA23409 for ; Mon, 4 May 1998 01:20:10 -0600 (MDT) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id BAA12897 for env-from (thorpej@lestat.nas.nasa.gov); Mon, 4 May 1998 01:19:05 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with SMTP id AAA04434; Mon, 4 May 1998 00:10:10 -0700 (PDT) Message-Id: <199805040710.AAA04434@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: localhost [127.0.0.1] didn't use HELO protocol To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: RFC 1323 implementation Cc: tcplw@bsdi.com Reply-To: Jason Thorpe From: Jason Thorpe Date: Mon, 04 May 1998 00:10:09 -0700 Sender: thorpej@nas.nasa.gov Regarding Dave's RFC1323 survey (Dave, this is an update/correction to the one which Kevin sent to you earlier...): _ Section 2.2 1. |_| Window Scale Option 2. |_| Only send in SYN/ACK if received in SYN 3. |_| Window Scale size based on receive buffer size _ Section 2.3 4. |_| Shift values > 14 are logged and treated as 14. _ Section 3.2 5. |_| Timestamps Option 6. |_| Only send in SYN/ACK if received in SYN 7. |_| RTT calculations based on Timestamps _ Section 3.4 *8. |_| Update TS.Recent if: SEG.TSval >= TSrecent and SEG.SEQ <= Last.ACK.sent _ Section 4.x 9. |_| PAWS 10. |_| "invalidate" TS.Recent if idle > 24 days. _ Appendix A: *11. |_| TCP Maxseg option: MSS = MTU - fixed IP/TCP header *12. |_| On output: adjust TCP data length for TCP options *13. |_| adjust TCP data length for IP options _ Appendix C: *14. |_| Disable Karn algorithm w/RTTM * New/changed items from RFC 1323. Vendor: The NetBSD Foundation, Inc. Product: NetBSD Version: 1.4 [1] Checklist items: 1 - 14 Version: 1.3.1 and earlier Checklist items: 1 - 7 [2], 9 - 11, 14 Contacts: Kevin M. Lahey Jason R. Thorpe [1] NetBSD 1.4 is not yet released, but the development sources which implement all checklist items are currently available as NetBSD 1.3E. [2] Window scale values > 14 are treated as 14, but not logged. This is changed in NetBSD 1.4, where the illegal value and the peer which sent it is now logged. Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: +1 408 866 1912 NAS: M/S 258-5 Work: +1 650 604 0935 Moffett Field, CA 94035 Pager: +1 415 428 6939 From tcplw-relay@services.BSDI.COM Mon May 4 16:17:22 1998 Delivery-Date: Mon, 04 May 1998 16:17:23 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA13125 for ; Mon, 4 May 1998 16:17:22 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA05264 for ; Mon, 4 May 1998 16:19:50 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id OAA07791 for tcplw-list@bsdi.com; Mon, 4 May 1998 14:16:01 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id OAA07786 for ; Mon, 4 May 1998 14:16:00 -0600 (MDT) Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id OAA18297 for env-from (dab@frantic.bsdi.com); Mon, 4 May 1998 14:14:58 -0600 (MDT) Received: (from dab@localhost) by frantic.bsdi.com (8.8.8/8.8.8) id PAA27478 for tcplw@bsdi.com; Mon, 4 May 1998 15:15:58 -0500 (CDT) Date: Mon, 4 May 1998 15:15:58 -0500 (CDT) From: David Borman Message-Id: <199805042015.PAA27478@frantic.bsdi.com> To: tcplw@BSDI.COM Subject: Window Scale option There is a change that I would like to add to RFC 1323 about the Window Scale Option. The current text on page 10 has: * The connection state is augmented by two window shift counts, Snd.Wind.Scale and Rcv.Wind.Scale, to be applied to the incoming and outgoing window fields, respectively. * If a TCP receives a segment containing a Window Scale option, it sends its own Window Scale option in the segment. * The Window Scale option is sent with shift.cnt = R, where R is the value that the TCP would like to use for its receive window. * Upon receiving a SYN segment with a Window Scale option containing shift.cnt = S, a TCP sets Snd.Wind.Scale to S and sets Rcv.Wind.Scale to R; otherwise, it sets both Snd.Wind.Scale and Rcv.Wind.Scale to zero. I'd like to change this to: * The connection state is augmented by two window shift counts, Snd.Wind.Scale and Rcv.Wind.Scale, to be applied to the incoming and outgoing window fields, respectively. ! * When sending a segment, the Window Scale option is ! sent with shift.cnt = R, where R is the value that the TCP ! would like to use for its receive window. ! * If a TCP receives a segment with a Window Scale option ! containing shift.cnt = S, it sends its own Window Scale option ! with shift.cnt = R in the . If R has not been set by ! the application, either explicitly or implicitly by changing ! the receive buffer space from its default value, a TCP may set ! R = S before generating the . The TCP then sets ! Snd.Wind.Scale to S and sets Rcv.Wind.Scale to R. ! * Upon receiving a segment with a Window Scale option containing shift.cnt = S, a TCP sets Snd.Wind.Scale to S and sets Rcv.Wind.Scale to R; otherwise, it sets both Snd.Wind.Scale and Rcv.Wind.Scale to zero. I have implemented this in both UNICOS and BSD/OS, with no ill effects. The reason for wanting to recommend turning around the scale value is that it can only be negotiated during the initial 3-way handshake, and on the passive side, the application that is doing the listen()/accept() may not be the one that knows that the receive buffer should be increased to get the a window scale value sent as non-zero. E.g, it is inetd that accepts the connection, which then execs rshd, which in turn execs rcp, which is the application that knows we're doing a bulk data transfer so the buffers should be made larger, but by then its too late. One way to address this is to modify inetd to allow it to set the receive buffers large for rshd. However, rshd is used for other things besides rcp. If the receive buffers are made large in inetd, and the application changes them back to the default values, then you have an outstanding advertised window from the initial window when the buffers were larger, which TCP can't retract. -David Borman, dab@bsdi.com From tcplw-relay@services.BSDI.COM Mon May 4 16:40:01 1998 Delivery-Date: Mon, 04 May 1998 16:40:01 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA13417 for ; Mon, 4 May 1998 16:40:00 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA05372 for ; Mon, 4 May 1998 16:42:28 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id OAA10520 for tcplw-list@bsdi.com; Mon, 4 May 1998 14:39:46 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id OAA10515; Mon, 4 May 1998 14:39:43 -0600 (MDT) From: braden@isi.edu Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id OAA18574 env-from (braden@ISI.EDU); Mon, 4 May 1998 14:38:40 -0600 (MDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id NAA11440; Mon, 4 May 1998 13:39:40 -0700 (PDT) Date: Mon, 4 May 1998 13:39:30 -0700 Posted-Date: Mon, 4 May 1998 13:39:30 -0700 Message-Id: <199805042039.AA20137@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Mon, 4 May 1998 13:39:30 -0700 To: tcplw@bsdi.com, dab@bsdi.com Subject: Re: Window Scale option Dave, Hmmmm. It seems clear in retrospect that a host really wants to allow its applications to dynamically adjust the amount of receive buffering they can have, and thereby possibly adjust the window scaling. I wonder if it's too late to do that, or whether it has to await a "second generation TCP". I recall that Van believed that the window scale ought to be determined in the Syn exchange, but I don't recall his argument for it. I expect the main problem is reliable transmission of the R value in ACK segments. I can imagine something like this: Once the 3 way handshake has negotiated scaling, any data/ACK packet can carry ScaleOption(S,R). If I want to change my R to R', I start sending a receive window with the R' scaling, together with ScaleOption(S,R'). Once the other side echos R' in its ScaleOption(R',S), I can stop sending the option. This is obviously more complicated than the current window scaling scheme, but it would at least support what applications really want. I suppose I should have reviewed the TCPLW archives before sending this message... Bob Braden From tcplw-relay@services.BSDI.COM Mon May 4 17:36:42 1998 Delivery-Date: Mon, 04 May 1998 17:36:42 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA14151 for ; Mon, 4 May 1998 17:36:41 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05656 for ; Mon, 4 May 1998 17:39:10 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id PAA15962 for tcplw-list@bsdi.com; Mon, 4 May 1998 15:35:14 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id PAA15957 for ; Mon, 4 May 1998 15:35:13 -0600 (MDT) Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id PAA19401 for env-from (dab@frantic.bsdi.com); Mon, 4 May 1998 15:34:11 -0600 (MDT) Received: (from dab@localhost) by frantic.bsdi.com (8.8.8/8.8.8) id QAA27588; Mon, 4 May 1998 16:35:05 -0500 (CDT) Date: Mon, 4 May 1998 16:35:05 -0500 (CDT) From: David Borman Message-Id: <199805042135.QAA27588@frantic.bsdi.com> To: braden@isi.edu, tcplw@BSDI.COM Subject: Re: Window Scale option Bob, > Hmmmm. It seems clear in retrospect that a host really wants to allow > its applications to dynamically adjust the amount of receive buffering > they can have, and thereby possibly adjust the window scaling. I > wonder if it's too late to do that, or whether it has to await a > "second generation TCP". I recall that Van believed that the window I think its too late now, TCPng with a 32 bit window field is the real answer... > scale ought to be determined in the Syn exchange, but I don't recall > his argument for it. The SYN segments are the only ones that are reliably retransmitted. The alternative was to include a window scale option in every packet, that applied to just that packet (See section 2.1). It was felt that the cost of limiting the Window Scale to the SYN packets was worth avoiding adding the Window Scale option to every packet. Trying to change the window scaling midflight hits two problems: 1) ACKs are not reliably retransmitted, and 2) we don't ACK acks. The side that wants to change its window scaling is typically the side that is receiving the data, and thus only generating acks... > I expect the main problem is reliable transmission of the R value in > ACK segments. I can imagine something like this: Once the 3 way Yes. > handshake has negotiated scaling, any data/ACK packet can carry > ScaleOption(S,R). If I want to change my R to R', I start sending a > receive window with the R' scaling, together with ScaleOption(S,R'). > Once the other side echos R' in its ScaleOption(R',S), I can stop > sending the option. This is obviously more complicated than the > current window scaling scheme, but it would at least support what > applications really want. An intersting idea. But it would be even more complicated than that if you start talking about multiple changes to (S,R'') before you get the ack for (R',S). And sending (S,R') would probably be in an ACK only packet, requiring the other side to either ACK an ACK, or defer (S,R') until it has data to send. I'd rather put my effort into doing TCPng. So, assuming that we are not going to be changing how the Window Scale option works, do you have any problems with recommending the ability to turn around the window scale option? And should it be a MAY or a SHOULD (I'll settle for MAY, but would like it to be SHOULD)? -David Borman, dab@bsdi.com From tcplw-relay@services.BSDI.COM Mon May 4 17:36:43 1998 Delivery-Date: Mon, 04 May 1998 17:36:43 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA14156 for ; Mon, 4 May 1998 17:36:43 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05659 for ; Mon, 4 May 1998 17:39:11 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id PAA15948 for tcplw-list@bsdi.com; Mon, 4 May 1998 15:35:01 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id PAA15945 for ; Mon, 4 May 1998 15:35:01 -0600 (MDT) Received: from gecko.nas.nasa.gov (gecko.nas.nasa.gov [129.99.34.45]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id PAA19396 for env-from (kml@gecko.nas.nasa.gov); Mon, 4 May 1998 15:33:51 -0600 (MDT) Received: from gecko.nas.nasa.gov (kml@localhost) by gecko.nas.nasa.gov (8.8.7/NAS8.8.7) with ESMTP id OAA05330; Mon, 4 May 1998 14:34:50 -0700 (PDT) Message-Id: <199805042134.OAA05330@gecko.nas.nasa.gov> To: braden@isi.edu cc: tcplw@bsdi.com Subject: Re: Window Scale option In-reply-to: Your message of "Mon, 04 May 1998 13:39:30 PDT." <199805042039.AA20137@gra.isi.edu> Date: Mon, 04 May 1998 14:34:50 -0700 From: "Kevin M. Lahey" In message <199805042039.AA20137@gra.isi.edu>braden@isi.edu writes >Hmmmm. It seems clear in retrospect that a host really wants to allow >its applications to dynamically adjust the amount of receive buffering >they can have, and thereby possibly adjust the window scaling. I'd certainly like to see this happen dynamically -- I often wind up with windows on my HIPPI LAN that are either way too small or way too large. Just specifying a large value is problematic, as it will wind up, as Dave Borman points out, in burning buffer for small, slow links. In the BSD stack, it is possible to associate socket buffer sizes with routes, so this can take care of some of the problem. The autotuning work by PSC might take care of some of the problems with buffer space being tied up unnecessarily: ftp://ftp.psc.edu/pub/networking/papers/autotune_sigcomm98.ps >I expect the main problem is reliable transmission of the R value in >ACK segments. Why not just send it with every segment? The space isn't really a problem -- we're typically burning 12 octets for the timestamp options as it is, in order to get nice alignment. We could define a new 11 octet timestamp/window scale option that would fold in both values, and would fit into the same 12 octet space. It shouldn't really require (much?) more CPU than the normal window shift that we're going to have to perform anyway -- we're just grabbing the value to use from the TCP options, rather than the tcpcb... Kevin From tcplw-relay@services.BSDI.COM Mon May 4 18:12:29 1998 Delivery-Date: Mon, 04 May 1998 18:12:30 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA14635 for ; Mon, 4 May 1998 18:12:29 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA05825 for ; Mon, 4 May 1998 18:14:56 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id QAA19056 for tcplw-list@bsdi.com; Mon, 4 May 1998 16:11:24 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id QAA19053 for ; Mon, 4 May 1998 16:11:23 -0600 (MDT) Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id QAA19709 for env-from (dab@frantic.bsdi.com); Mon, 4 May 1998 16:10:20 -0600 (MDT) Received: (from dab@localhost) by frantic.bsdi.com (8.8.8/8.8.8) id RAA27660; Mon, 4 May 1998 17:11:12 -0500 (CDT) Date: Mon, 4 May 1998 17:11:12 -0500 (CDT) From: David Borman Message-Id: <199805042211.RAA27660@frantic.bsdi.com> To: braden@isi.edu, kml@nas.nasa.gov Subject: Re: Window Scale option Cc: tcplw@BSDI.COM > Subject: Re: Window Scale option > Date: Mon, 04 May 1998 14:34:50 -0700 > From: "Kevin M. Lahey" > > In message <199805042039.AA20137@gra.isi.edu>braden@isi.edu writes > >Hmmmm. It seems clear in retrospect that a host really wants to allow > >its applications to dynamically adjust the amount of receive buffering > >they can have, and thereby possibly adjust the window scaling. > > I'd certainly like to see this happen dynamically -- I often wind up > with windows on my HIPPI LAN that are either way too small or way too > large. Just specifying a large value is problematic, as it will wind > up, as Dave Borman points out, in burning buffer for small, slow I don't think I quite said that, but that is true. :-) > links. In the BSD stack, it is possible to associate socket buffer > sizes with routes, so this can take care of some of the problem. A couple of points. First, you don't have to have large buffers to use the window scale option. In reality, what the window scale option does is change the granularity of the window updates. As long as that granularity is smaller than your threshhold for silly window syndrom avoidance, things will work just fine. A window shift of 4 allows a megabyte of window, with a window update granularity of 16 bytes, which is well below any SWS threshhold value. So, using typical 8K buffers, you can use window scale values of at least 5 or 6 without having any impact on performance. So, if bulk-data transfer clients send a window shift option, and the server automatically turns it around, it shouldn't cause any problems on the server. In BSD/OS I turn around the window scale, but I limit it to no more than 4 (changable by sysctl) to keep us from getting into trouble if we receive a window scale of 13 or 14 and our receive buffer is only 8K... I guess what I'm really saying is that if you have a user interface to TCP to allow the application to specify the window scale value without having to set the buffer size, and the server turns around the window scale value, then you can make TCP connections that are ready to use large buffers if the application wants them, without having to pre-allocate any extra buffer space on either the client or the server (and thus have an initial large window). But typically the client will know whether or not large buffers are wanted, so having it set a large receive buffer, and having the server turn around the scale option (without changing the buffer size) is usually sufficient. The only reason you don't want to always send a window scale option of at least 3 or 4 in the SYN is to avoid possible interoperability problems with older TCPs that don't properly ignore unknown TCP options, especially if there is no way that the application will ever be able to take advantage of it (i.e, it doesn't have a lot of data to transfer). -David Borman, dab@bsdi.com From tcplw-relay@services.BSDI.COM Mon May 4 18:35:36 1998 Delivery-Date: Mon, 04 May 1998 18:35:36 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA14797 for ; Mon, 4 May 1998 18:35:35 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA05891 for ; Mon, 4 May 1998 18:37:58 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id QAA21134 for tcplw-list@bsdi.com; Mon, 4 May 1998 16:34:11 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id QAA21131; Mon, 4 May 1998 16:34:07 -0600 (MDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mailfilter.bsdi.com (BSDI-MF 1.0) with SMTP id QAA19881 env-from (kcpoon@jurassic.eng.Sun.COM); Mon, 4 May 1998 16:33:01 -0600 (MDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA17172; Mon, 4 May 1998 15:34:02 -0700 Received: from jurassic.eng.sun.com by sunmail1.Sun.COM (SMI-8.6/SMI-4.1) id PAA16302; Mon, 4 May 1998 15:33:59 -0700 Received: from shield (shield [129.146.85.114]) by jurassic.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id PAA12082; Mon, 4 May 1998 15:33:57 -0700 (PDT) Date: Mon, 4 May 1998 15:33:56 -0700 (PDT) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: Window Scale option To: David Borman Cc: tcplw@bsdi.com In-Reply-To: "Your message with ID" <199805042135.QAA27588@frantic.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > So, assuming that we are not going to be changing how the Window > Scale option works, do you have any problems with recommending > the ability to turn around the window scale option? And should > it be a MAY or a SHOULD (I'll settle for MAY, but would like > it to be SHOULD)? I think it should be a MAY. If you want it to be a SHOULD, I suggest you to add that there must be a switch for the system administrator to turn this behavior on and off. K. Poon. kcpoon@eng.sun.com From tcplw-relay@services.BSDI.COM Mon May 4 18:52:35 1998 Delivery-Date: Mon, 04 May 1998 18:52:36 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA14913 for ; Mon, 4 May 1998 18:52:35 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA05924 for ; Mon, 4 May 1998 18:55:00 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id QAA22644 for tcplw-list@bsdi.com; Mon, 4 May 1998 16:52:08 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id QAA22637; Mon, 4 May 1998 16:52:05 -0600 (MDT) From: braden@isi.edu Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id QAA20039 env-from (braden@ISI.EDU); Mon, 4 May 1998 16:51:02 -0600 (MDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id PAA16407; Mon, 4 May 1998 15:52:03 -0700 (PDT) Date: Mon, 4 May 1998 15:51:48 -0700 Posted-Date: Mon, 4 May 1998 15:51:48 -0700 Message-Id: <199805042251.AA20199@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Mon, 4 May 1998 15:51:48 -0700 To: braden@isi.edu, tcplw@bsdi.com, dab@bsdi.com Subject: Re: Window Scale option *> *> An intersting idea. But it would be even more complicated than *> that if you start talking about multiple changes to (S,R'') before *> you get the ack for (R',S). And sending (S,R') would probably be *> in an ACK only packet, requiring the other side to either ACK an *> ACK, or defer (S,R') until it has data to send. I'd rather put *> my effort into doing TCPng. *> I resonate with that... *> So, assuming that we are not going to be changing how the Window *> Scale option works, do you have any problems with recommending *> the ability to turn around the window scale option? And should *> it be a MAY or a SHOULD (I'll settle for MAY, but would like *> it to be SHOULD)? *> I dunno... In some circumstances, it forces both ends to reserve large buffers even though the data flow is only in one direction. That might make the transfer fail unnecessarily, if the server does not have buffer space to devote, right? Bob *> -David Borman, dab@bsdi.com *> *> From tcplw-relay@services.BSDI.COM Mon May 4 18:58:59 1998 Delivery-Date: Mon, 04 May 1998 18:59:00 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA14949 for ; Mon, 4 May 1998 18:58:55 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05932 for ; Mon, 4 May 1998 19:01:18 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id QAA23195 for tcplw-list@bsdi.com; Mon, 4 May 1998 16:58:51 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id QAA23187; Mon, 4 May 1998 16:58:48 -0600 (MDT) From: braden@isi.edu Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id QAA20125 env-from (braden@ISI.EDU); Mon, 4 May 1998 16:57:46 -0600 (MDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id PAA16593; Mon, 4 May 1998 15:58:47 -0700 (PDT) Date: Mon, 4 May 1998 15:58:36 -0700 Posted-Date: Mon, 4 May 1998 15:58:36 -0700 Message-Id: <199805042258.AA20205@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Mon, 4 May 1998 15:58:36 -0700 To: braden@isi.edu, kml@nas.nasa.gov, dab@bsdi.com Subject: Re: Window Scale option Cc: tcplw@bsdi.com *> *> I guess what I'm really saying is that if you have a user interface *> to TCP to allow the application to specify the window scale value *> without having to set the buffer size, Dave, Why would you want to do that? It seems to me that the window scale itself should be *completely* hidden from the application; it is after all a kludge; as you noted earlier, we want to obsolete it eventually with a sensible window size. The application should know ONLY about buffer sizes! *> and the server turns around *> the window scale value, then you can make TCP connections that are *> ready to use large buffers if the application wants them, without *> having to pre-allocate any extra buffer space on either the client *> or the server (and thus have an initial large window). But typically Oh, you mean that there could be a system call that set the buffer max, without pre-allocation of buffers. But since it has to be ABLE to allocate that buffer space, you can still lose at the beginning. *> the client will know whether or not large buffers are wanted, so *> having it set a large receive buffer, and having the server turn around *> the scale option (without changing the buffer size) is usually sufficient. *> Bob From tcplw-relay@services.BSDI.COM Mon May 4 19:47:28 1998 Delivery-Date: Mon, 04 May 1998 19:47:28 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA15442 for ; Mon, 4 May 1998 19:47:27 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA06028 for ; Mon, 4 May 1998 19:49:52 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id RAA26997 for tcplw-list@bsdi.com; Mon, 4 May 1998 17:47:08 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id RAA26992; Mon, 4 May 1998 17:47:05 -0600 (MDT) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id RAA20561 env-from (thorpej@lestat.nas.nasa.gov); Mon, 4 May 1998 17:46:02 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with SMTP id QAA14532; Mon, 4 May 1998 16:37:11 -0700 (PDT) Message-Id: <199805042337.QAA14532@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: localhost [127.0.0.1] didn't use HELO protocol To: braden@isi.edu Cc: kml@nas.nasa.gov, dab@bsdi.com, tcplw@bsdi.com Subject: Re: Window Scale option Reply-To: Jason Thorpe From: Jason Thorpe Date: Mon, 04 May 1998 16:37:10 -0700 Sender: thorpej@nas.nasa.gov On Mon, 4 May 1998 15:58:36 -0700 braden@isi.edu wrote: > *> I guess what I'm really saying is that if you have a user interface > *> to TCP to allow the application to specify the window scale value > *> without having to set the buffer size, > > Dave, > > Why would you want to do that? It seems to me that the window scale > itself should be *completely* hidden from the application; it is after > all a kludge; as you noted earlier, we want to obsolete it eventually > with a sensible window size. The application should know ONLY about > buffer sizes! I agree completely. In some ways, I like with Kevin's suggestion of setting this on a per-route basis, but that has the problem of being a little too "global"; it catches things which really have no reason to advertise large windows (e.g. interactive sessions). On the other hand, I also have a problem with modifying every application that might want to do this (although I've started doing this in NetBSD just to see how annoying it might turn out to be...). Consider just the FTP case: - Modify inetd(8) so that ftpd(8) can be handed a control socket with a large recieve buffer (for passive upload). - Modify ftp(1) to allow a larger rcvbuf to be specified (for normal [data socket] and passive [control socket] download). - Modify ftpd(8) to allow a larger rcvbuf to be specified (for normal upload). > Oh, you mean that there could be a system call that set the buffer max, > without pre-allocation of buffers. But since it has to be ABLE to > allocate that buffer space, you can still lose at the beginning. Um, isn't that what the BSD stack already does? setsockopt of SO_RCVBUF simply sets so->so_rcv.sb_hiwat to the specified value; buffers are allocated lazily upon packet reception, and simply hung off the socket buffer until the high water mark is reached... In the even the buffer can't be allocated, the packet is simply dropped at the NIC level, an ACK is never transmitted, the sender's retransmit timer fires, and its congestion window closes (icky, but it works). Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: +1 408 866 1912 NAS: M/S 258-5 Work: +1 650 604 0935 Moffett Field, CA 94035 Pager: +1 415 428 6939 From tcplw-relay@services.BSDI.COM Mon May 4 20:02:34 1998 Delivery-Date: Mon, 04 May 1998 20:02:35 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA15602 for ; Mon, 4 May 1998 20:02:34 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA06062 for ; Mon, 4 May 1998 20:04:59 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id SAA28321 for tcplw-list@bsdi.com; Mon, 4 May 1998 18:02:13 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id SAA28318; Mon, 4 May 1998 18:02:08 -0600 (MDT) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id SAA20690 env-from (vern@ee.lbl.gov); Mon, 4 May 1998 18:01:05 -0600 (MDT) Received: by daffy.ee.lbl.gov (8.8.8/8.8.5) id RAA13212; Mon, 4 May 1998 17:02:05 -0700 (PDT) Message-Id: <199805050002.RAA13212@daffy.ee.lbl.gov> To: David Borman Cc: tcplw@bsdi.com Subject: comments on RFC1323.bis Date: Mon, 04 May 1998 17:02:05 PDT From: Vern Paxson Here are context diffs to the nroff source to fix some typos and phrasing, and also to point out some (minor) issues that need to be addressed. These last are done by introducing comments in the source, except when the comments are made inside a display. Some other issues: * The document doesn't specify the relationship between the options. For example, if you use window scaling, then is it a MUST that you use timestamps too? Or a SHOULD? Or ... ? * I added some MUSTs and SHOULDs (and the obligatory RFC 2119 cite to go with them). But I may have missed some places where these should be used. * A significant technical issue: the current RTTM discussion does not mention anything about altering the constants used for the exponentially-weighted moving average when updating the estimate of RTT. Sally Floyd has pointed out that using the usual constants is incorrect when the RTT is updated more than once per window; their use will result in an RTT estimate that is much more sensitive to transient changes in RTT. I think at a minimum the document needs to point out that there is an open issue here. * It needs a "security considerations" section. I sketched some thoughts on what might go in one. - Vern --- rfc1323.bis.ORIG Mon May 4 16:55:48 1998 +++ rfc1323.bis Mon May 4 16:54:46 1998 @@ -72,6 +72,9 @@ There is no one-line answer to the question: "How fast can TCP go?". There are two separate kinds of issues, performance and reliability, and each depends upon different parameters. We discuss each in turn. +.sp +(This document uses terms such as MUST and SHOULD. +See RFC 2119 for the exact interpretation of these terms.) .IN +0.3i .LT "1.1 TCP Performance" 0.3i .sp @@ -127,8 +130,10 @@ corresponding increase of the probability of more than one packet per window being dropped. This could have a devastating effect upon the throughput of TCP over an LFN. In addition, if a congestion control -mechanism based upon some form of random dropping were introduced into -gateways, randomly spaced packet drops would become common, possible +mechanism based upon some form of random dropping (such as discussed +in RFC2309) +were introduced into +gateways, randomly spaced packet drops would become common, possibly increasing the probability of dropping more than one packet per window. .sp @@ -318,7 +323,7 @@ However, some buggy TCP implementation might be crashed by the first appearance of an option on a non-SYN segment. Therefore, for each of the extensions defined below, TCP options will be sent on non-SYN -segments only after an exchange of options on the the SYN segments has +segments only after an exchange of options on the SYN segments has indicated that both sides understand the extension. Furthermore, an extension option will be sent in a segment only if the corresponding option was received in the initial segment. @@ -333,6 +338,12 @@ segment, adding 12 bytes to the 20-byte TCP header. We believe that the bandwidth saved by reducing unnecessary retransmissions will more than pay for the extra header bandwidth. +.\" How does the Timestamps option help with reducing unnecessary +.\" retransmissions? It only will if currently the RTO estimates +.\" are too low. While some TCP implementations suffer from this +.\" problem, most do not. In particular, using the coarse-grained +.\" BSD RTO algorithm works quite conservatively. So this argument +.\" is not right. .sp There is also an issue about the processing overhead for parsing the variable byte-aligned format of options, particularly with a @@ -342,7 +353,7 @@ and if it is verified then use a fast path. Hosts that use this canonical layout will effectively use the options as a set of fixed-format fields appended to the TCP header. However, to retain the -philosophical and protocol framework of TCP options, a TCP must be +philosophical and protocol framework of TCP options, a TCP MUST be prepared to parse an arbitrary options field, albeit with less efficiency. .sp @@ -415,7 +426,7 @@ with the SYN bit on and the ACK bit off). It may also be sent in a segment, but only if a Window Scale option was received in the initial segment. A Window Scale option in a segment without -a SYN bit should be ignored. +a SYN bit SHOULD be ignored. .sp The Window field in a SYN (i.e., a or ) segment itself is never scaled. @@ -577,7 +588,7 @@ set in the TCP header; if it is valid, it echos a timestamp value that was sent by the remote TCP in the TSval field of a Timestamps option. .mc -When TSecr is not valid, its value must be zero. +When TSecr is not valid, its value MUST be zero. .mc The TSecr value will generally be from the most recent Timestamp option that was received; however, there are exceptions that are explained @@ -608,6 +619,8 @@ represent the corresponding cumulative acknowledgments. The two timestamp fields of the Timestamps option are shown symbolically as . Each TSecr field contains the value most recently +.\" "most recently received" conflicts with 3.4, which spells out +.\" exactly which value is kept received in a TSval field; these echoed values. labelled "TS.Recent", are shown in parentheses. .nf @@ -625,7 +638,11 @@ 4. (130) <--- (6) . . . ( Pause for 60 timestamp clock ticks ) . . . . - + +.\" This formatting is messed up. Epochs 4 and 5 appear +.\" twice. In the first 4, TS.Recent is 130, but in the +.\" subsequent 5, we have TSecr=120. Also, why in 5 is +.\" TSval=1?? 5. (130) ---> (1) @@ -636,6 +653,8 @@ 5. ... <--- (5) +.\" What is the point of this second, less precisely specified +.\" example?? TCP A TCP B @@ -685,8 +704,8 @@ .LT (A) 0.5i Delayed ACKs. .sp -Many TCP's acknowledge only every Kth segment out of a group of -segments arriving within a short time interval; this policy is known +RFC1122 requires TCP's to acknowledge every 2nd full-sized segment. +The policy of acknowledging only every 2nd segment is known generally as "delayed ACKs". The data-sender TCP must measure the effective RTT, including the additional time due to delayed ACKs, or else it will retransmit unnecessarily. Thus, when delayed ACKs are in @@ -704,7 +723,7 @@ situation the sender should be conservative about retransmission. Furthermore, it is better to overestimate than underestimate the RTT. An ACK for an out-of-order segment should therefore contain the -timestamp from the most recent segment that advanced the window. +timestamp from the most recent (in-order) segment that advanced the window. .sp The same situation occurs if segments are re-ordered by the network. .sp @@ -734,7 +753,8 @@ SEG.TSval >= TSrecent and SEG.SEQ <= Last.ACK.sent .IN -0.3i then SEG.TSval is copied to TS.Recent; otherwise, it is -ignored. +ignored. Note that this test replaces Karn's algorithm [Karn87], +required by 4.2.3.1 of of RFC1122. .sp .LT (3) 0.5i When a TSopt is sent, its TSecr field is set to the current TS.Recent @@ -743,7 +763,10 @@ The following examples illustrate these rules. Here A, B, C... represent data segments occupying successive blocks of sequence numbers, and ACK(A),... represent the corresponding acknowledgment -segments. Note that ACK(A) has the same sequence number as B. We show +segments. Note that ACK(A) has the same sequence number as B, because +the first sequence number of B is the one immediately followly the +last sequence number included in A. +We show only one direction of timestamp echoing, for clarity. .IN +0.5i .LT o 0.5i @@ -857,8 +880,8 @@ connection will be discarded by the normal 3-way handshake and sequence number checks of TCP. .sp -It is recommended that RST segments NOT carry timestamps, and that RST -segments be acceptable regardless of their timestamp. Old duplicate +RST segments SHOULD NOT carry timestamps, and RST +segments SHOULD be accepted regardless of their timestamp. Old duplicate RST segments should be exceedingly unlikely, and their cleanup function should take precedence over timestamps. .IN +0.3i @@ -869,7 +892,7 @@ .IN +0.5i .LT R1) 0.5i If there is a Timestamps option in the arriving segment and SEG.TSval < -TS.Recent and if TS.Recent is valid (see later discussion), then treat +TS.Recent and if TS.Recent is valid (see later discussion in 4.2.3), then treat the arriving segment as not acceptable: .IN +0.5i Send an acknowledgement in reply as specified in RFC-793 page 69 and @@ -939,12 +962,15 @@ If B's retransmission was triggered by the "fast retransmit" algorithm, i.e., by duplicate ACKs, then the queued segments that caused these ACKs must have been received already. +.\" .sp +.\" Even if a segment were delayed past the RTO, the Fast Retransmit +.\" mechanism [Jacobson90c] will cause the delayed +.\" packets to be retransmitted at the same time as B.2, avoiding an extra +.\" RTT and therefore causing a very small performance penalty. +.\" +.\" ^^^^ This isn't right: fast retransmission will only retransmit +.\" one packet, not all of the delayed packets. .sp -Even if a segment were delayed past the RTO, the Fast Retransmit -mechanism [Jacobson90c] will cause the delayed -packets to be retransmitted at the same time as B.2, avoiding an extra -RTT and therefore causing a very small performance penalty. -.sp We know of no case with a significant probability of occurrence in which timestamps will cause performance degradation by unnecessarily discarding segments. @@ -973,7 +999,7 @@ .sp To make this more quantitative, any clock faster than 1 tick/sec will reject old duplicate segments for link speeds of ~8 Gbps. A 1ms -timestamp clock will work at link speeds up to 8 Tbps (8*10**12) bps! +timestamp clock will work at link speeds up to 8 Tbps (8*10**12 bps)! .sp .LT (b) 0.5i The timestamp clock must not be "too fast". @@ -1124,7 +1150,7 @@ .LT "4.3. Duplicates from Earlier Incarnations of Connection" 0.3i .sp The PAWS mechanism protects against errors due to sequence number -wrap-around on high-speed connection. Segments from an earlier +wrap-around on high-speed connections. Segments from an earlier incarnation of the same connection are also a potential cause of old duplicate errors. In both cases, the TCP mechanisms to prevent such errors depend upon the enforcement of a maximum segment lifetime (MSL) @@ -1179,8 +1205,19 @@ .ne 2 [Braden89] Braden, R., editor, "Requirements for Internet Hosts -- Communication Layers", -RFC 1122, October, 1989 +RFC 1122, October, 1989. +.sp .ne 2 +[Braden98] Braden, B., et al, +"Recommendations on Queue Management and Congestion Avoidance in the Internet", +RFC 2309, April, 1998. +.sp +.ne 2 +[Bradner97] +S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", +RFC 2119, March 1997. +.sp +.ne 2 [Clark87] Clark, D., Lambert, M., and L. Zhang, "NETBLT: A Bulk Data Transfer Protocol", RFC 998, MIT, March 1987. .sp @@ -1335,6 +1372,8 @@ .sp So, the MSS value to be sent in an MSS option should be equal to the effective MTU minus the fixed IP and TCP headers. +.\" But you don't know the effective MTU when sending an initial SYN +.\" and doing PMTU discovery Since both IP and TCP options are ignored when calculating the value for the MSS option, if there are any IP or TCP options to be sent in a packet, @@ -1361,6 +1400,9 @@ fragmented, and packets sent with the constraints in the lower right of this grid will cause IP fragmentation, the only way to guarantee that this doesn't happen is for +.\" It's not the "only way" - the other way is to confine +.\" the behavior to the first column (MSS adjusted to include +.\" options), since that's always conservative. the data sender to decrease the TCP data length by the size of the IP and TCP options. And since the sender will be adjusting the TCP data @@ -1439,6 +1481,8 @@ not the major contributor to this problem; the RTT is the limiting factor in how quickly connections can be opened and closed. Therefore, this problem will be no worse at high transfer speeds. +.\" It is worse at high transfer speeds, because you can sustain +.\" more connections per second. .sp .LT (b) 0.5i Allow old duplicate segments to expire. @@ -1526,9 +1570,9 @@ is disabled. The Karn algorithm disables all RTT measurements during retransmission, since it is ambiguous whether the ACK is -is for the original packet, or the retransmitted packet. +for the original packet, or the retransmitted packet. With Timestamps, that ambiguity is removed since the TSecr -in the ACK will contain the TSval from which ever data +in the ACK will contain the TSval from whichever data packet made it to the destination. .sp .LT (b) 0.5i @@ -1552,7 +1596,7 @@ to fill in the SEG.WND value, not SND.WND. .sp .LT (d) 0.5i -New pseudo-code summary has been added in Appendix E. +A new pseudo-code summary has been added in Appendix E. .sp .LT (e) 0.5i Appendix A has been expanded with information about @@ -1584,7 +1628,7 @@ Clock Values my.TSclock: Local source of 32-bit timestamp values - my.TSclock.rate: Period of my.TSclock (1 ms to 1 sec). + my.TSclock.rate: Tick granularity of my.TSclock (1 ms to 1 sec). Per-Connection State Variables @@ -1649,7 +1693,7 @@ (my.TSclock - SEG.TSecr)*my.TSclock.rate ) ; } - if Segment contains WSopt) then { + if (Segment contains WSopt) then { Snd.wind.scale = SEG.WSopt; Snd.WS.OK = TRUE; } @@ -1701,6 +1745,9 @@ else Update_SRTT( /* for compatibility */ (my.TSclock - Start.Time)/my.TSclock.rate); + ** Won't this update the RTT estimate on every + ** segment rather than once per window, requiring + ** new EWMA constants? } } @@ -1972,7 +2019,15 @@ .ne 3 .LT "Security Considerations" 0.3i .sp -Security issues are not discussed in this memo. +"Security issues are not discussed in this memo" is no longer +acceptable. A few considerations that come to mind: window scaling +makes denial-of-service easier if one can find an endless TCP data source +(such as chargen) since it can be made to send data at a higher rate +than it otherwise could; if mandatory, timestamps could making TCP +spoofing more difficult, because the spoofer has a harder time crafting +the timestamp echoes for the spoofed side of the connection; accepting +RSTs regardless of their timestamps doesn't make it any harder or +easier to spoof RST packets. .sp .LT "Authors' Addresses" 0.3i .sp @@ -1980,10 +2035,10 @@ Van Jacobson University of California Lawrence Berkeley Laboratory -Mail Stop 46A +Mail Stop 50B/2239 Berkeley, CA 94720 .sp -Phone: (415) 486-6411 +Phone: (510) 486-7519 EMail: van@ee.lbl.gov .sp 2 .ne 8 From tcplw-relay@services.BSDI.COM Mon May 4 21:09:37 1998 Delivery-Date: Mon, 04 May 1998 21:09:38 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA16174 for ; Mon, 4 May 1998 21:09:37 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA06181 for ; Mon, 4 May 1998 21:12:02 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id TAA03785 for tcplw-list@bsdi.com; Mon, 4 May 1998 19:08:55 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id TAA03779; Mon, 4 May 1998 19:08:52 -0600 (MDT) Received: from gecko.nas.nasa.gov (gecko.nas.nasa.gov [129.99.34.45]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id TAA21051 env-from (kml@gecko.nas.nasa.gov); Mon, 4 May 1998 19:07:49 -0600 (MDT) Received: from gecko.nas.nasa.gov (kml@localhost) by gecko.nas.nasa.gov (8.8.7/NAS8.8.7) with ESMTP id SAA05984; Mon, 4 May 1998 18:08:46 -0700 (PDT) Message-Id: <199805050108.SAA05984@gecko.nas.nasa.gov> To: David Borman cc: braden@isi.edu, tcplw@bsdi.com Subject: Re: Window Scale option In-reply-to: Your message of "Mon, 04 May 1998 17:11:12 CDT." <199805042211.RAA27660@frantic.bsdi.com> Date: Mon, 04 May 1998 18:08:45 -0700 From: "Kevin M. Lahey" In message <199805042211.RAA27660@frantic.bsdi.com>David Borman writes >A couple of points. First, you don't have to have large buffers >to use the window scale option. In reality, what the window scale >option does is change the granularity of the window updates. As long >as that granularity is smaller than your threshhold for silly window >syndrom avoidance, things will work just fine. A window shift of 4 >allows a megabyte of window, with a window update granularity of 16 >bytes, which is well below any SWS threshhold value. So, using >typical 8K buffers, you can use window scale values of at least >5 or 6 without having any impact on performance. I guess I agree. My only thought is that if we have window scales of up to 11 (1 GB/sec over 100ms link = 27 bits worth of window) we could get into a situation in which the scaling would be over the top. Obviously, hosts behind slow links that use small windows could decide not to echo back the value, or could echo back a smaller value. It isn't clear to me that this is a real big problem. I just like the idea of dynamically changing the value, so perhaps I've got a hammer looking for a pretty rare nail... >So, if bulk-data transfer clients send a window shift option, and >the server automatically turns it around, it shouldn't cause any >problems on the server. In BSD/OS I turn around the window scale, >but I limit it to no more than 4 (changable by sysctl) to keep us from >getting into trouble if we receive a window scale of 13 or 14 and our >receive buffer is only 8K... Sounds great to me. I think that this'll help out enormously as more and more people try to deal with LFNs... >The only reason you don't want to always send a window scale option >of at least 3 or 4 in the SYN is to avoid possible interoperability >problems with older TCPs that don't properly ignore unknown TCP >options, especially if there is no way that the application will ever >be able to take advantage of it (i.e, it doesn't have a lot of data >to transfer). Heck, since we're supposed to send the option even when we set the shift value to 0, we might as well start to default to setting the value to 3 or 4. I'm up for it! Kevin kml@nas.nasa.gov From tcplw-relay@services.BSDI.COM Tue May 5 14:56:39 1998 Delivery-Date: Tue, 05 May 1998 14:56:39 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA12112 for ; Tue, 5 May 1998 14:56:38 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA09331 for ; Tue, 5 May 1998 14:59:05 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id MAA07075 for tcplw-list@bsdi.com; Tue, 5 May 1998 12:54:04 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id MAA07072 for ; Tue, 5 May 1998 12:54:03 -0600 (MDT) Received: from zippy.psc.edu (zippy.psc.edu [128.182.61.149]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id MAA27907 for env-from (mathis@psc.edu); Tue, 5 May 1998 12:52:52 -0600 (MDT) Received: (from mathis@localhost) by zippy.psc.edu (8.8.5/8.8.2) id OAA09661; Tue, 5 May 1998 14:53:47 -0400 (EDT) To: tcplw@bsdi.com Subject: Re: Window Scale option References: <199805042134.OAA05330@gecko.nas.nasa.gov> From: Matt Mathis Date: 05 May 1998 14:53:46 -0400 In-Reply-To: "Kevin M. Lahey"'s message of Mon, 04 May 1998 14:34:50 -0700 Message-ID: <9jaf8wk0qt.fsf@zippy.psc.edu> Lines: 41 X-Mailer: Gnus v5.3/Emacs 19.34 The SYN only restriction is far more problematic for the timestamp option than it is for than the window scale option. For example, if you have a laptop with a radio modem and a 100bT interface, you are likely to find that you are either wasting the skinny link with uncompressible timestamps, or underfilling the LAN because you didn't negotiate timestamps. Although you could implement per-route or per-interface flags to control TCPLW features, the real problem is the pervasive 1323 mindset that new options must never appear after the SYN-ACK. If this mindset is relaxed, I believe it is a 1 line code change to allow timestamps to be turned on at any point. Thus all TCP connections could start without timestamps, and once they enter a regime where timestamps help (due to either PAWS or RTTM) timestamps could be turned on. Unfortunately, RFC1323 is structured such that relaxing this specification requires almost a complete rewrite. I tried it at one point, and had to abandon the project. Is this worth revisiting? About window scale option: The cost of negotiating an excessive window shift is very small - it increases the quantization in the flow control for applications which are receiver limited. This might be an issue to an application that *depends* on being able to advance (or control) the window in tiny increments, but I know of none. In our autotuning TCP the window shift defaults to the smallest value needed to support the largest socket buffer allowed on the system. (As specified by sb_max on most systems). The actual receiver window can then default to some small value, to be updated by the application or other mechanisms as needed. See ftp://ftp.psc.edu/pub/networking/papers/autotune_sigcomm98.ps Thanks, --MM-- From tcplw-relay@services.BSDI.COM Tue May 5 15:13:37 1998 Delivery-Date: Tue, 05 May 1998 15:13:38 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA12519 for ; Tue, 5 May 1998 15:13:37 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA09430 for ; Tue, 5 May 1998 15:16:03 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id NAA08831 for tcplw-list@bsdi.com; Tue, 5 May 1998 13:13:20 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id NAA08828 for ; Tue, 5 May 1998 13:13:19 -0600 (MDT) From: braden@isi.edu Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id NAA28081 for env-from (braden@ISI.EDU); Tue, 5 May 1998 13:12:15 -0600 (MDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id MAA13992; Tue, 5 May 1998 12:13:05 -0700 (PDT) Date: Tue, 5 May 1998 12:12:53 -0700 Posted-Date: Tue, 5 May 1998 12:12:53 -0700 Message-Id: <199805051912.AA21669@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Tue, 5 May 1998 12:12:53 -0700 To: tcplw@bsdi.com, mathis@psc.edu Subject: Re: Window Scale option Cc: braden@isi.edu *> *> The SYN only restriction is far more problematic for the timestamp *> option than it is for than the window scale option. *> *> For example, if you have a laptop with a radio modem and a 100bT *> interface, you are likely to find that you are either wasting the *> skinny link with uncompressible timestamps, or underfilling the LAN *> because you didn't negotiate timestamps. Although you could implement *> per-route or per-interface flags to control TCPLW features, the real *> problem is the pervasive 1323 mindset that new options must never *> appear after the SYN-ACK. Matt, I would not call it a "mindset", I would call it concern about (possible lack of) interoperability. However, the issue of breaking some TCPs with options on non-SYN segments may well be less of a concern than it was 8 years ago. In any case, I see no reason why TCPs cannot exchange timestamp options n the SYN exchange to enable the feature, then suspend sending time stamps whenever they want (e.g., when the connection throughput falls below some threshold?) Am I missing something? Bob From tcplw-relay@services.BSDI.COM Tue May 5 16:02:27 1998 Delivery-Date: Tue, 05 May 1998 16:02:27 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA13749 for ; Tue, 5 May 1998 16:02:27 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA09743 for ; Tue, 5 May 1998 16:04:52 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id OAA13235 for tcplw-list@bsdi.com; Tue, 5 May 1998 14:01:54 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id OAA13230 for ; Tue, 5 May 1998 14:01:53 -0600 (MDT) Received: from zippy.psc.edu (zippy.psc.edu [128.182.61.149]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id OAA28540 for env-from (mathis@psc.edu); Tue, 5 May 1998 14:00:49 -0600 (MDT) Received: (from mathis@localhost) by zippy.psc.edu (8.8.5/8.8.2) id QAA09864; Tue, 5 May 1998 16:01:20 -0400 (EDT) To: braden@isi.edu Cc: tcplw@bsdi.com Subject: Re: Window Scale option References: <199805051912.AA21669@gra.isi.edu> From: Matt Mathis Date: 05 May 1998 16:01:19 -0400 In-Reply-To: braden@ISI.EDU's message of Tue, 5 May 1998 12:12:53 -0700 Message-ID: <9j7m40jxm8.fsf@zippy.psc.edu> Lines: 16 X-Mailer: Gnus v5.3/Emacs 19.34 >In any case, I see no reason why TCPs cannot exchange timestamp options >n the SYN exchange to enable the feature, then suspend sending >time stamps whenever they want (e.g., when the connection throughput >falls below some threshold?) Am I missing something? I considered this approach, but the difficulty is that there is no distiction between "timestamp" and "timestamp reply". Thus turning off timestamps requires having some way to discover that the other end isn't using them. For example the value zero could be used to indicate that a reply is not needed. I have long since forgotten the details.... --MM-- From tcplw-relay@services.BSDI.COM Tue May 5 16:03:22 1998 Delivery-Date: Tue, 05 May 1998 16:03:22 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA13778 for ; Tue, 5 May 1998 16:03:21 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA09753 for ; Tue, 5 May 1998 16:05:48 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id OAA13447 for tcplw-list@bsdi.com; Tue, 5 May 1998 14:03:21 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id OAA13444 for ; Tue, 5 May 1998 14:03:20 -0600 (MDT) From: braden@isi.edu Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id OAA28568 for env-from (braden@ISI.EDU); Tue, 5 May 1998 14:02:16 -0600 (MDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id NAA15569; Tue, 5 May 1998 13:03:17 -0700 (PDT) Date: Tue, 5 May 1998 13:03:06 -0700 Posted-Date: Tue, 5 May 1998 13:03:06 -0700 Message-Id: <199805052003.AA21704@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Tue, 5 May 1998 13:03:06 -0700 To: braden@isi.edu, mathis@psc.edu Subject: Re: Window Scale option Cc: tcplw@bsdi.com *> *> I considered this approach, but the difficulty is that there is no *> distiction between "timestamp" and "timestamp reply". Thus turning *> off timestamps requires having some way to discover that the other end *> isn't using them. For example the value zero could be used to indicate *> that a reply is not needed. *> *> I have long since forgotten the details.... *> Me too. *> --MM-- *> *> *> From tcplw-relay@services.BSDI.COM Tue May 5 17:49:08 1998 Delivery-Date: Tue, 05 May 1998 17:49:09 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA15979 for ; Tue, 5 May 1998 17:49:08 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA10304 for ; Tue, 5 May 1998 17:51:35 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id PAA24243 for tcplw-list@bsdi.com; Tue, 5 May 1998 15:48:49 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id PAA24203 for ; Tue, 5 May 1998 15:48:47 -0600 (MDT) From: braden@isi.edu Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id PAA29856 for env-from (braden@ISI.EDU); Tue, 5 May 1998 15:47:39 -0600 (MDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id OAA19308; Tue, 5 May 1998 14:48:42 -0700 (PDT) Date: Tue, 5 May 1998 14:48:31 -0700 Posted-Date: Tue, 5 May 1998 14:48:31 -0700 Message-Id: <199805052148.AA21759@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Tue, 5 May 1998 14:48:31 -0700 To: braden@isi.edu, mathis@psc.edu Subject: Re: Window Scale option Cc: tcplw@bsdi.com *> *> I considered this approach, but the difficulty is that there is no *> distiction between "timestamp" and "timestamp reply". Thus turning *> off timestamps requires having some way to discover that the other end *> isn't using them. For example the value zero could be used to indicate *> that a reply is not needed. *> It isn't clear to me that any bad thing happens if one end simply refrains from sending a TSopt even though it could send it. The other end could take this as a signal to itself stop sending TSopts. (We would have to make sure this cannot confuse PAWS). Bob From tcplw-relay@services.BSDI.COM Wed May 6 03:33:37 1998 Delivery-Date: Wed, 06 May 1998 03:33:37 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA02418 for ; Wed, 6 May 1998 03:33:36 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA11346 for ; Wed, 6 May 1998 03:36:01 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id BAA11006 for tcplw-list@bsdi.com; Wed, 6 May 1998 01:31:55 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id BAA11003 for ; Wed, 6 May 1998 01:31:54 -0600 (MDT) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id BAA04178 for env-from (thorpej@lestat.nas.nasa.gov); Wed, 6 May 1998 01:30:41 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with SMTP id AAA29254; Wed, 6 May 1998 00:21:37 -0700 (PDT) Message-Id: <199805060721.AAA29254@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: localhost [127.0.0.1] didn't use HELO protocol To: braden@isi.edu Cc: tcplw@bsdi.com, mathis@psc.edu Subject: Re: Window Scale option Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 06 May 1998 00:21:36 -0700 Sender: thorpej@nas.nasa.gov On Tue, 5 May 1998 12:12:53 -0700 braden@isi.edu wrote: > I would not call it a "mindset", I would call it concern about > (possible lack of) interoperability. However, the issue of breaking > some TCPs with options on non-SYN segments may well be less of a > concern than it was 8 years ago. Unfortunately, there's still the concern of intermediate agents (e.g. routers, terminal servers, etc.) completely losing if they encounter non-SYN packets with options. It's not too hard to find recent accounts of people having to disable timestamps because their or their ISP's terminal server or ISDN gateway can't cope with them. (Presumably, they're looking that far into the packet because they're trying to do header compression.) Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: +1 408 866 1912 NAS: M/S 258-5 Work: +1 650 604 0935 Moffett Field, CA 94035 Pager: +1 415 428 6939 From tcplw-relay@services.BSDI.COM Wed May 6 13:20:37 1998 Delivery-Date: Wed, 06 May 1998 13:21:57 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA14801 for ; Wed, 6 May 1998 13:19:16 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA13573 for ; Wed, 6 May 1998 13:21:28 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id LAA03769 for tcplw-list@bsdi.com; Wed, 6 May 1998 11:12:15 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id LAA03765 for ; Wed, 6 May 1998 11:12:14 -0600 (MDT) From: braden@isi.edu Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id KAA07819 for env-from (braden@ISI.EDU); Wed, 6 May 1998 10:37:08 -0600 (MDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id JAA18068; Wed, 6 May 1998 09:38:05 -0700 (PDT) Date: Wed, 6 May 1998 09:37:53 -0700 Posted-Date: Wed, 6 May 1998 09:37:53 -0700 Message-Id: <199805061637.AA22258@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Wed, 6 May 1998 09:37:53 -0700 To: braden@isi.edu, thorpej@nas.nasa.gov Subject: Re: Window Scale option Cc: tcplw@bsdi.com, mathis@psc.edu *> *> Unfortunately, there's still the concern of intermediate agents (e.g. *> routers, terminal servers, etc.) completely losing if they encounter *> non-SYN packets with options. *> Routers should not be looking at TCP anyway, but terminal servers are probably the leading location of deficient TCP implementations. *> It's not too hard to find recent accounts of people having to disable *> timestamps because their or their ISP's terminal server or ISDN gateway *> can't cope with them. (Presumably, they're looking that far into the *> packet because they're trying to do header compression.) *> So we should continue to be conservative in what we send. Bob *> Jason R. Thorpe thorpej@nas.nasa.gov *> NASA Ames Research Center Home: +1 408 866 1912 *> NAS: M/S 258-5 Work: +1 650 604 0935 *> Moffett Field, CA 94035 Pager: +1 415 428 6939 *> From tcplw-relay@services.BSDI.COM Wed May 6 14:15:33 1998 Delivery-Date: Wed, 06 May 1998 14:16:53 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA17097 for ; Wed, 6 May 1998 14:14:13 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA13864 for ; Wed, 6 May 1998 14:16:35 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id MAA09483 for tcplw-list@bsdi.com; Wed, 6 May 1998 12:11:04 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id MAA09473 for ; Wed, 6 May 1998 12:10:59 -0600 (MDT) Received: from zippy.psc.edu (zippy.psc.edu [128.182.61.149]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id LAA08238 for env-from (mathis@psc.edu); Wed, 6 May 1998 11:04:57 -0600 (MDT) Received: (from mathis@localhost) by zippy.psc.edu (8.8.5/8.8.2) id NAA11815; Wed, 6 May 1998 13:05:58 -0400 (EDT) To: Jason Thorpe Cc: tcplw@bsdi.com Subject: Re: Window Scale option References: <199805060721.AAA29254@lestat.nas.nasa.gov> From: Matt Mathis Date: 06 May 1998 13:05:58 -0400 In-Reply-To: Jason Thorpe's message of Wed, 06 May 1998 00:21:36 -0700 Message-ID: <9j4sz3tjm1.fsf@zippy.psc.edu> Lines: 21 X-Mailer: Gnus v5.3/Emacs 19.34 >Unfortunately, there's still the concern of intermediate agents (e.g. >routers, terminal servers, etc.) completely losing if they encounter >non-SYN packets with options. We ran into this as well, and your diagnosis isn't quite correct. There are a number of VJ header compression implementations that completely and totally botch *all* TCP or IP options. But under VJ compression some packets such as SYNs and retransmissions (data which is non-contigious with the prior segment) are not compressed, so they make it through. These implementations are just busted because they are incorrectly compressing packets containing options. This situation is precisely what started me thinking about initiating timestamps later in the connection. These paths are the very ones that benefit the least and can least afford the overhead of timestamps. Under 1323, the TCP has to know in advance of the SYNACK if timestamps are a gain or loss, and negotiate accordingly. This is way too early, long before TCP has had any opportunity to measure anything useful about the path. --MM-- From tcplw-relay@services.BSDI.COM Wed May 6 14:33:47 1998 Delivery-Date: Wed, 06 May 1998 14:33:47 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA17979 for ; Wed, 6 May 1998 14:33:47 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA13948 for ; Wed, 6 May 1998 14:36:07 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id MAA11185 for tcplw-list@bsdi.com; Wed, 6 May 1998 12:29:31 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id MAA11181 for ; Wed, 6 May 1998 12:29:30 -0600 (MDT) Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id MAA09019 for env-from (huitema@seawind.bellcore.com); Wed, 6 May 1998 12:28:18 -0600 (MDT) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id OAA02239; Wed, 6 May 1998 14:29:19 -0400 (EDT) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id OAA08979; Wed, 6 May 1998 14:29:18 -0400 (EDT) Date: Wed, 6 May 1998 14:29:18 -0400 (EDT) From: Christian Huitema Message-Id: <980506142918.ZM8977@seawind.bellcore.com> In-Reply-To: braden@isi.edu "Re: Window Scale option" (May 6, 9:37am) References: <199805061637.AA22258@gra.isi.edu> X-Mailer: Z-Mail (5.0.0 30July97) To: braden@isi.edu Subject: Window Scale option -- what about null windows ? Cc: tcplw@bsdi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Bob, One of the problems with the current window scale options is that it is based on an old concept -- the idea that the max send window has to be somehow configured to match the number of receive buffers available at the peer. This leads to design choices, such as annoucing scaling options during the SYN exchange. I contend that, if we implement congestion control, we don't actually need a send window. In fact, the send window is trying to protect the sender against a very specific form of congestion, when the receiver rather than the network is the bottleneck. If this is the case, overflowing the receive buffers will trigger a packet loss, and the congestion window will shrink. The congestion window is automatically discovered, and permanently updated. It is not artificially limited to 64K. It can lead to very efficient implementations. Can we propose a specific "window scaling" option that, instead of negotiating an actual window scale, would merely establish an infinite send window ? -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ From tcplw-relay@services.BSDI.COM Wed May 6 15:10:51 1998 Delivery-Date: Wed, 06 May 1998 15:10:51 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA19790 for ; Wed, 6 May 1998 15:10:50 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA14144 for ; Wed, 6 May 1998 15:13:15 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id NAA15031 for tcplw-list@bsdi.com; Wed, 6 May 1998 13:09:35 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id NAA15028 for ; Wed, 6 May 1998 13:09:35 -0600 (MDT) From: braden@isi.edu Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id NAA09339 for env-from (braden@ISI.EDU); Wed, 6 May 1998 13:08:25 -0600 (MDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id MAA24643; Wed, 6 May 1998 12:09:28 -0700 (PDT) Date: Wed, 6 May 1998 12:09:15 -0700 Posted-Date: Wed, 6 May 1998 12:09:15 -0700 Message-Id: <199805061909.AA22343@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Wed, 6 May 1998 12:09:15 -0700 To: braden@isi.edu, huitema@bellcore.com Subject: Re: Window Scale option -- what about null windows ? Cc: tcplw@bsdi.com Christian, Are you saying we don't need window scaling because we don't need to pass (receiver) window information in the protocol? Oh goody, that frees up 16 bits in the TCP header! I think we are out of scope for TCPLW; suggest you send your msg to E2E-interest, and we will see what develops. Bob From tcplw-relay@services.BSDI.COM Thu May 7 00:20:53 1998 Delivery-Date: Thu, 07 May 1998 00:20:54 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA05737 for ; Thu, 7 May 1998 00:20:53 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA15929 for ; Thu, 7 May 1998 00:23:17 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id WAA24177 for tcplw-list@bsdi.com; Wed, 6 May 1998 22:20:11 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id WAA24164; Wed, 6 May 1998 22:20:07 -0600 (MDT) From: braden@isi.edu Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id WAA13369 env-from (braden@ISI.EDU); Wed, 6 May 1998 22:18:59 -0600 (MDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id RAA15662; Wed, 6 May 1998 17:42:57 -0700 (PDT) Date: Wed, 6 May 1998 17:42:45 -0700 Posted-Date: Wed, 6 May 1998 17:42:45 -0700 Message-Id: <199805070042.AA22584@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Wed, 6 May 1998 17:42:45 -0700 To: dab@bsdi.com, vern@ee.lbl.gov Subject: Re: comments on RFC1323.bis Cc: tcplw@bsdi.com *> Some other issues: *> *> * The document doesn't specify the relationship between the *> options. For example, if you use window scaling, then is *> it a MUST that you use timestamps too? Or a SHOULD? Or ... ? *> Vern, I don't think there is any relationship, except the obvious one that PAWS and RTTM both use timestamp options. They are all recommended. *> *> * A significant technical issue: the current RTTM discussion *> does not mention anything about altering the constants used *> for the exponentially-weighted moving average when updating *> the estimate of RTT. Sally Floyd has pointed out that using *> the usual constants is incorrect when the RTT is updated more *> than once per window; their use will result in an RTT estimate *> that is much more sensitive to transient changes in RTT. *> *> I think at a minimum the document needs to point out that *> there is an open issue here. *> Yes! This issue came up in the beginning but was never resolved. How much digital control (or filtering?) theory is required to answer this one? ... *> @@ -333,6 +338,12 @@ *> segment, adding 12 bytes to the 20-byte TCP header. We *> believe that the bandwidth saved by reducing unnecessary *> retransmissions will more than pay for the extra header bandwidth. *> +.\" How does the Timestamps option help with reducing unnecessary *> +.\" retransmissions? It only will if currently the RTO estimates *> +.\" are too low. While some TCP implementations suffer from this *> +.\" problem, most do not. In particular, using the coarse-grained *> +.\" BSD RTO algorithm works quite conservatively. So this argument *> +.\" is not right. Hum. As I recall, this was taken directly from a comment by Van. How about if it says, "We believe that the increased performance resulting from the use of RTTM will more than pay for the extra header bandwidth". If RTTM does not improve performance, why are we doing it??? *> @@ -608,6 +619,8 @@ *> represent the corresponding cumulative acknowledgments. The two *> timestamp fields of the Timestamps option are shown symbolically as *> . Each TSecr field contains the value most recently *> +.\" "most recently received" conflicts with 3.4, which spells out *> +.\" exactly which value is kept My impression was that it did not really conflict, there is just some deliberate ambiguity at this point on what "most recently received" means. *> .nf *> @@ -625,7 +638,11 @@ *> 4. (130) <--- (6) *> *> . . . ( Pause for 60 timestamp clock ticks ) . . . . *> - *> + *> +.\" This formatting is messed up. Epochs 4 and 5 appear *> +.\" twice. In the first 4, TS.Recent is 130, but in the *> +.\" subsequent 5, we have TSecr=120. Also, why in 5 is *> +.\" TSval=1?? *> *> 5. (130) ---> (1) *> *> @@ -636,6 +653,8 @@ *> 5. ... <--- (5) *> *> *> +.\" What is the point of this second, less precisely specified *> +.\" example?? *> I will have to review all this; I thought we had it right in the original document. *> TCP A TCP B *> *> @@ -685,8 +704,8 @@ *> .LT (A) 0.5i *> Delayed ACKs. *> .sp *> -Many TCP's acknowledge only every Kth segment out of a group of *> -segments arriving within a short time interval; this policy is known *> +RFC1122 requires TCP's to acknowledge every 2nd full-sized segment. Nope. It's only a SHOULD. *> +The policy of acknowledging only every 2nd segment is known *> generally as "delayed ACKs". The data-sender TCP must measure the *> effective RTT, including the additional time due to delayed ACKs, or *> else it will retransmit unnecessarily. Thus, when delayed ACKs are in *> @@ -704,7 +723,7 @@ *> situation the sender should be conservative about retransmission. *> Furthermore, it is better to overestimate than underestimate the RTT. *> An ACK for an out-of-order segment should therefore contain the *> -timestamp from the most recent segment that advanced the window. *> +timestamp from the most recent (in-order) segment that advanced the window. ?? How can you advance the window without an in-order segment? Adding the parenthetical phrase seems to me to be confusing without clarifying; am I missing something? *> @@ -939,12 +962,15 @@ *> If B's retransmission was triggered by the "fast retransmit" algorithm, *> i.e., by duplicate ACKs, then the queued segments that caused these *> ACKs must have been received already. *> +.\" .sp *> +.\" Even if a segment were delayed past the RTO, the Fast Retransmit *> +.\" mechanism [Jacobson90c] will cause the delayed *> +.\" packets to be retransmitted at the same time as B.2, avoiding an extra *> +.\" RTT and therefore causing a very small performance penalty. *> +.\" *> +.\" ^^^^ This isn't right: fast retransmission will only retransmit *> +.\" one packet, not all of the delayed packets. (Will have to review this) *> @@ -1179,8 +1205,19 @@ *> .ne 2 *> [Braden89] Braden, R., editor, *> +[Braden98] Braden, B., et al, It is a little-known fact that these two characters are the same person... :-) *> @@ -1972,7 +2019,15 @@ *> .ne 3 *> .LT "Security Considerations" 0.3i *> .sp *> -Security issues are not discussed in this memo. *> +"Security issues are not discussed in this memo" is no longer *> +acceptable. A few considerations that come to mind: window scaling *> +makes denial-of-service easier if one can find an endless TCP data source *> +(such as chargen) since it can be made to send data at a higher rate *> +than it otherwise could; if mandatory, timestamps could making TCP *> +spoofing more difficult, because the spoofer has a harder time crafting *> +the timestamp echoes for the spoofed side of the connection; accepting *> +RSTs regardless of their timestamps doesn't make it any harder or *> +easier to spoof RST packets. *> .sp Gack. This needs discussion... Bob Braden From tcplw-relay@services.BSDI.COM Thu May 7 03:07:51 1998 Delivery-Date: Thu, 07 May 1998 03:07:52 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA12378 for ; Thu, 7 May 1998 03:07:51 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA16235 for ; Thu, 7 May 1998 03:10:14 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id BAA08708 for tcplw-list@bsdi.com; Thu, 7 May 1998 01:07:15 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id BAA08705 for ; Thu, 7 May 1998 01:07:14 -0600 (MDT) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id BAA15152 for env-from (vern@ee.lbl.gov); Thu, 7 May 1998 01:06:06 -0600 (MDT) Received: by daffy.ee.lbl.gov (8.8.8/8.8.5) id AAA06697; Thu, 7 May 1998 00:07:10 -0700 (PDT) Message-Id: <199805070707.AAA06697@daffy.ee.lbl.gov> To: braden@isi.edu Cc: tcplw@bsdi.com Subject: Re: comments on RFC1323.bis In-reply-to: Your message of Wed, 06 May 1998 17:42:45 PDT. Date: Thu, 07 May 1998 00:07:10 PDT From: Vern Paxson > *> * The document doesn't specify the relationship between the > *> options. For example, if you use window scaling, then is > *> it a MUST that you use timestamps too? Or a SHOULD? Or ... ? > *> > > Vern, > > I don't think there is any relationship, except the obvious one that > PAWS and RTTM both use timestamp options. They are all recommended. The relationship I was thinking of was that larger windows allow you to transmit at higher speeds, and hence PAWS is of extra interest. Even if there isn't a relationship between window scaling and timestamps, it seems it would help if the document spells this out, as it's something I found myself wondering as I read it. I guess I'm also wondering whether "They are all recommended" means that a TCP SHOULD implement these, or simply MAY implement them. Since this is standards-track, I think it's important to define what's expected of an implementation. > [changing the EWMA constants] > > Yes! This issue came up in the beginning but was never resolved. > How much digital control (or filtering?) theory is required to > answer this one? Van & I discussed this a while ago, and his hit was that the whole RTO algorithm should be rethought. Since the goal is to form a good estimate of an *upper bound* on RTT, then what's really of interest are maxima of measured RTTs, and not some estimate of the mean RTT plus its variance (which was just an attempt to estimate the maximum, given infrequent sampling). On our joint to-do list is to crunch some alternate algorithms over the TCP traces I gathered for my thesis to see how well they do. So, if you buy the above as a well-grounded statement, then I'd say that this issue remains research, and for 1323.bis should be addressed simply by noting that it is indeed such, and noting that the traditional constants may lead to poor RTO estimates. > How about if it says, "We believe that the increased performance resulting > from the use of RTTM will more than pay for the extra header bandwidth". > > If RTTM does not improve performance, why are we doing it??? Hmmmmm .... I can see a couple of ways in which it might pay off, neither all that compelling. The first is producing tighter estimates of RTO, so that timeout retransmissions become less expensive. That, though, requires first addressing the above research item. The second is that with RTTM you can think about sender-side estimation of network path properties such as bottleneck bandwidth (though you can do these without RTTM if you keep track of each packet in flight anyway). So I guess I'm not convinced we can say that RTTM itself buys anything. I'd certainly be interested in hearing what I'm missing here. > *> +.\" "most recently received" conflicts with 3.4, which spells out > *> +.\" exactly which value is kept > > My impression was that it did not really conflict, there is just some > deliberate ambiguity at this point on what "most recently received" > means. (FWIW: as I read it I formed a mental model that it meant "by golly, the last one that arrived", and was confused because I knew it was more complicated than that.) > *> +RFC1122 requires TCP's to acknowledge every 2nd full-sized segment. > > Nope. It's only a SHOULD. Well, not so clear. 4.2.3.2 says it SHOULD implement a delayed ack; the context implies that this means as opposed to acking every packet. The following text states that acking every 2nd full-sized segment is a SHOULD; but the table in 4.2.5 shows it as a MUST. But I'd be happy with: RFC1122 states that TCP's SHOULD acknowledge every 2nd full-sized segment. My main concern is that the text not imply that ack-every-K is just fine. > *> -timestamp from the most recent segment that advanced the window. > *> +timestamp from the most recent (in-order) segment that advanced the window. > > ?? How can you advance the window without an in-order segment? Adding > the parenthetical phrase seems to me to be confusing without clarifying; > am I missing something? For me, from the earlier phrasing (regarding out-of-order) I had to pause at this point to think "yes, it has to be in-order". But if you find the suggest phrase confusing rather than helpful, then go ahead and disregard it. > *> [Braden89] Braden, R., editor, > *> +[Braden98] Braden, B., et al, > > It is a little-known fact that these two characters are the same > person... :-) I suspected as much! :-) (But I figured that this character likewise had control over their decisions regarding first initials, since they're lead author on both docs, and the above inconsistency is indeed how the docs read ... but if you think you can somehow get their okay on rectifying the cites, then by all means go ahead!) Vern From tcplw-relay@services.BSDI.COM Thu May 7 11:58:13 1998 Delivery-Date: Thu, 07 May 1998 11:58:14 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA20055 for ; Thu, 7 May 1998 11:58:13 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA17481 for ; Thu, 7 May 1998 12:00:40 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id JAA21908 for tcplw-list@bsdi.com; Thu, 7 May 1998 09:57:02 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id JAA21902 for ; Thu, 7 May 1998 09:57:02 -0600 (MDT) From: braden@isi.edu Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id JAA18071 for env-from (braden@ISI.EDU); Thu, 7 May 1998 09:55:53 -0600 (MDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id IAA04376; Thu, 7 May 1998 08:57:00 -0700 (PDT) Date: Thu, 7 May 1998 08:56:47 -0700 Posted-Date: Thu, 7 May 1998 08:56:47 -0700 Message-Id: <199805071556.AA22865@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Thu, 7 May 1998 08:56:47 -0700 To: braden@isi.edu, vern@ee.lbl.gov Subject: Re: comments on RFC1323.bis Cc: tcplw@bsdi.com *> *> I guess I'm also wondering whether "They are all recommended" means that *> a TCP SHOULD implement these, or simply MAY implement them. Since this is *> standards-track, I think it's important to define what's expected of an *> implementation. *> Vern, I didn't think that 'standards track' necessarily implies that the RFC must combine technical definition and Applicability Statement, but it seems like a good idea in this case, at least. It was certainly the intent of the original authors that it ought to be a (strong) SHOULD. However, your comments on RTTM call this into question. *> > [changing the EWMA constants] *> > *> > Yes! This issue came up in the beginning but was never resolved. *> > How much digital control (or filtering?) theory is required to *> > answer this one? *> *> Van & I discussed this a while ago, and his hit was that the whole RTO *> algorithm should be rethought. Since the goal is to form a good estimate *> of an *upper bound* on RTT, then what's really of interest are maxima of *> measured RTTs, and not some estimate of the mean RTT plus its variance *> (which was just an attempt to estimate the maximum, given infrequent *> sampling). On our joint to-do list is to crunch some alternate algorithms *> over the TCP traces I gathered for my thesis to see how well they do. *> *> So, if you buy the above as a well-grounded statement, then I'd say that *> this issue remains research, and for 1323.bis should be addressed simply by *> noting that it is indeed such, and noting that the traditional constants *> may lead to poor RTO estimates. *> Eeeergggg. No, that cannot the right answer. The message you are sending is "You should implement this to improve RTO estimates and get better performance, but if you use the current constants you may get worse RTO estimates and we can't tell you what constants to use". We might as well go home now and forget it. Did you notice that Van did not answer your question? Does that mean there is some terrible flaw in the current scheme, so that NO values of the constants will actually improve the RTO? If the answer is "yes", we should abandon RTTM now; otherwise, we should be able to specify recommended constants in the document, even if they may be improved with subsequent research. *> *> > *> +RFC1122 requires TCP's to acknowledge every 2nd full-sized segment. *> > *> > Nope. It's only a SHOULD. *> *> Well, not so clear. 4.2.3.2 says it SHOULD implement a delayed ack; the *> context implies that this means as opposed to acking every packet. The *> following text states that acking every 2nd full-sized segment is a SHOULD; *> but the table in 4.2.5 shows it as a MUST. *> Ooo, ooo, ooo! You've found a bug in RFC1122!! Bob From tcplw-relay@services.BSDI.COM Thu May 7 16:42:01 1998 Delivery-Date: Thu, 07 May 1998 16:42:01 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA27919 for ; Thu, 7 May 1998 16:41:55 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA18874 for ; Thu, 7 May 1998 16:44:22 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id OAA18227 for tcplw-list@bsdi.com; Thu, 7 May 1998 14:40:23 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id OAA18224 for ; Thu, 7 May 1998 14:40:22 -0600 (MDT) Received: from mail.cerent.com ([209.31.24.98]) by mailfilter.bsdi.com (BSDI-MF 1.0) with SMTP id OAA21064 for env-from (minshall@fiberlane.com); Thu, 7 May 1998 14:39:13 -0600 (MDT) Received: from mailhost.fiberlane.com by mail.cerent.com via smtpd (for mailfilter.BSDI.COM [205.230.225.21]) with SMTP; 7 May 1998 20:35:23 UT Received: from red.mtv.fiberlane.com by intranet1.fiberlane.com with smtp id m0yXXRy-000gypC; Thu, 7 May 1998 13:39:30 -0700 (PDT) Received: from red.mtv.fiberlane.com by red.mtv.fiberlane.com (8.8.7) id NAA06285; Thu, 7 May 1998 13:39:11 -0700 (PDT) Message-Id: <199805072039.NAA06285@red.mtv.fiberlane.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Vern Paxson cc: braden@isi.edu, tcplw@bsdi.com Subject: Re: comments on RFC1323.bis In-reply-to: Your message of "Thu, 07 May 1998 00:07:10 PDT." <199805070707.AAA06697@daffy.ee.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 May 1998 13:39:10 -0700 From: Greg Minshall Maybe i missed an e-mail, but i think the right (conservative) advice is to just update the RTT estimate once per window. From tcplw-relay@services.BSDI.COM Thu May 7 18:52:40 1998 Delivery-Date: Thu, 07 May 1998 18:52:40 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA29573 for ; Thu, 7 May 1998 18:52:35 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA19614 for ; Thu, 7 May 1998 18:55:01 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id QAA29655 for tcplw-list@bsdi.com; Thu, 7 May 1998 16:50:41 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id QAA29652 for ; Thu, 7 May 1998 16:50:40 -0600 (MDT) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id QAA22231 for env-from (vern@ee.lbl.gov); Thu, 7 May 1998 16:49:31 -0600 (MDT) Received: by daffy.ee.lbl.gov (8.8.8/8.8.5) id PAA09087; Thu, 7 May 1998 15:50:36 -0700 (PDT) Message-Id: <199805072250.PAA09087@daffy.ee.lbl.gov> To: braden@isi.edu Cc: tcplw@bsdi.com, floyd@ee.lbl.gov Subject: Re: comments on RFC1323.bis In-reply-to: Your message of Thu, 07 May 1998 08:56:47 PDT. Date: Thu, 07 May 1998 15:50:36 PDT From: Vern Paxson > Did you notice that Van did not answer your question? Does that mean > there is some terrible flaw in the current scheme, so that NO values of > the constants will actually improve the RTO? Sorry, I didn't mean to imply that. Presumably one can find coefficients for the EWMA that will yield estimates similar to what you get with the once-per-window estimator, which we know is basically sound, if quite conservative. However, the coefficients will be a function of the window size, instead of fixed as they are today. Sally believes that figuring out the form for the coefficients to give equivalent behavior isn't all that hard, and will be posting something to the list about this quite soon. > If the answer is "yes", > we should abandon RTTM now; otherwise, we should be able to specify > recommended constants in the document, even if they may be improved > with subsequent research. I think the best we can do in the near-term is recommend coefficients that give equivalent behavior (so this still leaves the question, Why bother with RTTM?). We might hope in the medium-term to have either better coefficients, or a modified estimation algorithm per Van's suggestions. This latter is something I'm going to try to pursue further in my CST (copious spare time), using the NPD data. Vern From tcplw-relay@services.BSDI.COM Thu May 7 20:41:38 1998 Delivery-Date: Thu, 07 May 1998 20:41:38 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA00118 for ; Thu, 7 May 1998 20:41:38 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA19850 for ; Thu, 7 May 1998 20:44:04 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id SAA09669 for tcplw-list@bsdi.com; Thu, 7 May 1998 18:41:04 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id SAA09665 for ; Thu, 7 May 1998 18:41:03 -0600 (MDT) Received: from owl.ee.lbl.gov (owl.ee.lbl.gov [131.243.1.50]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id SAA23092 for env-from (floyd@ee.lbl.gov); Thu, 7 May 1998 18:39:54 -0600 (MDT) Received: by owl.ee.lbl.gov (8.8.8/8.8.5) id RAA03284; Thu, 7 May 1998 17:41:01 -0700 (PDT) Message-Id: <199805080041.RAA03284@owl.ee.lbl.gov> To: tcplw@bsdi.com Subject: Re: comments on RFC1323.bis Date: Thu, 07 May 1998 17:41:01 PDT From: Sally Floyd *> * A significant technical issue: the current RTTM discussion *> does not mention anything about altering the constants used *> for the exponentially-weighted moving average when updating *> the estimate of RTT. Short summary: >From a quick look, I think that you could make a small change to the weight in the exponential weighted moving average, and get a "time constant" (in numbers of samples averaged, not in seconds) to use for the timestamp option that gives roughly the same "time constant" as the old weight without the timestamp option. Another outstanding question about the timestamp option is whether, with more accurate samples and therefore a more accurate estimate of the mean and mean deviation, it is still sufficient to set the RTO to the average plus *four* times the mean deviation. The more conservative thing to do, in compensation for the more accurate estimates, would be to use a larger multiple for the mean deviation. It seems to me that this leaves open the questions of whether (1) this gives sufficient benefit over the old method; or (2) we should take the hit now and check out other methods for calculating the RTO. However, my *guess* would be that timestamps with the changed weight gives better performance than no timestamps... Details: (The question is whether your average RTT is reflecting the samples of the RTT taken over a number of roundtrip times, or whether your average RTT is only reflecting the samples of the RTT taken from the most recent congestion window of packets.) Assume, for purposes of simple illustration, that the measured RTT abruptly changes to "new", and we are using the old algorithm. Then we update the RTT estimate once per window, as follows: avg <- (1-w) avg_0 + w new Where "avg_0" is the original estimate of the RTT. Now imagine that instead, we are using the timestamp option. We probably have a much more accurate measurement of "new", but we will ignore that for the moment. The key thing is that instead of updating the RTT estimate once, we update it N times, as follows: (We are using weight w1 with the timestamp option.) First packet: avg <- (1-w1) avg_0 + w1 new1 Second packet: avg <- (1-w1) ((1-w1) avg_0 + w1 new1) + w1 new1 N-th packet: avg <- (1-w1)^n avg_0 + sum_i=0^(n-1) (1-w1)^i w1 new1 So if we set w1 so that (1-w1)^n = (1-w), or w1 = ( 1 - (1-w)**(1/n) ), then we get something with the timestamp option that is close to what we get without the timestamp option with weight w. (Unfortunately, I usually do this stuff on mathematica, and things seems to have changed so that I now need a special password to use mathematica. But scripts for very simple numerical experiments on S are below.) That means, for example, that for a weight w of 1/32 without timestamps, the weight with timestamps and a congestion window N of 10 packets would be 1 - (1-w)**(1/N), which is 0.003169835, or roughly 1/256. (Well, actually, N represents not the congestion window, but the number of estimates of the RTT that are averaged-in in one RTT.) (This could use a second check from someone else...) If anyone is moved to investigate further, the ns simulator has an option for TCP timestamps (Agent/TCP set timestamps_ true), but it is not tested in any of the validation tests (even in the validation test for retransmit timers, "test-all-tcp" in tcl/test), so I don't know if it works correctly these days or not. (Analytical investigations are useful if we assume that the RTT samples come from some stationary distribution, but that is clearly a stretch...) - Sally -------------------------------- http://www-nrg.ee.lbl.gov/floyd/ Scripts for S: The function avgg(old, new, N, w0) computes the new average RTT when the old average was "old", the new measurements are all "new", there are N samples of the new measurement, and the weight used in the exponential weighted moving average is "w". Working data will be in /home/pig/u1/floyd/.Data > avgg <- function(avg, new, k, w) { if (k>1) { newavg <- (1-w)*avg + w*new count <- k-1 avgg(newavg, new, count, w) } else (1-w)*avg + w*new } + + + + + + + + > w0 <- 1/32 > N <- 10 > old <- 2 > new <- 1 > w1 <- 1 - (1-w0)**(1/N) > avgg(old, new, 1, w0) ## without timestamps [1] 1.96875 > avgg(old, new, N, w0) ## timestamps, old weight, window = N [1] 1.727976 > avgg(old, new, N, w1) ## timestamps, new weight, window = N [1] 1.96875 > old <- 1 > new <- 2 > avgg(old, new, 1, w0) [1] 1.03125 > avgg(old, new, N, w0) [1] 1.272024 > avgg(old, new, N, w1) [1] 1.03125 > w0 [1] 0.03125 > w1 [1] 0.003169835 From tcplw-relay@services.BSDI.COM Wed May 13 05:19:33 1998 Delivery-Date: Wed, 13 May 1998 05:19:33 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id FAA11382 for ; Wed, 13 May 1998 05:19:32 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id FAA11560 for ; Wed, 13 May 1998 05:21:57 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id DAA20496 for tcplw-list@bsdi.com; Wed, 13 May 1998 03:16:12 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id DAA20493 for ; Wed, 13 May 1998 03:16:12 -0600 (MDT) Received: from ainur.ee.surrey.ac.uk (ainur.ee.surrey.ac.uk [131.227.50.25]) by mailfilter.bsdi.com (BSDI-MF 1.0) with SMTP id DAA15733 for env-from (G.Aggelou@ee.surrey.ac.uk); Wed, 13 May 1998 03:14:50 -0600 (MDT) Received: from ee.surrey.ac.uk by ainur.ee.surrey.ac.uk with smtp (Smail3.1.29.1-ident) id m0yZXdi-0003ZuC; Wed, 13 May 98 10:15 BST Message-ID: <355964C9.1E1139C4@ee.surrey.ac.uk> Date: Wed, 13 May 1998 10:15:54 +0100 From: George Aggelou Organization: University of Surrey, Guildford, England X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: tcplw@bsdi.com Subject: subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit subscribe From tcplw-relay@services.BSDI.COM Wed May 13 07:17:19 1998 Delivery-Date: Wed, 13 May 1998 07:17:19 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA11922 for ; Wed, 13 May 1998 07:17:18 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id HAA11710 for ; Wed, 13 May 1998 07:19:42 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id FAA29115 for tcplw-list@bsdi.com; Wed, 13 May 1998 05:15:37 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id FAA29112 for ; Wed, 13 May 1998 05:15:37 -0600 (MDT) Received: from intelsat1.intelsat.int (intelsat1.intelsat.int [164.86.100.3]) by mailfilter.bsdi.com (BSDI-MF 1.0) with SMTP id FAA16206 for env-from (changr@smtpgate.adm.intelsat.int); Wed, 13 May 1998 05:14:16 -0600 (MDT) Received: (from smap@localhost) by intelsat1.intelsat.int (8.6.10/8.6.10) id HAA30517 for ; Wed, 13 May 1998 07:10:47 -0400 Received: from smtpgate.adm.intelsat.int(164.86.14.240) by intelsat1 via smap (V1.3mjr) id sma006374; Wed May 13 06:10:00 1998 Received: from Connect2 Message Router by smtpgate.adm.intelsat.int via Connect2-SMTP 4.30A; Wed, 13 May 1998 07:14:45 -0400 Message-ID: Date: Wed, 13 May 1998 07:13:00 -0400 From: rory chang Sender: rory chang Reply-To: Organization: INTELSAT To: tcplw@bsdi.com Subject: unsubscribe Importance: Normal MIME-Version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-disposition: inline Content-transfer-encoding: 7bit X-Mailer: Connect2-SMTP 4.30A MHS/SMF to SMTP Gateway unsubscribe From tcplw-relay@services.BSDI.COM Thu May 14 14:12:09 1998 Delivery-Date: Thu, 14 May 1998 14:12:10 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA17942 for ; Thu, 14 May 1998 14:12:08 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA18794 for ; Thu, 14 May 1998 14:14:34 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id MAA11234 for tcplw-list@bsdi.com; Thu, 14 May 1998 12:09:56 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id MAA11231 for ; Thu, 14 May 1998 12:09:55 -0600 (MDT) Received: from ainur.ee.surrey.ac.uk (ainur.ee.surrey.ac.uk [131.227.50.25]) by mailfilter.bsdi.com (BSDI-MF 1.0) with SMTP id MAA04423 for env-from (G.Aggelou@ee.surrey.ac.uk); Thu, 14 May 1998 12:08:30 -0600 (MDT) Received: from ee.surrey.ac.uk by ainur.ee.surrey.ac.uk with smtp (Smail3.1.29.1-ident) id m0ya2Ro-0003WyC; Thu, 14 May 98 19:09 BST Message-ID: <355B3363.FD5E553B@ee.surrey.ac.uk> Date: Thu, 14 May 1998 19:09:39 +0100 From: George Aggelou Organization: University of Surrey, Guildford, England X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: tcplw@bsdi.com Subject: subscribe Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
subscribe
  From tcplw-relay@services.BSDI.COM Wed May 27 23:32:59 1998 Delivery-Date: Wed, 27 May 1998 23:32:59 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA19838 for ; Wed, 27 May 1998 23:32:58 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA14023 for ; Wed, 27 May 1998 23:35:22 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id VAA28400 for tcplw-list@bsdi.com; Wed, 27 May 1998 21:30:01 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id VAA28397 for ; Wed, 27 May 1998 21:30:01 -0600 (MDT) From: info@cigi.com Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id VAA14136 for env-from (info@cigi.com); Wed, 27 May 1998 21:29:16 -0600 (MDT) Received: from cigi.com (slip129-37-113-30.ny.us.ibm.net [129.37.113.30]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id DAA62452 for ; Thu, 28 May 1998 03:29:56 GMT Date: Thu, 28 May 1998 03:29:56 GMT Message-Id: <199805280329.DAA62452@out2.ibm.net> To: tcplw@bsdi.com Subject: Shopping Cart - June Specials! X-UBE-Index: mailfilter.bsdi.com high 2000/1000 Hello, Thought you may be interested in installing a shopping cart to help better service your customers. The shopping cart can be easily modified to suit your website. If you are interested in seeing how this works you can go to my demo shops at: http://www.webjunkie.com/tvmatters/index.html AND http://www.webjunkie.com/cashcart/index.html This cart is loaded with many features, it even comes with a built in search engine. If you would like to find out more about the carts features, you can go to: http://www.webjunkie.com/cashcart/features.html It won't cost you anything but some time and your commitment to get started. We do not ask for any payments up front, all we ask is that you meet the following requirements: 1) Your pages must be hosted on a UNIX type server. (Will work on anything but an NT server) 2) You are serious about purchasing a Shopping Cart to enhance your website. Thats it. If you meet the above requirements, and are ready to add a Shopping Cart to your website, contact us today so we can get started on your working demo. This demo will be created from your own online catalog and will be used as your templates. When you are satisfied with the performance of your working demo and are ready to transfer it over to your server, that is when we ask for payment. PRICES Shopping Cart Program, Manual, $175.00 (reg. $250.00)* and Tech Support. Shopping Cart Program, Manual, Installation and Tech Support. $325.00 (reg. $425.00)* * The discounts will only apply to carts purchased before June 31,1998. Prices will revert back to normal after that. Once we receive payment we will install the Shopping Cart on your server, or provide you with detailed instructions on how to do it yourself, the choice is yours. You will also receive your templates and instructions on how to use them. If you get stuck along the way, we offer tech support via phone or e-mail, for as long as you need it. We can setup many other cgi-scripts, such as Bulletin Boards, Live Chat, Search Engines, Auction Scripts, Classifieds, etc. If you are interested in taking your website to the "next level", or if you have any questions, please, contact me at info@cigi.com Thanks, Eric Webjunkie Productions http://www.webjunkie.com From tcplw-relay@services.BSDI.COM Wed Jun 3 07:50:27 1998 Delivery-Date: Wed, 03 Jun 1998 07:53:33 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA15294 for ; Wed, 3 Jun 1998 07:43:40 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id HAA12429 for ; Wed, 3 Jun 1998 07:45:56 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id FAA02933 for tcplw-list@bsdi.com; Wed, 3 Jun 1998 05:39:32 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id FAA02930 for ; Wed, 3 Jun 1998 05:39:26 -0600 (MDT) Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id KAA06938 for env-from (Michelle.Claude@prism.uvsq.fr); Tue, 2 Jun 1998 10:53:17 -0600 (MDT) Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by soleil.uvsq.fr (8.8.8/jtpda-5.3) with ESMTP id SAA10942 ; Tue, 2 Jun 1998 18:48:51 +0200 (METDST) Received: from bonacieu.prism.uvsq.fr (bonacieu.prism.uvsq.fr [193.51.25.106]) by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with SMTP id SAA06275 ; Tue, 2 Jun 1998 18:46:18 +0200 (MET DST) Message-Id: <1.5.4.32.19980602164754.006b0824@guillotin.prism.uvsq.fr> X-Sender: mic@guillotin.prism.uvsq.fr X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 02 Jun 1998 18:47:54 +0200 To: rabah@auto.emn.fr, rachid@lsa.u-picardie.fr, raczy@lifl.fr, rafaelp@cogs.susx.ac.uk, rafiq@crisv2.univ-pau.fr, raghu@iss.nus.sg, raja@laas.fr, ramak@lifac.ens-cachan.fr, ran@ee.technion.ac.il, rauzy@lumimath.univ-mrs.fr, raynal@irisa.fr, raynaud@irit.fr, raynaud@limhp.univ-paris13.fr, rbb@isid.ernet.in, rcohen@csa.CS.Technion.AC.IL, rdantu@tddcae99.fnts.com, reboulet@jupiter.cert.fr, reed@oboe.cs.uiuc.edu, reeves@eos.ncsu.edu, reinartz@informatik.uni-erlangen.de, reiser@inf.ethz.ch, Remy.Giraud@meteo.fr, richard@univ-tours.fr, rigault@res.enst.fr, rjp@ncp.gpt.co.uk, rlfike@aol.com, rlozano@hds.univ-compiegne.fr, rne@hybrid.com, rnelson@ox.com, robert@mic.laas.fr, roberto.saracco@cselt.stet.it, Roland.Balter@imag.fr, rom@ee.technion.ac.il, Romeo.Ortega@hds.univ-compiegne.fr, Ron.Horn.0090874@nt.com, roro@titan.enst-bretagne.fr, roubella@laas.fr, rouchon@cas.ensmp.fr, roux@laas.fr, rst@kom.e-technik.th-darmstadt.de, rtsai@e0sun3.ccl.itri.org.tw, rubino@irisa.fr, ruget@chorus.fr, saito@hashi.ntt.jp, saive@idris.fr, sal@Mozart1.INSL.McGill.CA, sallet@ilm.loria.fr, salut@laas.fr, samoht@cc.ec-lyon.fr, sanlavil@ucfma.univ-bpclermont.fr, santafecs@aol.com, saracco@cselt.stet.it, sbell@bmth.ac.uk, sbw@ccrl.nj.nec.com, sc@etca.fr, sc6wg4@ntd.comsat.com, schaff@loria.fr, schmid@dfki.uni-kl.de, schnoebelen@imag.fr, schulzrinne@cs.columbia.edu, schuppen@cwi.nl, schwaab@loria.loria.fr, schwartz@ctr.columbia.edu, scott_linke@aus.hp.com, segall@cs.technion.ac.il, serazzi@morgana.elet.polimi.it, Serge.Fdida@masi.ibp.fr, Sergio.Yovine@imag.fr, sericola@irisa.fr, shapiro@prof.inria.fr, shima@hashi.ntt.jp, shimojo@ICS.UCI.EDU, shuli@ee.technion.ac.il, sibilla@irit.fr, sibille@cran.u-nancy.fr, sidou@eurecom.fr, sie@probe.att.com, sigmedia@bellcore.com, silva@etsii.unizar.es, simon@cui.unige.ch, simon@gmc.insa-lyon.fr, simoni@res.enst.fr, simonian@issy.cnet.fr, siron@issy.cnet.fr, skudoh@shako.sk.tsukuba.ac.jp, skumar@cs.columbia.edu, slh@ti.ens-fcl.fr, smith@CS.Berkeley.EDU, snelling@cs.man.ac.uk, sohier@lurpa.ens-cachan.fr, song@loria.fr, soueres@laas.fr, sound@acm.org, soyez@lsa.u-picardie.fr, spaniol@informatik.rwth-aachen.de, ssjoo@tdx.etri.re.kr, sslaven@watson.ibm.com, Stanislaw.Budkowski@hugo.int-evry.fr, stanm@bellcore.com, staples@bnr.ca, stefani@issy.cnet.fr, stelios@csi.forth.gr, Stephane.Gaubert@inria.fr, stephane.michel@der.edf.fr, steve.pollock@umich.edu, steve@o2tech.fr, steve@sics.se, sugi@rd.nacsis.ac.jp, suruagy@di.ufpe.br, svr@shiva.iitm.ernet.in, tabti@inrets.fr, tacquard@univ-tours.fr, takagi@shako.sk.tsukuba.ac.jp, takahasi@nttgoso.ntt.jp, takine@ise.eng.osaka-u.ac.jp, talay@sophia.inria.fr, tandriot@suisse.far.cea.fr, tantawi@watson.ibm.com, tarek@lrps.u-strasbg.fr, tasaka@elcom.nitech.ac.jp, Tayeb.Ben-Meriem@int-evry.fr, tbraun@entropy.inria.fr, tcplw@bsdi.com, tellez@hugo.int-evry.fr, testnet@canarie.ca, thai@masi.ibp.fr, thamel@hds.univ-compiegne.fr, thierry@cert.fr, thom@insa.insa-lyon.fr, thomas.baumann@ia.epfl.ch, thomesse@loria.fr, thuilot@suisse.far.cea.fr, tigli@alto.unice.fr, titli@laas.fr, tjo@bellcore.com, tlp@big.att.com, tmarnet@euriware.fr, tobagi@soe.Stanford.EDU, todd@mcmaster.ca, tohme@res.enst.fr, toinard@fermi.cnam.fr, toinard@labri.u-bordeaux.fr, tomonori@exa.onlab.ntt.jp, tondu@dge.insa-tlse.fr, tony@eng.umd.edu, toure@lagep.univ-lyon1.fr, toutain@rsm.enst-bretagne.fr, towsley@cs.umass.edu, trangia@informatik.uni-wuerzburg.de, treca@urec.fr, trehel@comte.univ-fcomte.fr, tripathi@cs.umd.edu, trobles@dit.upm.es, trystram@imag.fr, tsr@iitk.ernet.in, tsuchida@csl.melco.co.jp, tsuzuki@ccsd.ho.nec.co.jp, tsyum@ie.cuhk.hk, ttlee@ie.cuhk.hk, Tulin.Atmaca@int-evry.fr, uist.chi@Xerox.com, ulfk@tts.lu.se, urban@egd.igd.fhg.de, uriy@math.tau.ac.il, utpal@ece.iisc.ernet.in, valduriez@rodin.inria.fr, vanas@mail.zserv.tuwien.ac.at, vandrome@coria.fr, vberge@hds.univ-compiegne.fr, Vecchi@dassault-elec.fr, venieris@theseas.softlab.ece.ntua.gr, ventre@cps.na.cnr.it, vernadat@poncelet.univ-metz.fr, vernon@cs.wisc.edu, veron@cran.u-nancy.fr, Veronique.Gleize@der.edf.fr, Veronique.Veque@lri.fr, vila@ensam.inra.fr, Vincent.Dumas@inria.fr, virot@univ-orleans.fr, vivalda@ilm.loria.fr, voicu@zeus.genie.uottawa.ca, wagneur@auto.emn.fr, waisum@buckaroo.ho.att.com, wakid@nist.gov, walkup@cs.washington.edu, walter@lss.supelec.fr, wbu@zurich.ibm.com, weber@psc.informatik.uni-frankfurt.de, wertz@auto.ucl.ac.be, westphal@inf.ufsc.br, WGODWIN@chelt.ac.uk, whs@crhc.uiuc.edu, willink@rrl.co.uk, wolfson@ouri.eecs.uic.edu, wonham@odin.control.utoronto.ca, wow@research.att.com, wz@first.gmd.de, xrjo@atc.boeing.com, xu@ilm.loria.fr, yabe@kouken.csl.melco.co.jp, yakov@buckaroo.ho.att.com, yamamoto@comm.eng.osaka-u.ac.jp, yamamoto@cs.umass.edu, yamanouc@trl.ibm.co.jp, yang@nice.etri.re.kr, yang@trix.genie.uottawa.ca, yavatkar@ideal.jf.intel.com, yemini@cs.columbia.edu, yevin@sam.imash.ras.ru, yim@ec-lille.fr, yolande@cs.kuleuven.ac.be, yoshida@netwk.ntt-at.co.jp, youcef@lagep.univ-lyon1.fr, yrobert@lip.ens-lyon.fr, yutaka@kuamp.kyoto-u.ac.jp, Yves.Fouquet@der.edf.fr, yves.quenechdu@supelec.fr, Yves.Sorel@inria.fr, yy@smarts.com, Zack.lakdari@lacp.ismra.fr, zahorjan@cs.washington.edu, zaninotti@korrigan.cea.fr, zapata@lirmm.lirmm.fr, zeyons@onera.fr, zig@atri.curtin.edu.au, ziram@etna.int-evry.fr, zit@ibr.cs.tu-bs.de, zjh1@cornell.edu, zoran@cs.uq.oz.au, zouaoui@masi.ibp.fr, Guy.Pujolle@prism.uvsq.fr From: =?iso-8859-1?Q?Michelle_Claud=E9_=3CMichelle.Claude=40prism.uvsq.fr=3E?=@prism.uvsq.fr Subject: MMNS98 Second IFIP/IEEE International Conference on Management of Multimedia Networks and Services '98 MMNS'98 ************************************** CALL FOR PAPERS EXTENDED TO JUNE 26 ************************************** Versailles, FRANCE November 16-18, 1998 Organized by: DNAC & PRISM Lab., University of Versailles Co-sponsored by: IFIP Working Group 6.4 and 6.6 and IEEE Communications Society see our web page at : http://www.prism.uvsq.fr/~mmns98 From tcplw-relay@services.BSDI.COM Sun Jun 14 15:49:27 1998 Delivery-Date: Sun, 14 Jun 1998 15:49:27 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA07773 for ; Sun, 14 Jun 1998 15:49:26 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA01205 for ; Sun, 14 Jun 1998 15:51:49 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.9.0/8.9.0) id NAA07485 for tcplw-list@bsdi.com; Sun, 14 Jun 1998 13:46:28 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.9.0/8.9.0) with ESMTP id NAA07482 for ; Sun, 14 Jun 1998 13:46:27 -0600 (MDT) Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id NAA26997 for env-from (dab@frantic.bsdi.com); Sun, 14 Jun 1998 13:45:03 -0600 (MDT) Received: (from dab@localhost) by frantic.bsdi.com (8.8.8/8.8.8) id OAA17509; Sun, 14 Jun 1998 14:46:02 -0500 (CDT) Date: Sun, 14 Jun 1998 14:46:02 -0500 (CDT) From: David Borman Message-Id: <199806141946.OAA17509@frantic.bsdi.com> To: tcplw@BSDI.COM Subject: Re: Window Scale option -- what about null windows ? Cc: ariel@world.std.com, braden@isi.edu The attached message got bounced due to sendmail changes on bsdi.com, (I've fixed things now) so I'm manually resending it. -David Borman, dab@bsdi.com Return-Path: Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.9.0/8.9.0) with ESMTP id SAA18208 for ; Sat, 13 Jun 1998 18:50:39 -0600 (MDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id SAA23143 for env-from (ariel@world.std.com); Sat, 13 Jun 1998 18:49:17 -0600 (MDT) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id UAA10620; Sat, 13 Jun 1998 20:50:36 -0400 (EDT) Received: from slip-32-100-55-21.ma.us.ibm.net by world.std.com (TheWorld/Spike-2.0) id AA18431; Sat, 13 Jun 1998 20:50:29 -0400 Message-Id: <35831DE9.B484B1C0@world.std.com> Date: Sat, 13 Jun 1998 20:48:41 -0400 From: Robert Ullmann X-Mailer: Mozilla 4.05 [en] (WinNT; I) Mime-Version: 1.0 To: Christian Huitema Cc: braden@isi.edu, tcplw@bsdi.com Subject: Re: Window Scale option -- what about null windows ? References: <199805061637.AA22258@gra.isi.edu> <980506142918.ZM8977@seawind.bellcore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, (I'm including the whole message because it's been 5 weeks :-) This isn't just a wild idea, it works very well. While working on one major TCP implementation, we had a customer with "fat" satellite links, that were usually limited by buffering at earth stations rather than anything else ... they asked for LW, I found that difficult to code immediately in that particular configuration, so the same idea occurred to me, and I tested by setting window to 384 K (later, essentially *local* buffering constraint) regardless of the remote announcement, and allowing congestion control to work. (I also made some serious improvements to the congestion control to not-so-"slow-start", so this *might* not work as well with vanilla VJ, but I think it would). Result: just dandy. Always ignore dogma. AFAIK, that code is still used in that implementation ... I still like to see window spec'd and do this in TP7 (32 bits, 64 bit seq/ack); but it isn't really absolutely necessary. Making the modulus space big enough (e.g. 64 bits) proves to be much more important.) Robert Ullmann IBM/Lotus Multimedia Christian Huitema wrote: > Bob, > > One of the problems with the current window scale options is that it is > based on an old concept -- the idea that the max send window has to be > somehow configured to match the number of receive buffers available at the > peer. This leads to design choices, such as annoucing scaling options > during the SYN exchange. > > I contend that, if we implement congestion control, we don't actually need > a send window. In fact, the send window is trying to protect the sender > against a very specific form of congestion, when the receiver rather than > the network is the bottleneck. If this is the case, overflowing the > receive buffers will trigger a packet loss, and the congestion window will > shrink. The congestion window is automatically discovered, and permanently > updated. It is not artificially limited to 64K. It can lead to very > efficient implementations. > > Can we propose a specific "window scaling" option that, instead of > negotiating an actual window scale, would merely establish an infinite > send window ? > > -- > Christian Huitema > ---------- > See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ --SAB18209.897785440/services.BSDI.COM-- From tcplw-relay@services.BSDI.COM Mon Jun 15 15:20:21 1998 Delivery-Date: Mon, 15 Jun 1998 15:20:22 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA03689 for ; Mon, 15 Jun 1998 15:20:21 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA05284 for ; Mon, 15 Jun 1998 15:22:43 -0400 (EDT) Received: by services.BSDI.COM (8.9.0/8.9.0) id NAA29506 for tcplw-list@bsdi.com; Mon, 15 Jun 1998 13:18:34 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.9.0/8.9.0) with ESMTP id NAA29503 for ; Mon, 15 Jun 1998 13:18:33 -0600 (MDT) From: braden@isi.edu Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id NAA05454 for env-from (braden@ISI.EDU); Mon, 15 Jun 1998 13:17:07 -0600 (MDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id MAA09444; Mon, 15 Jun 1998 12:18:18 -0700 (PDT) Date: Mon, 15 Jun 1998 12:17:13 -0700 Posted-Date: Mon, 15 Jun 1998 12:17:13 -0700 Message-Id: <199806151917.AA00951@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Mon, 15 Jun 1998 12:17:13 -0700 To: huitema@bellcore.com, ariel@world.std.com Subject: Re: Window Scale option -- what about null windows ? Cc: braden@isi.edu, tcplw@bsdi.com This is certainly not the correct mailing list for this discussion. I suggest end2end-interest. Bob Braden From tcplw-relay@services.BSDI.COM Wed Jul 1 17:07:19 1998 Delivery-Date: Wed, 01 Jul 1998 17:07:19 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA16615 for ; Wed, 1 Jul 1998 17:07:18 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA18536 for ; Wed, 1 Jul 1998 17:09:40 -0400 (EDT) Received: by services.BSDI.COM (8.9.0/8.9.0) id PAA18174 for tcplw-list@bsdi.com; Wed, 1 Jul 1998 15:04:27 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.9.0/8.9.0) with ESMTP id PAA18171 for ; Wed, 1 Jul 1998 15:04:26 -0600 (MDT) Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id PAA11602 for env-from (dab@frantic.bsdi.com); Wed, 1 Jul 1998 15:02:23 -0600 (MDT) Received: (from dab@localhost) by frantic.bsdi.com (8.8.8/8.8.8) id QAA06802 for tcplw@bsdi.com; Wed, 1 Jul 1998 16:04:23 -0500 (CDT) Date: Wed, 1 Jul 1998 16:04:23 -0500 (CDT) From: David Borman Message-Id: <199807012104.QAA06802@frantic.bsdi.com> To: tcplw@BSDI.COM Subject: SPAM filtering turned on Hi everyone, The tcplw@bsdi.com mailing list (and all mail destined for bsdi.com) goes through a BSDI MailFilter box. (See: http://www.bsdi.com/white-papers/war-on-spam http://www.BSDI.COM/products/BMF/ for more details.) As mail passes through the MailFilter box, it gets a score on the probablility that it is SPAM. Non-zero scores cause a "X-UBE-Index: score/thresh" line to be inserted in the message header, with the "thresh" being the threshhold at which the mail will be rejected. Up until now all messages for tcplw@bsdi.com have gone through, just being marked if the are suspected SPAM. I've now had rejection turned on. I don't expect this to cause any legitimate messages to be rejected, but we're dealing with computers and programmers, so anything is possible. In looking over the archive, nothing legitimate has been scored as spam at a level that would have rejected it. If SPAM gets through, I can always lower the threshhold. Questions or comments to me. -David Borman, dab@bsdi.com From tcplw-relay@services.BSDI.COM Wed Jul 8 03:11:43 1998 Delivery-Date: Wed, 08 Jul 1998 03:11:43 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA01385 for ; Wed, 8 Jul 1998 03:11:42 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA07983 for ; Wed, 8 Jul 1998 03:13:59 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.9.0/8.9.0) id BAA15877 for tcplw-list@bsdi.com; Wed, 8 Jul 1998 01:09:40 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.9.0/8.9.0) with ESMTP id BAA15872 for ; Wed, 8 Jul 1998 01:09:40 -0600 (MDT) From: spapad@csi.forth.gr Received: from nemesis.csi.forth.gr (nemesis.csi.forth.gr [139.91.151.3]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id BAA03093 for env-from (spapad@csi.forth.gr); Wed, 8 Jul 1998 01:07:21 -0600 (MDT) Received: from mickey.csi.forth.gr (mickey.csi.forth.gr [139.91.182.40]) by nemesis.csi.forth.gr (8.8.7/ICS-FORTH/V3) with SMTP id KAA01912 for ; Wed, 8 Jul 1998 10:09:34 +0300 (EET DST) Posted-Date: Wed, 8 Jul 1998 10:09:34 +0300 (EET DST) Received: by mickey.csi.forth.gr (5.65v4.0/1.1.8.2/30Jun94-0118PM) id AA19250; Wed, 8 Jul 1998 10:09:33 +0300 Date: Wed, 8 Jul 1998 10:09:33 +0300 Message-Id: <9807080709.AA19250@mickey.csi.forth.gr> Organization: Institute of Computer Science, Foundation for Research and Technology-Hellas (FORTH) Science and Technology Park of Crete Vassilika Vouton, P.O.Box 1385 GR 711 10 Heraklion, Crete, Greece tel.: +30 (81) 39 16 00, fax: +30 (81) 39 16 01 To: tcplw@bsdi.com Subject: ECDL98 - Call for Participation and Preliminary Programme _____________________________________________________________________________ Call for Participation and Preliminary Programme for the Second European Conference on Research and Advanced Technology for Digital Libraries European European IEEE ICS-FORTH University of Union Research Computer Crete Consortium for Society Informatics and Mathematics 19 - 23 September, 1998 Knossos Royal Village, Heraklion, Crete, Greece Web Page: http://www.csi.forth.gr/2EuroDL E-mail: ecdl@cc.uch.gr _____________________________________________________________________________ We cordially invite you to join us at the Second European Conference on Research and Advanced Technology for Digital Libraries, to be held at Heraklion, Crete, Greece, September 19-23. The conference opening session will take place at 9.00a.m. on Monday the 21th of September 1998 and the final session will take place on Wednesday afternoon, the 23th of September 1998. The technical talks are complemented by internationally renowned experts' invited presentations and special sessions, panel discussions, as well as poster and demonstration sessions. The 7th DELOS Workshop on Electronic Commerce will be held jointly with the Second European Conference on Research and Advanced Technology. Tutorials will be organized on the 19th and 20th of September 1998. Please note that early registration deadline is July 31, 1998. A limited number of fellowships for the Conference and also for Tutorials are available. For more information, including registration and fellowship application forms, please consult the appropriate sections of our conference web pages. Details concerning the Conference Programme can be found at the conference web page, under the 'Conference Programme' section, http://www.ics.forth.gr/2EuroDL/programme.html For specific information please consult the appropriate sections of the conference web pages: Paper Sessions - http://www.ics.forth.gr/2EuroDL/highlights/accpapers.html Panel Sessions - http://www.ics.forth.gr/2EuroDL/highlights/panels.html Posters - http://www.ics.forth.gr/2EuroDL/highlights/posters.html Demos - http://www.ics.forth.gr/2EuroDL/highlights/demos.html Tutorials - http://www.ics.forth.gr/2EuroDL/highlights/tutorials.html Invited Speakers - http://www.ics.forth.gr/2EuroDL/highlights/speakers.html Special Sessions - http://www.ics.forth.gr/2EuroDL/highlights/sessions.html 7th DELOS Workshop on Electronic Commerce - http://www.ics.forth.gr/2EuroDL/Delos-7.html Please find attached the Preliminary Conference Programme as well as information on Tutorials and Paper Sessions, including titles and authors. ______________________________________________________________________________ Tutorials http://www.ics.forth.gr/2EuroDL/highlights/tutorials.html ______________________________________________________________________________ SATURDAY, SEPTEMBER 19 Full Day Tutorials Visual Information Systems by Babu M. Mehtre Multimedia Information Retrieval, categorisation, and filtering by Pasquale Savino and Fabrizio Sebastiani Half Day Tutorials Designing Content for the Web of Tomorrow World Wide Web Consortium sponsored Tutorial by Bert Bos Secure Communication and Payments over the Internet by Amir Herzberg SUNDAY, SEPTEMBER 20 Full Day Tutorials Internet Technologies for the Digital Library by Larry Masinter Thesauri for knowledge-based assistance in searching digital libraries by Dagobert Soergel Metadata for Networked Resources by Renato Iannella, Carl Lagoze and Stuart Weibel ______________________________________________________________________________ Preliminary Conference Programme [* implies pending final confirmation] http://www.ics.forth.gr/2EuroDL/programme.html ______________________________________________________________________________ MONDAY, SEPTEMBER 21 8:30 - 9:15 Opening Ceremony C. Nikolaou, ECDL98 Programme Chair G. Arsenis, Minister of Education and Religious Affairs * N. Adam, Digital Libraries Technical Committee, IEEE Computer Society C. Spiraki, Rector, University of Crete E. Economou, Chairman FORTH * S. Orphanoudakis, Vice President ERCIM, Director ICS-FORTH 9:15 - 10:30 Plenary Session A Invited Speaker: D. Ferguson, Chief Architect, Director, Application Development Division, IBM, and IBM Academy, USA 10:30 - 10:45      Coffee Break 10:45 - 12:30 Parallel Session B PS B1 - DELOS Workshop PS B2 - Special Session Organizer: Ann Okerson PS B3 - Paper Session: Architectures for DLs PS B4 - Paper Session: Image DLs 12:30 - 14:00 Lunch Break 14:00 - 16:30 Plenary Session C Invited Speakers: J. O'Donnell, Professor of classical studies, Vice Provost for Computing, University of Pennsylvania, USA A. Friedlander CNRI, Editor of the D-Lib Magazine W. Arms CNRI, Publisher of the D-Lib Magazine 16:30 - 16:45 Coffee Break 16:45 - 18:40 Parallel Session D PS D1 - DELOS Workshop PS D2 - Paper Session: Multilinguality PS D3 - Paper Session: DL Technologies for Libraries PS D4 - Paper Session: Case Studies I - Invited Speaker Y. Ioannidis, Professor, University of Athens ______________________________________________________________________________ TUESDAY, SEPTEMBER 22 8:30 - 10:30 Plenary Session E Invited Speakers M. Maybury, Advanced Information Systems Center The MITRE Corporation E. Gelenbe, Nello L. Teer Jr. Professor and Chair of Electrical and Computer Engineering Duke University, USA 10:30 - 10:45 Coffee Break 10:45 - 12:30 Parallel Session F PS F1 - DELOS Workshop PS F2 - Special Session Organizer: D. Law PS F3 - Paper Session: Case Studies II - Invited Speaker E. Neuhold, R. Ferber, GMD-IPSI PS F4 - Panel Session DL Technology for Health Care Coordinator: S. Orfanoudakis - Paper Session: Navigation and DLs 12:30 - 14:00 Lunch Break 14:00 - 15:15 Plenary Session G Keynote Speaker: G. Papandreou, Alternate Minister for Foreign Affairs, Greece 15:15 - 16:30 Plenary Session H Invited Speaker: V. Jongeneel, Director, Swiss Institute for Bioinformatics Switzerland 16:30 - 16:45 Coffee Break 16:45 - 17:45 Parallel Session I PS I1 - Panel Session Interaction Design in Digital Libraries Coordinator: C. Stephanidis PS I2 - Panel Session Metadata and content-based approaches to resource discovery Coordinator: T. Baker and J. Klavan PS I3 - Paper Session: IR for DLs 17:45 - 19:10 Parallel Session J PS J1 - DELOS Workshop PS J2 - Paper Session: Querying in DLs PS J3 - Paper Session: Human Computer Interaction for DLs ______________________________________________________________________________ WEDNESDAY, SEPTEMBER 23 8:15 - 10:45 Posters and Demos 10:45 - 11:00 Coffee Break 11:00 - 12:30 Parallel Session K PS K1 - DELOS Workshop PS K2 - Paper Session: Natural Language Processing for DLs PS K3 - Panel Session Architectures and services for cultural heritage information Coordinator: P. Constantopoulos PS K4 - Panel Session Federated scientific data repositories for the environment towards global scalable management of environmental information: How useful will they be? What is their potential impact? Shall we save the environment? Coordinator: C. Houstis 12:30 - 14:00 Lunch Break 14:00 - 15:15 Plenary Session L Panel Session EU and US funding policies for Digital Libraries Coordinator: C. Nikolaou 15:30 - 16:45 Plenary Session M Panel Session Findings of the ESPRIT NSF Working Group on Digital Libraries Coordinator: C. Peters 16:45 - 17:00 Closing Remarks Serge Abiteboul, ECDL99 Programme Chair ______________________________________________________________________________ Paper Sessions http://www.ics.forth.gr/2EuroDL/highlights/accpapers.html ______________________________________________________________________________ Architectures for Digital Libraries [Parallel Session B3, Monday 21, 10:45 - 12:30] Session Chair: S. Haridi, Swedish Institute of Computer Science, Sweden Flexible and Extensible Digital Object and Repository Architecture (FEDORA) Sandra Payette, Carl Lagoze Cornell University, USA The Alexandria Digital Library Architecture James Frew, Michael Freeston, Nathan Freitas, Linda Hill, Greg Janee, Kevin Lovette, Robert Nideffer, Terence Smith, Qi Zheng University of California, Santa Barbara, USA A Framework for the Encapsulation of Value-Added Services in Digital Objects Manolis Marazakis, Dimitris Papadakis, Stavros A. Papadakis University of Crete and ICS-FORTH, Greece A Management Architecture for Measuring and Monitoring the Behavior of Digital Libraries Sarantos Kapidakis, ICS-FORTH, Greece, Sotirios Terzis, Trinity College, University of Dublin, Ireland, Jakka Sairamesh, IBM T. J. Watson Research Center, USA Building HyperNavigation Wrappers for Publisher Web-Sites Lukas C. Faulstich, Freie Universitat Berlin, Germany, Myra Spiliopoulou, Humboldt-Universitat zu Berlin, Germany ______________________________________________________________________________ Image Digital Libraries [Parallel Session B4, Monday 21, 10:45 - 12:30] Session Chair: S. Abiteboul, INRIA, France Combining Color and Spatial Information for Content-based Image Retrieval Ramin Zabih, Jing Huang Cornell University, USA The Application of Metadata Standards to Video Indexing Jane Hunter University of Queensland, Australia Search and Progressive Image Retrieval from Distributed Image/Video Databases: the SPIRE project Vittorio Castelli, Lawrence D. Bergman, Chung-Sheng Li, John R. Smith IBM Thomas J. Watson Research Center, USA Improving the Spatial-Temporal Clue Based Segmentation by the use of Rhythm Walid Mahdi, Liming Chen, Dominique Fontaine Universite de Technologie de Compiegne, France ______________________________________________________________________________ Multilinguality [Parallel Session D2, Monday 21, 16:45 - 18:40] Session Chair: C. Peters, IEI-CNR, Italy Multilingual Information Retrieval Based on Document Alignment Techniques Martin Braschler, Eurospider Information Technology AG, Switzerland, Peter Schauble, ETH Zurich, Switzerland Experimental Studies on an Applet-based Document Viewer for Multilingual WWW Documents - Functional Extension of and Lessons Learned from Multilingual HTML Shigeo Sugimoto, Myriam Dartois, Jun Ohta, Shigetaka Nakao, Tetsuo Sakaguchi, Koichi Tabata, University of Library and Information Science, Japan, Akira Maeda, Nara Institute of Science and Technology, Japan SIS - TMS A Thesaurus Management System for Distributed Digital Collections Martin Doerr, Irini Fountoulaki ICS-FORTH, Greece Parallel Text Alignment Charles B. Owen, Michigan State University, USA James Ford, Fillia Makedon, Tilmann Steinberg, Dartmouth College, USA ______________________________________________________________________________ DL Technologies for Libraries [Parallel Session D3, Monday 21, 16:45 - 18:40] Session Chair: I. Solvberg, University of Science and Technology, Norway An Analysis of Usage of a Digital Library Steve Jones, Sally Jo Cunningham, Rodger McNab University of Waikato, New Zealand ILLUSTRATED BOOK STUDY: Digital Conversion Requirements of Printed Illustrations Anne R. Kenney, Cornell University, USA, Louis H. Sharpe II, Picture Elements, Inc., USA, Barbara Berger, Cornell University, USA Structuring Facilities in Digital Libraries Peter J. Nuernberg, Aarhus University, Germany Uffe K. Wiil, Aalborg University, Germany John J. Leggett, Texas A&M University, USA E-Referencer: A Prototype Expert System Web Interface to Online Catalogs Christopher Khoo, Soon-Kah Liew, Nanyang Technological University, Singapore Danny C.C. Poo, Teck-Kang Toh, National University of Singapore, Singapore ______________________________________________________________________________ Case Studies I [Parallel Session D4, Monday 21, 16:45 - 18:40] Session Chair: C. Thanos, IEI-CNR, Italy Scientific Workflow Management Invited Speaker: Prof. Yiannis Ioannidis, University of Athens The Planetary Data System. A Case Study in the Development and Management of Meta-Data for a Scientific Digital Library J. Steven Hughes, Susan K. McMahon JPL, California Institute of Technology, USA Performing Arts Data Service - An Online Digital Resource Library Steve Malloch, Carola Boehm, Celia Duffy, Catherine Owen, Stephen Arnold, Tony Pearson University of Glasgow, UK ______________________________________________________________________________ Case Studies II [Parallel Session F3, Tuesday 22, 10:45 - 12:30] Session Chair: C. Houstis, University of Crete and ICS-FORTH, Greece Global Info Invited Speakers: Dr. Erich Neuhold and Dr. Reginald Ferber, GMD-IPSI Invited Paper [title to be announced shortly] Robin Wright Online Manager Cinemedia Invited Paper [title to be announced shortly] Richard Paterson Head of Information and Education Division, British Film Institute ______________________________________________________________________________ Navigation and DLs [Parallel Session F4, Tuesday 22, 11:45 - 12:25] Session Chair: C. Lagoze, Cornell University, USA Learning User Communities for Improving the Services of Information Providers Georgios Paliouras, Christos Papatheodorou, Vangelis Karkaletsis, Costantine Spyropoulos, Victoria Malaveta NCSR Demokritos, Greece Soft Navigation in Product Catalogs Markus Stolze IBM Research Division, Zurich Research Laboratory, Switzerland ______________________________________________________________________________ IR for DLs [Parallel Session I3, Tuesday 22, 16:45 - 17:45] Session chair: P. Schauble, ETH Zurich, Switzerland Mixing and Merging for Spoken Document Retrieval Mark Sanderson, University of Massachusetts, USA Fabio Crestani, University of Glasgow, UK An Integrated Approach to Semantic Evaluation and Content-Based Retrieval of Multimedia Documents A. Knoll, University of Bielefeld, C. Altenschmidt, J. Biskup, University of Dortmund, H.-M. Blüthgen, University of Technology RWTH Aachen, I. Glöckner, University of Bielefeld, S. Hartrumpf, H. Helbig, Fernuniversität Hagen, C. Henning, University of Technology RWTH Aachen, R. Lüling, B. Monien, University of Paderborn, T. Noll, University of Technology RWTH Aachen, N. Sensen, University of Paderborn, Germany Taiscealai: Information Retrieval from an Archive of Spoken Radio News A.F. Smeaton, School of Computer Applications, Dublin City University M. Morony, School of Electronic Engineering, Dublin City University G. Quinn, School of Computer Applications, Dublin City University R. Scaife, School of Electronic Engineering, Dublin City University Ireland ______________________________________________________________________________ Querying in DLs [Parallel Session J2, Tuesday 22, 17:45 - 19:05] Session Chair: H.J. Schek, ETH Zurich, Switzerland Semantic Structuring and Visual Querying of Document Abstracts in Digital Libraries Andreas Becks, Stefan Sklorz, Lehrstuhl fur Informatik, RWTH Aachen, Germany, Christopher Tresp, LuFG Theoretische Informatik, RWTH Aachen, Germany Documentation, Cataloging and Query by Navigation: A Practical and Sound Approach F.J.M. Bosman, P.D. Bruza, Th.P. van der Weide, L.V.M. Weusten Signature File Methods for Semantic Query Caching Boris Chidlovskii, Xerox Research Centre Europe, France, Uwe M. Borghoff, Universität der Bundeswehr München, Germany Introducing MIRA: a Retrieval Applications' Development Environment Jose M. Martinez, Jesus Bescos, Guillermo Cisneros Universidad Politecnica de Madrid, Spain ______________________________________________________________________________ Human Computer Interaction for DLs [Parallel Session J3, Tuesday 22, 17:45 - 18:45] Session chair: C. Stephanidis, ICS-FORTH, Greece Interacting With IDL: The Adaptive Visual Interface M. F. Costabile, F. Esposito, G. Semeraro, N. Fanizzi, S. Ferilli Universita di Bari, Italy Evaluating a Visual Navigation System for a Digital Library Anton Leouski, James Allan Visualizing Document Classification: A Search Aid for the Digital Library Yew-Huey Liu, Paul Dantzig, and Martin Sachs IBM T.J. Watson Research Center, USA, Jim Corey, Mark Hinnebusch and Terry Sullivan Florida Center For Library Automation, USA, Marc Damashek and Jonathan Cohen U.S. Department of Defense, USA ______________________________________________________________________________ Natural Language Processing for DLs [Parallel Session K2, Wednesday 23, 11:00 - 12:20] Session Chair: S. Weibel, OCLC, USA A Linguistically Motivated Probabilistic Model of Information Retrieval Djoerd Hiemstra University of Twente, The Netherlands The C-value/NC-value method of Automatic Recognition for Multi-Word Terms Katerina Frantzi, Sophia Ananiadou, Manchester Metropolitan University, UK, Junichi Tsujii, University of Tokyo, Japan Comparing the Effect of Syntactic vs. Statistical Phrase Indexing Strategies for Dutch Wessel Kraaij, Institute of Applied Physics, TNO, The Netherlands, Renee Pohlmann, Utrecht University, The Netherlands Reduction of Expanded Search Terms for Fuzzy English-text Retrieval Manabu Ohta, University of Tokyo, Japan, Atsuhiro Takasu, Jun Adachi National Center for Science Information Systems, Japan From tcplw-relay@services.BSDI.COM Sat Jul 18 06:15:26 1998 Delivery-Date: Sat, 18 Jul 1998 06:15:26 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA27749 for ; Sat, 18 Jul 1998 06:15:25 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id GAA29795 for ; Sat, 18 Jul 1998 06:15:18 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.9.0/8.9.0) id EAA10239 for tcplw-list@bsdi.com; Sat, 18 Jul 1998 04:12:19 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.9.0/8.9.0) with ESMTP id EAA10236 for ; Sat, 18 Jul 1998 04:12:18 -0600 (MDT) Received: from nemesis.csi.forth.gr (nemesis.csi.forth.gr [139.91.151.3]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id EAA27740 for env-from (spapad@csi.forth.gr); Sat, 18 Jul 1998 04:09:37 -0600 (MDT) Received: from ismene-lane.csi.forth.gr (ismene-lane.csi.forth.gr [139.91.157.51]) by nemesis.csi.forth.gr (8.8.7/ICS-FORTH/V3) with ESMTP id NAA01841 for ; Sat, 18 Jul 1998 13:12:13 +0300 (EET DST) Received: from crete.ics.forth.gr (crete.csi.forth.gr [139.91.190.10]) by ismene-lane.csi.forth.gr (8.8.8/ICS-FORTH/V3) with ESMTP id NAA28011 for ; Sat, 18 Jul 1998 13:12:11 +0300 (EET DST) From: "Stavros A. Papadakis" Received: (from spapad@localhost) by crete.ics.forth.gr (8.8.6/ICS-FORTH/C1) id NAA22797; Sat, 18 Jul 1998 13:10:15 +0300 (EET DST) Date: Sat, 18 Jul 1998 13:10:15 +0300 (EET DST) Posted-Date: Sat, 18 Jul 1998 13:10:15 +0300 (EET DST) Message-Id: <199807181010.NAA22797@crete.ics.forth.gr> Organization: Institute of Computer Science, Foundation for Research and Technology-Hellas (FORTH) Science and Technology Park of Crete Vassilika Vouton, P.O.Box 1385 GR 711 10 Heraklion, Crete, Greece tel.: +30 (81) 39 16 00, fax: +30 (81) 39 16 01 To: tcplw@bsdi.com Subject: Second Call for Participation for ECDL98 _____________________________________________________________________________ Call for Participation Second European Conference on Research and Advanced Technology for Digital Libraries European European ICS-FORTH University of Union Research Crete Consortium for Informatics and Mathematics - IEEE Computer Society - Lambrakis Research Foundation - OTE - FORTHnet - INTRACOM - CaberNet - Air Greece - Ergodata - Swets & Zeitlinger B.V. 19 - 23 September, 1998 Knossos Royal Village, Heraklion, Crete, Greece Web Page: http://www.csi.forth.gr/2EuroDL E-mail: ecdl@cc.uch.gr _____________________________________________________________________________ We cordially invite you to join us at the Second European Conference on Research and Advanced Technology for Digital Libraries, to be held at Heraklion, Crete, Greece, September 19-23. The conference opening session will take place at 9.00a.m. on Monday the 21th of September 1998 and the final session will take place on Wednesday afternoon, the 23rd of September 1998. The technical talks are complemented by internationally renowned experts' invited presentations and special sessions, panel discussions, as well as poster and demonstration sessions. The 7th DELOS Workshop on Electronic Commerce will be held jointly with the Second European Conference on Research and Advanced Technology. Tutorials will be organized on the 19th and 20th of September 1998. Please note that early registration deadline is July 31, 1998. A limited number of fellowships for the Conference and also for Tutorials are available. For more information, including registration and fellowship application forms, please consult the appropriate sections of our conference web pages, http://www.ics.forth.gr/2EuroDL/registration.html and http://www.ics.forth.gr/2EuroDL/fellowships.html Details concerning the Conference Programme can be found at the conference web page, under the 'Conference Programme' section, http://www.ics.forth.gr/2EuroDL/programme.html For specific information please consult the appropriate sections of the conference web pages: Paper Sessions - http://www.ics.forth.gr/2EuroDL/highlights/accpapers.html Panel Sessions - http://www.ics.forth.gr/2EuroDL/highlights/panels.html Posters - http://www.ics.forth.gr/2EuroDL/highlights/posters.html Demos - http://www.ics.forth.gr/2EuroDL/highlights/demos.html Tutorials - http://www.ics.forth.gr/2EuroDL/highlights/tutorials.html Invited Speakers - http://www.ics.forth.gr/2EuroDL/highlights/speakers.html Special Sessions - http://www.ics.forth.gr/2EuroDL/highlights/sessions.html 7th DELOS Workshop on Electronic Commerce - http://www.ics.forth.gr/2EuroDL/Delos-7.html From tcplw-relay@services.BSDI.COM Mon Jul 27 11:21:37 1998 Delivery-Date: Mon, 27 Jul 1998 11:23:33 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA16619 for ; Mon, 27 Jul 1998 11:19:31 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA04307 for ; Mon, 27 Jul 1998 11:19:13 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.9.0/8.9.0) id JAA26867 for tcplw-list@bsdi.com; Mon, 27 Jul 1998 09:13:45 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.9.0/8.9.0) with ESMTP id JAA26861 for ; Mon, 27 Jul 1998 09:13:37 -0600 (MDT) Received: from mailgw1.fhg.de (mailgw1.fhg.de [153.96.1.2]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id EAA14979 for env-from (imc98@egd.igd.fhg.de); Mon, 27 Jul 1998 04:01:06 -0600 (MDT) Received: by mailgw1.fhg.de (fhg.de); Mon, 27 Jul 1998 12:03:29 +0200 (MET DST) X-ENV: (mailgw1.fhg.de) imc98@egd.igd.fhg.de -> X-BULK-CHECK-980727.11.48.53: egd.egd.igd.fhg.de [153.96.43.2] Received: by mailgw1.fhg.de (fhg.de) with SMTP; Mon, 27 Jul 1998 11:48:45 +0200 (MET DST) from brussel.egd.igd.fhg.de Received: by brussel.egd.igd.fhg.de; Mon, 27 Jul 98 11:46:56 +0200 Message-Id: <9807270946.AA00399@brussel.egd.igd.fhg.de> Subject: Reminder: CfP IMC-98 INTERACTIVE APPLICATIONS OF MOBILE COMPUTING Date: Mon, 27 Jul 1998 11:45:10 +0200 X-Sender: imc98@egd.egd.igd.fhg.de X-Mailer: Claris Emailer 2.0v3, January 22, 1998 From: imc98 To: "R. Bowen Loftin" , , "Wojciech Mokrzycki" , "Ivan Herman" , "Hrvoje Dujmic" , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Dear colleague, Please let us remind you of the approaching submission deadline for IMC'98. We cordially invite you to submitt a paper to this workshop. Please feel free to distribute ths CfP to interested colleagues and post it as appropriate. Also, please accept our sincere apologies if you receive multiple copies of this CfP. Thank you very much. With best regards, Bodo Urban Thomas Kirste IMC'98 Conference Chair IMC'98 Program Chair ====================================================================== Preliminary Call for Papers IMC-98 INTERACTIVE APPLICATIONS OF MOBILE COMPUTING Rostock, Germany -- November 24-25, 1998 http://www.egd.igd.fhg.de/~imc98 Submission Deadline: July 31, 1998 ====================================================================== Aims and Scope The availability of ultra-portable mobile computing hardware allows to support the user in virtually all situations of everyday life. Instead of being tied to the desktop, computer assistance is becoming available in any situation, anytime, and anywhere. Environment-sensitive mobile computing devices guide visitors through exhibitions, assist maintenance personnel in repairing complex machinery, and help people by scheduling and keeping track of their personal daily tasks. The use of computing and communications devices becomes an integral part of modern lifestyle, augmenting physical reality with computer-generated information. Providing an optimal support for the user based on mobile computing hardware poses new challenges for developers of interactive graphics an multimedia information systems. New approaches are required for providing database- and middleware-support for mobile multimedia, adequate sensorics and environment monitoring facilities, as well as the cognitive minimal intrusive integration of computer- generated assistive information. The goal of this workshop is to bring together researchers, developers and practitioners in all these areas of interactive mobile information system. The workshop will provide a forum for the discussion of the individual problem areas from an interdisciplinary viewpoint, supporting cross- fertilization and problem awareness between the different research areas of interactive mobile applications. Thematic focus Topics of interest include, but are not limited to: - Database support for mobile, interactive graphics and multimedia applications; transaction, security and replication concepts. - Imaging, visualization and presentation in distributed and mobile environments; integrated use of alternative presentation media. - Adaptive architectures for heterogeneous, dynamic, and resource-limited system infrastructures. - Data and object models for mobile information systems. - Environment sensing technologies, situation and location dependent computing. - User interface strategies and visualization concepts for heterogeneous mobile devices, ranging from PDA to wearable computers. - Modeling concepts for situation and task-dependent assistive support (workflow approaches, cognitive task models). - Interactive mobile applications: case studies, design concepts, experiences. After the successful IMC'96 being held in Rostock during February 1996, IMC'98 will be the second workshop spanning the gap between Interactive Graphics Applications and system technologies for Mobile Computing. Submissions Authors are invited to submit extended abstracts / position papers (4 pages) on completed research or work in progress to the IMC'98 conference secretariat (see below for address). Electronic submission by Email is preferred. Alternatively, you may use our anonymous ftp server ftp.egd.igd.fhg.de, directory /public/imc98 (please send us a note by Email after upload, specifying name, type, and contents of the file) Important Dates July 31: Extended abstracts due. August 31: Notification of acceptance. November 10: Camera ready papers due. Supporting Organizations ACM GI FG 4.1 GI AK 4.0.4 Program committee B. Andersen, Copenhagen Business School, DK B.R. Badrinath, Rutgers Univ, USA U. Baumgarten, TU Munich, D K. Brodlie, Univ. Leeds, UK M.G. Brown, Olivetti & Oracle Research Lab, UK J.F. Buford, GTE Laboratories, USA B. Burg, Motorola Research Paris, F C.H. Cap, Rostock Univ., D N. Davies, Univ. Lancaster , UK J.L. Encarnacao, TU Darmstadt, D S. Fischer, TU Darmstadt, D B. Freisleben, Univ. Siegen, D N. Gerfelder, ZGDV Darmstadt, D B. Herzog, CRCG Providence, USA A. Heuer, Univ. Rostock, D W. Herzner, Research Center Seibersdorf, AT B. Kehrer, ZGDV Rostock, D U. Kersken, Bosch Research, D T. Kirste, Fraunhofer-IGD Rostock, D (Program Chair) K. Meyer-Wegener, TU Dresden, D R. Prang, Volkswagen Research, D B.-O. Schneider, IBM T.J. Watson Research Center, USA S. Schnittger, FAW Ulm, D H. Schumann, Univ. Rostock, D P. Slavik, TH Prag, CZ R. Steinmetz, GMD Darmstadt, D J. Teixeira, Univ. Coimbra, PT B. Urban, Fraunhofer-IGD Rostock, D (Conference Chair) H. Wandke, Humboldt-University Berlin, D I. Wolff, Institut fuer Mobil- u. Satellitenfunktechnik, D Organization IMC-98 Conference Secretariat Fraunhofer-Institute for Computer Graphics J.-Jungius-Str. 11, D-18059 Rostock, Germany Phone: +49 (0) 381 4024-110 Fax: +49 (0) 381 4024-199 Email: imc98@egd.igd.fhg.de http://www.egd.igd.fhg.de/~imc98