TP/IX Working Group R. L. Ullmann Internet Draft Process Software Corporation June 30, 1993 TCP version 7 options 1 Status of this Memo This memo describes experimental option definitions for use with the TP/IX version 7 TCP. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Ullmann DRAFT: expires December 29, 1993 [page 1] Internet draft TCP version 7 options June 30, 1993 2 Contents 1 Status of this Memo . . . . . . . . . . . . . . . . 1 2 Contents . . . . . . . . . . . . . . . . . . . . . . 2 3 Introduction . . . . . . . . . . . . . . . . . . . . 3 4 Selective Acknowledgement . . . . . . . . . . . . . 3 5 Time Stamp . . . . . . . . . . . . . . . . . . . . . 3 6 Record Mark . . . . . . . . . . . . . . . . . . . . 4 7 References . . . . . . . . . . . . . . . . . . . . . 6 8 Author's Address . . . . . . . . . . . . . . . . . . 6 Ullmann DRAFT: expires December 29, 1993 [page 2] Internet draft TCP version 7 options June 30, 1993 3 Introduction This memo presents several options for version 7 of the TCP. Two of them provide for the extensions defined by the TCP Large Windows project not covered in the basic field definitions. The other option helps provide some of the semantics expected of the transport layer by OSI applications, and may be useful to other applications defined on the TCP. 4 Selective Acknowledgement The selective acknowledgement (SACK) option (type = 4) indicates that some block of data, not "connected" to the left (start) edge of the TCP window has been received. It need not be transmitted again by the other TCP and will be acknowledged by the TCP sending the SACK option in the normal way when the window edge arrives at the first sequence number in the block. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = 4 | length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + start sequence number + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + end sequence number + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This acknowledges receipt of bytes between (start) and (end-1). If end is equal to or less than start in sequence space, the option is meaningless, and must be ignored. The SACK option should not be used to acknowledge the FIN (or SYN) sequence number. A selective acknowledgement that attempts to acknowledge the FIN sequence number should be ignored. The selective acknowledgement option may occur more than once in a TCP segment, acknowledging receipt of more than one block of data. A block may represent more than one consecutive segment. It is probably unreasonable to expect the other TCP to use a SACK that acknowledges less than a full segment. 5 Time Stamp The time stamp option (type = 5) is used for enhanced measurement of the round-trip delays of the network path being used for a TCP connection. It contains a timestamp value selected by the sending TCP, and a copy of the (usually) most recently-received timestamp from the other TCP. Ullmann DRAFT: expires December 29, 1993 [page 3] Internet draft TCP version 7 options June 30, 1993 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = 5 | length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Timestamp value + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Echoed timestamp reply + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The timestamp field is only valid when its value is non-zero. The reply field is only valid when the ACK flag is set in the TCP header, and the value of the reply field is non-zero. When the ACK flag is not set, the timestamp reply field (if the option appears) must be zero. Please refer to [RFC1323] for the precise use of this option in round-trip measurements. The version 7 TS option is not used for the PAWS mechanism described therein; the 64-bit sequence space is not expected to wrap within a connection. The exact semantics of the timestamp values used by the (remote) TCP are not specified; the frequency, resolution, and stabilty of the remote clock are not used by the local TCP. The local TCP should only copy specific remote TS values into the echo-reply field. ([RFC1323] specifies that the TS values must be monotonically non-decreasing, for use with PAWS; this may be unnecessary here.) 6 Record Mark The record mark option (type = 6) indicates the boundary of an application record. The record mark is constructed by the TCP service interface at the sender, and passed to the receiver's service interface. It is not used directly by the TCP, except that the TCP may use record marks as hints to where segments might be divided for maximum performance. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = 6 | length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + mark sequence number + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ullmann DRAFT: expires December 29, 1993 [page 4] Internet draft TCP version 7 options June 30, 1993 The mark sequence number identifies the first octet of the following record. This is consistant with the definition of the acknowlegement field, which identifies a point "in between" octets by specifying the number of the following octet. The mark must point somewhere within the segment carrying the option, i.e. it must be between the segment sequence number and the sequence number plus the segment size, inclusive. Receivers may ignore record mark options that point outside the segment. The option may occur any number of times within one segment. There is an implicit record mark at sequence SYN+1, and an implicit mark at sequence FIN. (And remember that these may be the same point.) A sending TCP may prefer to send an explicit mark at SYN+1, possibly on the SYN segment itself; this allows early indication to the receiver's application that record marking is available and will be used. Note that to be useful when a record is sent in exactly one segment, the option marking the record boundary should point at the end of the segment. (I.e. the record mark between two records should be sent with the first record, not the second.) If this is not done, the reciever would have to wait for a subsequent record before being able to pass the first to the application. There are no zero-length records. The record mark itself does not have a sequence number; there is no way to distinguish a repeat of a record mark (in, for example, a segment containing retransmitted data) and thus no way to deliver two or more record marks at the same sequence number. Finally, it may be desireable for the TCP to request network layer conversion prohibition (IP Don't Convert option) to prevent loss of record marking if the network route changes to traverse version 4 systems. (Another possibility is to redefine the high bit of the option type field to be an indicator that the conversion must fail if the option is not translatable; this feature was in a prior version of TP/IX. If such a failure occured, the datagram would be returned with ICMP conversion failed/code 11.) An earlier version of TP/IX specified a TCP flag (M), indicating "more data" in the style of (e.g.) X.25. When the M flag was clear, the segment was the last (or only) part of the application record; when set, it indicated that there was more data to come. The flag method was discarded in favor of the option because it added constraints to the TCP that are undesirable. Like X.25 and OSI TP0, the flag permits a TSDU (Transport Service Data Unit) to span multiple TPDUs, but does not permit the coelescing of multiple small TSDUs into one TPDU, and thence one network datagram. In the TCP architecture, segmentation is entirely in the control of the TCP, and the record marking is only of interest to the application. Ullmann DRAFT: expires December 29, 1993 [page 5] Internet draft TCP version 7 options June 30, 1993 7 References [RFC1323] V. Jacobson, R. T. Braden, D. A. Borman. TCP extensions for high performance. May, 1992. [RFC1475] Robert Ullmann. TP/IX: The Next Internet. Process Software Corporation. June, 1993. [RFC1476] Robert Ullmann. RAP: Internet Route Access Protocol. Process Software Corporation. June, 1993. 8 Author's Address Robert Ullmann Process Software Corporation 959 Concord Street Framingham, MA 01701 USA Phone: +1 508 879 6994 x226 Email: Ariel@Process.COM Ullmann DRAFT: expires December 29, 1993 [page 6]