home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 94dec / tcpng-minutes-94dec.txt < prev   
Text File  |  1995-02-28  |  6KB  |  145 lines
  1.  
  2. Next Generation TCP BOF (TCPNG)
  3.  
  4. Reported by Robert Braden/USC Information Sciences Institute
  5.  
  6.  
  7. Introduction
  8.  
  9. The transition to IP6 requires at least a small modification to TCP and
  10. UDP implementations.  Since these generally require kernel
  11. modifications, some have suggested that this might be a good time to
  12. make more significant revisions in TCP. This BOF was convened at the San
  13. Jose IETF, at the request of the Transport Area Director, to review the
  14. entire range of suggested improvements to TCP, and to decide what
  15. approach should be taken to TCP modifications and extension in the near
  16. term and perhaps the long term.  Bob Braden led the discussion.  He
  17. expressed regret that Dave Borman was unable to attend, although Borman
  18. did eventually get connected via the MBONE.
  19.  
  20. The meeting distinguished TCP6, the minimal changes to operate over IP6,
  21. from a TCPng, a wonderful new TCP-like protocol.  Braden began by
  22. presenting a summary of known suggestions for extensions; later the
  23. audience supplied some more.  The following list and the slides below
  24. reflect the augmented list.
  25.  
  26.  
  27. Minutes
  28.  
  29. TCP6 needs to solve the following three problems:
  30.  
  31.  
  32.   1. Provide a pseudo-header with longer addresses, or some equivalent
  33.      mechanism.
  34.  
  35.      The convention for embedding IPv4 addresses in IP6 addresses has
  36.      the happy property of preserving the TCP/UCP checksum, if we simply
  37.      expand the addresses in the pseudo-header to 64 bits.
  38.  
  39.      It was observed that IP6 has no IP header checksum, so it would be
  40.      unwise to dispense with the protection provided by the
  41.      pseudo-header.  Steve Deering pointed out that the pseudo-header
  42.      checks not only the IP addresses but also the length of a segment.
  43.      An alternative mechanism was suggesting, passing a checksum
  44.      ``seed'' in a SYN packet, to be used in the rest of the connection.
  45.  
  46.      A mis-delivered packet from a different connection would have the
  47.      wrong seed and its checksum would presumably fail.  Huitema
  48.      suggested a random number for this seed; Matt Mathis suggested that
  49.      checksum of the pseudo-header.  However, this approach does not
  50.      check the length.
  51.  
  52.   2. Revise the MSS option to handle segments larger than 64KB.
  53.  
  54.      It was correctly pointed out that the MSS is concerned only with
  55.      the largest segment that can be reassembled at the receiver; it is
  56.      logically independent of the path MTU (although some common
  57.      implementations of TCP have confused these issues).  However, in
  58.      practice most implementations have an effective MSS that is (much)
  59.      larger than the path MTU's, so the MSS is seldom a real issue.
  60.  
  61.   3. Provide a mechanism to bound segment lifetimes.
  62.  
  63.      Maximum segment lifetime (MSL) is more of an important theoretical
  64.      problem than a practical one.  Theoretically, TCP4's reliability
  65.      depended upon routers treating the TTL field of the IP header as a
  66.      maximum queue time in seconds; however, in practice most routers
  67.      use it strictly as a hop count.  IP6 turns this practice into a
  68.      rule, so TCP6 needs some substitute mechanism to bound segment
  69.      lifetimes.
  70.  
  71.      The only viable approach seems to be to increase the effective MSL,
  72.      and then engineer the routers to enforce a maximum queueing delay,
  73.      e.g., 30 seconds per hop, before discarding a packet.  Then we must
  74.      have MSL > N*30 seconds, where N is the maximum Internet diameter.
  75.  
  76.      Braden noted that Van Jacobson's TCP timestamps, as embodied in the
  77.      PAWS mechanism (RFC 1323), do increase MSL to a very large value,
  78.      but only within the same connection.  A possible extension to PAWS
  79.      would store the latest timestamp per association, solving this
  80.      problem.
  81.  
  82.  
  83. Other major proposals for improving TCP without extending its
  84. functionality included the following:
  85.  
  86.  
  87.    o Redefine option format to provide more option space; in particular,
  88.      this would ease the implementation of SACK.
  89.    o Align header fields for 64-bit processors.
  90.    o Incorporate the RFC 1323 extensions (large windows, RTTM, and
  91.      PAWS).
  92.    o Extend ports to 32 bits.
  93.    o Move Urgent pointer into the options
  94.    o Provide ``DEC bit'' in ACKs
  95.    o Provide trailing checksums
  96.    o Provide an ``ACK request'' bit
  97.    o Provide an End-of-Record bit
  98.    o Include a TCP version field
  99.  
  100.  
  101. Finally, there were some changes that represented functionality
  102. extensions:
  103.  
  104.  
  105.    o Allow renumbering of open connections, to support dynamic host
  106.      reconfiguration.
  107.  
  108.    o Provide support for mobility and multihoming.
  109.      There was an inconclusive discussion on whether mobility support is
  110.      needed in the transport layer, or whether it can be exclusively in
  111.      the IP layer.
  112.  
  113.    o Include reliable multicast
  114.      Since there is a great variety of definitions of reliable multicast
  115.      service, it is very unlikely to make sense to extend TCP in this
  116.      direction.
  117.  
  118.    o Support transactions (see RFC 1644)
  119.  
  120.    o TMUX support
  121.  
  122.    o Security support
  123.  
  124.  
  125. Allison Mankin, the Transport Area Director, presented the
  126. recommendation of the Area Directorate.
  127.  
  128.  
  129.   1. Review text on TCP in the IPv6 specification, expand it for clarity
  130.      and to handle the MSS/jumbogram issue.
  131.  
  132.      Bob Braden and Erik Nordmark took an action to do this.
  133.  
  134.   2. Consider chartering a TranportNG working group, to go beyond TCP6.
  135.  
  136.      The Area Directors concerned are particularly in favor of option
  137.      expansion for SACK, and address-independent TCP.
  138.  
  139.      Several people suggested that a recent draft produced by Dave
  140.      Borman might be an appropriate starting point for such an effort.
  141.  
  142.  
  143. These recommendations appeared to be accepted by those present.
  144.  
  145.