Network Working Group T. Bova INTERNET-DRAFT T. Krivoruchka Cisco Systems Expires in six months 25 Feburary 1999 RELIABLE UDP PROTOCOL Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This Internet Draft discusses Reliable UDP (RUDP). RUDP is a simple packet based transport protocol. RUDP is based on RFCs 1151 and 908 - Reliable Data Protocol. RUDP is layered on the UDP/IP Protocols and provides reliable in-order delivery (up to a maximum number of retransmissions) for virtual connections. RUDP has a very flexible design that would make it suitable for a variety of transport uses. One such use would be to transport telecommunication signaling protocols. Bova & Krivoruchka [Page 1] Internet Draft Reliable UDP Protocol Feb 1999 TABLE OF CONTENTS 1. Introduction...............................................3 1.1 System Overview.......................................3 1.2 Background............................................5 1.3 Data Structure Format.................................5 1.4 Feature Negotiation..................................16 2. Future Potential Enhancements.............................16 3. References................................................17 4. Author's Addresses........................................17 Bova & Krivoruchka [Page 2] Internet Draft Reliable UDP Protocol Feb 1999 1. Introduction This Internet Draft discusses a simple packet based transport protocol designed to support applications that require a reliable, sequenced packet based transport protocol. RUDP is based on RFCs 1151 and 908 - Reliable Data Protocol. RUDP is layered on the UDP/IP Protocols and provides reliable in-order delivery (up to a maximum number of retransmissions) for virtual connections. 1.1 Background A reliable transport protocol is needed to transport of telephony signaling across IP networks. This reliable transport must be able to provide an architecture for a variety of applications (i.e. signaling protocols) requiring transport over IP. Existing IP protocols have been scrutinized and it has been concluded that a new reliable transport mechanism for telecommunication signaling protocols is needed. This protocol should meet the following criteria: * transport should provide reliable delivery up to a maximum number of retransmissions (i.e. avoid stale signaling messages). * transport should provide in-order delivery. * transport should be a message based. * transport should provide flow control mechanism. * transport should have low overhead, high performance. * characteristics of each virtual connection should be configurable (i.e. timers). * transport should provide a keep-alive mechanism. * transport should provide error detection. * transport should provide for secure transmission. RUDP is designed to allow characteristics of each connection to be individually configured so that many protocols with different transport requirements can be implemented simultaneously on the same platform. 1.3 Data Structure Format 1. Six octet minimum RUDP header for data transmissions Each UDP packet sent by RUDP must start with at least a six octet header. The first octet contains a series of single bit flags. The next three fields are each one octet in size. They are: Header length, Sequence Bova & Krivoruchka [Page 3] Internet Draft Reliable UDP Protocol Feb 1999 number, and Acknowledgment number. These three octets are followed by a two octet checksum. 0 1 2 3 4 5 6 7 8 15 +-+-+-+-+-+-+-+-+---------------+ |S|A|E|R|N|C|T| | Header | |Y|C|A|S|U|H|C|0| Length | |N|K|K|T|L|K|S| | | +-+-+-+-+-+-+-+-+---------------+ | Sequence # + Ack Number | +---------------+---------------+ | Checksum | +---------------+---------------+ Figure 1, RUDP Header Control bits The control bits indicate what is present in the packet. The SYN bit indicate a synchronization segment is present. The ACK bit indicates the acknowledgment number in the header is valid. The EACK bit indicates an extended acknowledge segment is present. The RST bit indicates the packet is a reset segment. The NUL bit indicates the packet is a null segment. The TCS bit indicates the packet is a transfer connection state segment. The SYN, EACK, RST, and TCS bits are mutually exclusive. The ACK bit is always set when the NUL bit is set. The CHK bit indicates whether the Checksum field contains the checksum of just the header or the header and the body (data). If the CHK bit is zero, the Checksum field only contains the checksum of the header. If the CHK bit is one, the Checksum field contains the checksum of the header and data. Header length. The Header length field indicates where user data begins in the packet. If total length of the packet is greater than the value of the header length field, user data exists in the packet. User data cannot be present in packets with the EACK, NULL, or RST bits set. A packet with user data in it always has the ACK bit set and is called a data segment. Sequence number. Each packet contains a sequence number. When a connection is first opened, each peer randomly picks an initial sequence number. This sequence number is used in the SYN segments to open the connection. Each transmitter increments the sequence number before sending a data, null, or reset segment. Bova & Krivoruchka [Page 4] Internet Draft Reliable UDP Protocol Feb 1999 Acknowledgment Number. The acknowledgment number field indicates to a transmitter the last in- sequence packet the receiver has received. Checksum. A checksum is always calculated on the RUDP header to ensure integrity. In addition, the checksum can be calculated on the header and body if the CHK bit is set to one. The checksum algorithm used in RUDP is the same algorithm used in UDP and TCP headers which is the 16-bit one's complement of the one's complement sum of bytes being checksumed. 2. SYN Segment The SYN is used to establish a connection and synchronize sequence numbers between two hosts. The SYN segment also contains the negotiable parameters of the connection. All configurable parameters that the peer must know about are contained in this segment. This includes the maximum number of segments the local RUDP is willing to accept and option flags that indicate the features of the connection being established. A SYN segment must not be combined with user data. A SYN segment is also used to perform an auto reset on a connection. Auto reset is described later. Figure 2 shows a SYN segment. Bova & Krivoruchka [Page 5] Internet Draft Reliable UDP Protocol Feb 1999 0 7 8 15 +-+-+-+-+-+-+-+-+---------------+ | |A| | | | | | | | |1|C|0|0|0|0|0|0| 28 | | |K| | | | | | | | +-+-+-+-+-+-+-+-+---------------+ + Sequence # + Ack Number | +---------------+---------------+ | Vers | Spare | Max # of Out | | | | standing Segs | +---------------+---------------+ | Option Flags | Spare | +---------------+---------------+ | Maximum Segment Size | +---------------+---------------+ | Retransmission Timeout Value | +---------------+---------------+ | Cumulative Ack Timeout Value | +---------------+---------------+ | Null Segment Timeout Value | +---------------+---------------+ | Transfer State Timeout Value | +---------------+---------------+ | Max Retrans | Max Cum Ack | +---------------+---------------+ | Max Out of Seq| Max Auto Reset| +---------------+---------------+ | Connection Identifier | + + | (32 bits in length) | +---------------+---------------+ | Checksum | +---------------+---------------+ Figure 2, SYN segment Sequence Number The sequence number field contains the initial sequence number selected for this connection. Acknowledgment Number This field is valid only if the ACK flag is set. In that case, this field will contain the sequence number of the SYN segment received from the other RUDP. Version The version field contains the version of RUDP. The initial version is one (1). Bova & Krivoruchka [Page 6] Internet Draft Reliable UDP Protocol Feb 1999 Maximum Number of Outstanding Segments The maximum number of segments that should be sent without getting an acknowledgment. This is used by the receiver as a means of flow control. The number is selected during connection initiation and may not be changed later in the life of the connection. This is not a negotiable parameter. Each side must use the value provided by its peer when sending data. Options Flag Field This field of two octets contains a set of options flags that specify the set of optional functions that are desired for this connection. A preliminary subset of flags are defined as follows: Bit # Bit Name Description 0 not used not used, must always be set to 1. 1 CHK Data Checksum enable. If this bit is set then the checksum field will contain a checksum of the entire RUDP packet (header and data). This is a negotiable parameter. 2 REUSE This bit must be set during an auto reset to indicate the previous negotiable parameters should be used. When this bit is set the following fields of the SYN should be set to zero by the sender and must be ignored by the receiver: Maximum Segment Size, Retransmission Timeout Value, Cumulative Ack Timeout Value, Max Retransmissions, Max Cumulative Ack, Max Out of Sequence, and Max Auto Reset. 3-7 Spare Maximum Segment Size The maximum number of octets that can be received by the peer sending the SYN segment. Each peer may specify a different value. Each peer must not send packets greater than the value of this field received from its peer during connection negotiation. This number includes the size of the RUDP header. This is not a negotiable parameter. Retransmission Timeout Value The timeout value for retransmission of unacknowledged packets. This value is specified in milliseconds. The valid range is 100 to 65536. This is a negotiable parameter, both peers must agree on the same value for this parameter. Bova & Krivoruchka [Page 7] Internet Draft Reliable UDP Protocol Feb 1999 Cumulative Ack Timeout Value The timeout value for sending an acknowledgment segment if another segment is not sent. This value is specified in milliseconds. The valid range is 100 to 65536. This is a negotiable parameter, both peers must agree on the same value for this parameter. In addition, this parameter should be smaller than the Retransmission Timeout Value. Null Segment Timeout Value The timeout value for sending a null segment if a data segment has not been sent. Thus, the null segment acts as a keep-alive mechanism. This value is specified in milliseconds. The valid range is 0 to 65536. A value of 0 disables null segments. This is a negotiable parameter, both peers must agree on the same value for this parameter. Transfer State Timeout Value This timeout value indicate the amount of time the state information will be saved for a connection before an auto reset occurs. This value is specified in milliseconds. The valid range is 0 to 65536. This is a negotiable parameter, both peers must agree on the same value for this parameter. A value of 0 indicates the connection will be auto-reset immediately. Max Retrans The maximum number of times consecutive retransmission(s) will be attempted before the connection is considered broken. The valid range for this value is 0 to 255. A value of 0 indicates retransmission should be attempted forever. This is a negotiable parameter, both peers must agree on the same value for this parameter. Max Cum Ack The maximum number of acknowledgments that will be accumulated before sending an acknowledgment if another segment is not sent. The valid range for this value is 0 to 255. A value of 0 indicates an acknowledgment segment will be send immediately when a data, null, or reset segment is received. This is a negotiable parameter, both peers must agree on the same value for this parameter. Max Out of Seq The maximum number of out of sequence packets that will be accumulated before an EACK (Extended Acknowledgement) segment is sent. The valid range for this value is 0 to 255. A value of 0 indicates an EACK will be sent immediately if an out of order segment is received. This is a negotiable parameter, both peers must agree on the same value for this parameter. Bova & Krivoruchka [Page 8] Internet Draft Reliable UDP Protocol Feb 1999 Max Auto Reset The maximum number of consecutive auto reset that will performed before a connection is reset. The valid range for this value is 0 to 255. A value of 0 indicates that an auto reset will not be attempted, the connection will be reset immediately if an auto reset condition occurs. This is a negotiable parameter, both peers must agree on the same value for this parameter. The consecutive auto reset counter is cleared once a connection is opened. Connection Identifier When opening a new connection each peer transmits a connection identifier that is unique among all RUDP current connections. Each side then saves the connection ID received. When an auto reset is performed, the peer shall send the saved connection ID originally received to indicate that an auto reset is being performed on the connection. 3. ACK Segment The ACK Segment is used to acknowledge in-sequence segments. It contains both the next send sequence number and the acknowledgment sequence number in the RUDP header. The ACK segment may be sent as a separate segment, but it should be combined with data whenever possible. Data and Null segments must always include the ACK bit and Acknowledgment Number field. The size of a stand-alone ACK segment is six octets. Figure 3 shows a stand-alone ACK segment. 0 1 2 3 4 5 6 7 8 15 +-+-+-+-+-+-+-+-+---------------+ |0|1|0|0|0|0|0|0| 6 | +-+-+-+-+-+-+-+-+---------------+ | Sequence # | Ack Number | +---------------+---------------+ | Checksum | +---------------+---------------+ Figure 3, Stand-alone ACK segment 4. EACK segment The EACK segment is used to acknowledge segments received out of sequence. It contains the sequence numbers of one or more segments received out of sequence. The EACK is always combined with an ACK in the segment, giving the sequence number of the last segment received in sequence. The header length is variable for the EACK segment. Its minimum value is seven and its maximum value depends on the maximum receive queue length. Figure 4 shows a stand-alone EACK segment. Bova & Krivoruchka [Page 9] Internet Draft Reliable UDP Protocol Feb 1999 0 1 2 3 4 5 6 7 8 15 +-+-+-+-+-+-+-+-+---------------+ |0|1|1|0|0|0|0|0| N + 6 | +-+-+-+-+-+-+-+-+---------------+ | Sequence # | Ack Number | +---------------+---------------+ |1st out of seq |2nd out of seq | | ack number | ack number | +---------------+---------------+ | . . . |Nth out of seq | | | ack number | +---------------+---------------+ | Checksum | +---------------+---------------+ Figure 4, EACK segment 5. RST segment The RST segment is used to close or reset a connection. Upon receipt of an RST segment, the sender must stop sending new packets, but must continue to attempt delivery of packets already accepted from the API. The RST is sent as a separate segment and does not include any data. Figure 5 shows a RST segment. 0 1 2 3 4 5 6 7 8 15 +-+-+-+-+-+-+-+-+---------------+ | |A| | | | | | | | |0|C|0|1|0|0|0|0| 6 | | |K| | | | | | | | +-+-+-+-+-+-+-+-+---------------+ | Sequence # | Ack Number | +---------------+---------------+ | Header Checksum | +---------------+---------------+ Figure 5, RST segment 6. NUL segment The NUL segment is used to determine if the other side of a connection is still active. Thus, the NUL segment performs a keep-alive function. When a NUL segment is received, an RUDP implementation must immediately acknowledge the segment if a valid connection exists and the segment sequence number is the next one in sequence. The segment is then discarded. The NUL must be combined with an ACK in a segment but never combined with user data. Figure 6 shows a NUL segment. Bova & Krivoruchka [Page 10] Internet Draft Reliable UDP Protocol Feb 1999 0 1 2 3 4 5 6 7 8 15 +-+-+-+-+-+-+-+-+---------------+ |0|1|0|0|1|0|0|0| 6 | +-+-+-+-+-+-+-+-+---------------+ | Sequence # | Ack Number | +---------------+---------------+ | Checksum | +---------------+---------------+ Figure 6, NUL segment 7. TCS Segment The TCS is used to transfer the state of connection. Figure 7 shows a TCS segment. 0 1 2 3 4 5 6 7 8 15 +-+-+-+-+-+-+-+-+---------------+ | |A| | | | | | | | |0|C|0|0|0|0|1|0| 12 | | |K| | | | | | | | +-+-+-+-+-+-+-+-+---------------+ | Sequence # | Ack Number | +---------------+---------------+ | Seq Adj Factor| Spare | +---------------+---------------+ | Connection Identifier | + + + | (32 bits in length) | +---------------+---------------+ | Checksum | +---------------+---------------+ Figure 7, TCS segment Sequence Number The sequence number field contains the initial sequence number selected for this connection. Acknowledgment Number The acknowledgment number field indicates to a transmitted that last in- sequence packet the receiver has received. Seq Adj Factor This field is used during transfer of state to adjust sequence numbers between the old and current connections. Bova & Krivoruchka [Page 11] Internet Draft Reliable UDP Protocol Feb 1999 Connection Identifier When opening a new connection each peer transmits a connection identifier that is unique among all current RUDP connections. Each side then saves the connection ID received. This field is used to inform the peer connection of the connection record that is being transferred to this connection. 1.3.1 Detailed Design A separate internet draft is being prepared which details in connections state transitions in Specification and Description Language (SDL) format. It also contains more details on the internal design of RUDP. 1.3.2 Feature Description The following features are supported by RUDP. In the following description, transmitter and receiver refer to either clients or servers that are sending or receiving a data segment respectively on a connection. Client refers to the peer that initiates the connection and Server refers to the peer that listened for a connection. A connection is defined as an interface that serves a unique peer IP address/UDP port pair. A server or a client can have multiple connections on a particular IP address/UDP port, each connection will be with a unique peer IP address/UDP port pair. 1. Retransmission timer. The transmitter has a retransmission timer with a configurable time- out value. This timer is initialized every time a data, null, or reset segment is sent and there is not a segment currently being timed. If an acknowledgment for this data segment is not received by the time the timer expires, all segments that have been sent but not acknowledged are retransmitted. The Retransmission timer is re-started when the timed segment is received, if there is still one or more packets that have been sent but not acknowledged. The recommended value of the retransmission timer is 600 milliseconds. 2. Retransmission Counter. The transmitter maintains a counter of the number of times a segment has been retransmitted. The maximum value of this counter is configurable with a recommended value is 2. If this counter exceeds its maximum, the connection will be considered broken. Refer to paragraph item 14 below, Broken Connection Handling, for a description of how RUDP handles a broken connection. 3. Stand-alone acknowledgments. A stand-alone acknowledgment segment is a segment that contains only acknowledgment information. Its sequence number field contains the sequence number of the next data, null, or reset segment to be sent. Bova & Krivoruchka [Page 12] Internet Draft Reliable UDP Protocol Feb 1999 4. Piggyback acknowledgments. Whenever a receiver sends a data, null, or reset segment to the transmitter, the receiver includes the sequence number of the last in-sequence data, null, or reset segment received from the transmitter in the acknowledgment number field of the header of the segment being sent by the receiver. 5. Cumulative acknowledge counter. The receiver maintains a counter of unacknowledged segments received without an acknowledgment being sent to the transmitter. The maximum value of this counter is configurable. If this counter's maximum is exceeded, the receiver sends either a stand-alone acknowledgment, or an extended acknowledgment if there are currently any out-of-sequence segments. The recommended value for the cumulative acknowledge counter is 3. 6. Out-of-sequence acknowledgments counter. The receiver maintains a counter of the number of segments that have arrived out-of-sequence. Each time this counter exceeds its configurable maximum, an extended acknowledgment segment containing the sequence numbers of all current out-of-sequence segments that have been received is sent to the transmitter. The counter is then reset to zero. The recommended value for the out-of-sequence acknowledgements counter is 3. When a transmitter receives an Extended Acknowledgment, it retransmits the missing data segments to the receiver. 7. Cumulative acknowledge timer. When a receiver has any segments that it has not acknowledged or if it has segments on its out-of-sequence queue, it waits a maximum amount of time before sending a stand-alone acknowledgment or an extended acknowledg- ment, respectively. When this timer expires, if there are segments on the out-of-sequence queue, an extended acknowledgment is sent. Otherwise, if there are any segments currently unacknowledged, a stand-alone acknowledgment is sent. The recommended value of the cumulative acknowledgement timer is 300 milliseconds. The cumulative acknowledge timer is restarted whenever an acknowledgment is sent in a data, null, or reset segment, provided that there are no segments currently on the out-of-sequence queue. If there are segments on the out- of-sequence queue, the timer is not restarted, so that another extended acknowledgment will be sent when it expires again. 8. Null segment timer The client maintains a timer which is started when the connection is opened and is reset every time a data segment is sent. If the client's null segment timer expires, the client sends a null segment to the server. Bova & Krivoruchka [Page 13] Internet Draft Reliable UDP Protocol Feb 1999 The null segment is acknowledged by the server if its sequence number is valid. The server maintains a null segment timer with a time-out value of twice the client's time-out value. The server's timer is reset whenever a data or null segment is received from the client. If the server's null segment timer expires, the connection is considered broken. Refer to paragraph item 14 below, Broken Connection Handling, for a description of how RUDP handles a broken connection. The recommended value of the Null segment timer is 2 seconds. 9. Auto Reset Either side of a connection can initiate an auto reset. An auto reset can be caused by the retransmission count exceeding its maximum, the the expiration of the server's Null segment timer, or the expiration of the transfer state timer. An auto reset will cause both peers to reset their current states including flushing retransmission and out-of-sequence queues and then reset their initial sequence number and re-negotiate the connection. Each peer will notify its Upper Layer Protocol (ULP) of the auto reset. There is a consecutive reset counter that sets the maximum number of auto-reset that can occur without the connection opening. If this counter exceeds its maximum the connection is reset. The recommended value for the consecutive reset counter is 3. 10. Receiver Input Queue Size The size of the receiver's input queue is a configurable parameter. The recommended value of the receiver input queue size is 32 packets. The input queue size acts as a flow control mechanism. 11. Congestion control and slow start RUDP does not provide any congestion control or slow start algorithms. 12. UDP port numbers RUDP doesn't place any restrictions on which UDP port numbers are used. Valid port numbers are ports not defined in RFC 1700. 13. Support for redundant connections If an RUDP connection fails, the Upper Layer Protocol will be signaled and the transfer state timer will be started. The ULP can initiate the transfer of this state to another RUDP connection via an API call and RUDP will transfer the state information to the new connection ensuring that packets are not duplicated or lost. If the ULP does not transfer the state to another connection before the Transfer State Timer expires, the connection state is lost and buffers of the queues of the connection are freed. The time-out value for the Transfer State timer is configurable. The recommended value for the Transfer State timer is 1 second. Bova & Krivoruchka [Page 14] Internet Draft Reliable UDP Protocol Feb 1999 14. Broken connection handling An RUDP connection is considered broken if either of the following situations occur: - The Retransmission Timer expires and the Retransmission Count has been exceeded its maximum. - A server's Null Segment Timer expires. If either of the above two situations occur and the Transfer State timeout value is non-zero, the ULP will be notified of the connection failure via the Connection failure signal of the API and the Transfer State Timer will be started. If the Transfer State Timer expires, an Auto Reset is performed and the ULP is notified via the Connection auto reset signal of the API. If the transfer state timeout value is zero, then an auto reset will be performed immediately when either of the above two situlations occur. The ULP will be notified of a connection failure via the Connection auto reset signal of the API. 15. Retransmission Algorithm Retransmission occurs as a result of receiving an EACK segment or the time-out of the Retransmission timer. When an EACK segment is received. The segments specified in the message are removed from the unacknowledged sent queue. The segments to be retransmitted are determined by examining the Ack Number and the last out of seq ack number in the EACK segment. All segments between but not including these two sequence numbers that are on the unacknowledged sent queue are retransmitted. When a retransmission time-out occurs, all messages on the unacknowledged sent queue are retransmitted. 16. Signals to Upper Layer Protocol (ULP) The following signals are sent to the ULP via the API. These are used to signal asynchronous events to the ULP: Connection open - This signal is generated when the state of the connection transitions to Open. Connection refused - This signal is generated when the state of a connection transitions to the Closed state from other than the Close Wait state. Connection closed - This signal is generated when the state of a connection transitions from the Close Wait state to the Closed state. Bova & Krivoruchka [Page 15] Internet Draft Reliable UDP Protocol Feb 1999 Connection failure - This signal is generated when a connection is declared broken, as described in section 1.3.2, item 15 (Retransmission Algorithm) above. Connection auto reset - This signal is generated when a connection auto resets. This is an indication to the ULP that data may have been lost and RUDP is attempting to return the connection to the Open state. 17. Checksum Algorithm The checksum algorithm used in RUDP is the same algorithm used in UDP and TCP headers which is the 16-bit one's complement of the one's complement sum of data being checksumed. The checksum is calculated over the entire RUDP packet if negotiated at the time the connection was opened. The negotiation is based on setting the CHK bit of the options field in the SYN segment used to open the connection. Otherwise, the checksum is calculated over the RUDP header only. Refer to RFC 1071 for implementation information for this algorithm. 18. FEC RUDP does not define a procedure for generate Forward Error Correction (FEC). It is compatible with FEC algorithms that generate duplicate packets because it will throw away any duplicate packets it receives. 19. Security RUDP will be compatible with the IPsec standard for secure IP communications. 1.4 Feature Negotiation When client initiates a connection its sends a SYN segment which contains the negotiable parameters defined by the ULP via the API. The server can accept these parameters by echoing them back in its SYN with ACK response or propose different parameters in its SYN with ACK response. The client can then choose to accept the parameters sent by the server by sending an ACK to establish the connection or it can refuse the connection by sending send a RST. Features cannot be re-negotiated during an auto reset. 2.0 Future Potential Enhancements RUDP should support a symmetrical mode of operation in addition to the current client/server mode of operation. This would allow both sides to actively start the connection. RUDP should support the ability to expand the sequence and acknowledge fields from their current one octet length to two octets. This will allow transmission windows of greater than 255 buffer to be used. Investigate use of the Nagle algorithm to improve network efficiency. Bova & Krivoruchka [Page 16] Internet Draft Reliable UDP Protocol Feb 1999 3.0 References [1] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, USC/Information Sciences Institute, September 1981. [2] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, August 1980. [3] Postel, J. (ed.), "Transmission Control Protocol", RFC 793, USC/Information Sciences Institute, September 1981. [4] Velten, D., Hinden, R. and Sax, J., "Reliable Data Protocol", RFC 908, BBN Communications Corporation, July 1984. [5] Partridge, C. and Hinden, R., "Version 2 of the Reliable Data Protocol", RFC 1151, BBN Corporation, April 1990. [6] Braden, R., "Computing the Internet Checksum", RFC 1071, ISI, September 1988 [7] V. Jacobson, "Congestion Avoidance and Control," Computer Communication Review, Val. 18, no. 4, pp. 314-329, Aug. 1988. [8] W. Stevens, RFC 2001 “TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms”, January 1997 [9] V. Jacobson, "Modified TCP Congestion Avoidance Algorithm", April 30, 1990. [10] Z. Wang, J. Crowcroft, A Dual-Window Model for Flow and Congestion Control, The Distributed Computing Engineering Journal, Institute of Physics/British Computer Society/IEEE, Vol 1, No 3, page 162-172, May 1994. [11] Romanow, Allyn, "TCP over ATM: Some Performance Results", ATM Forum/93-784 4.0 Author's Addresses Tom Bova Tel: +1-703-484-3331 Cisco Systems Email: tbova@cisco.com 13615 Dulles Technology Drive Herndon, VA 20171 USA Ted Krivoruchka Tel: +1-703-484-3325 Cisco Systems Email: tedk@cisco.com 13615 Dulles Technology Drive Herndon, VA 20171 USA