Next Generation TCP BOF (TCPNG) Reported by Robert Braden/USC Information Sciences Institute Introduction The transition to IP6 requires at least a small modification to TCP and UDP implementations. Since these generally require kernel modifications, some have suggested that this might be a good time to make more significant revisions in TCP. This BOF was convened at the San Jose IETF, at the request of the Transport Area Director, to review the entire range of suggested improvements to TCP, and to decide what approach should be taken to TCP modifications and extension in the near term and perhaps the long term. Bob Braden led the discussion. He expressed regret that Dave Borman was unable to attend, although Borman did eventually get connected via the MBONE. The meeting distinguished TCP6, the minimal changes to operate over IP6, from a TCPng, a wonderful new TCP-like protocol. Braden began by presenting a summary of known suggestions for extensions; later the audience supplied some more. The following list and the slides below reflect the augmented list. Minutes TCP6 needs to solve the following three problems: 1. Provide a pseudo-header with longer addresses, or some equivalent mechanism. The convention for embedding IPv4 addresses in IP6 addresses has the happy property of preserving the TCP/UCP checksum, if we simply expand the addresses in the pseudo-header to 64 bits. It was observed that IP6 has no IP header checksum, so it would be unwise to dispense with the protection provided by the pseudo-header. Steve Deering pointed out that the pseudo-header checks not only the IP addresses but also the length of a segment. An alternative mechanism was suggesting, passing a checksum ``seed'' in a SYN packet, to be used in the rest of the connection. A mis-delivered packet from a different connection would have the wrong seed and its checksum would presumably fail. Huitema suggested a random number for this seed; Matt Mathis suggested that checksum of the pseudo-header. However, this approach does not check the length. 2. Revise the MSS option to handle segments larger than 64KB. It was correctly pointed out that the MSS is concerned only with the largest segment that can be reassembled at the receiver; it is logically independent of the path MTU (although some common implementations of TCP have confused these issues). However, in practice most implementations have an effective MSS that is (much) larger than the path MTU's, so the MSS is seldom a real issue. 3. Provide a mechanism to bound segment lifetimes. Maximum segment lifetime (MSL) is more of an important theoretical problem than a practical one. Theoretically, TCP4's reliability depended upon routers treating the TTL field of the IP header as a maximum queue time in seconds; however, in practice most routers use it strictly as a hop count. IP6 turns this practice into a rule, so TCP6 needs some substitute mechanism to bound segment lifetimes. The only viable approach seems to be to increase the effective MSL, and then engineer the routers to enforce a maximum queueing delay, e.g., 30 seconds per hop, before discarding a packet. Then we must have MSL > N*30 seconds, where N is the maximum Internet diameter. Braden noted that Van Jacobson's TCP timestamps, as embodied in the PAWS mechanism (RFC 1323), do increase MSL to a very large value, but only within the same connection. A possible extension to PAWS would store the latest timestamp per association, solving this problem. Other major proposals for improving TCP without extending its functionality included the following: o Redefine option format to provide more option space; in particular, this would ease the implementation of SACK. o Align header fields for 64-bit processors. o Incorporate the RFC 1323 extensions (large windows, RTTM, and PAWS). o Extend ports to 32 bits. o Move Urgent pointer into the options o Provide ``DEC bit'' in ACKs o Provide trailing checksums o Provide an ``ACK request'' bit o Provide an End-of-Record bit o Include a TCP version field Finally, there were some changes that represented functionality extensions: o Allow renumbering of open connections, to support dynamic host reconfiguration. o Provide support for mobility and multihoming. There was an inconclusive discussion on whether mobility support is needed in the transport layer, or whether it can be exclusively in the IP layer. o Include reliable multicast Since there is a great variety of definitions of reliable multicast service, it is very unlikely to make sense to extend TCP in this direction. o Support transactions (see RFC 1644) o TMUX support o Security support Allison Mankin, the Transport Area Director, presented the recommendation of the Area Directorate. 1. Review text on TCP in the IPv6 specification, expand it for clarity and to handle the MSS/jumbogram issue. Bob Braden and Erik Nordmark took an action to do this. 2. Consider chartering a TranportNG working group, to go beyond TCP6. The Area Directors concerned are particularly in favor of option expansion for SACK, and address-independent TCP. Several people suggested that a recent draft produced by Dave Borman might be an appropriate starting point for such an effort. These recommendations appeared to be accepted by those present.