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.