rfc2140.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 620 行 · 第 1/2 页

   congestion, the set of connections might behave as if it were
   multiplexed prior to TCP, as if all data were part of a single
   connection. As a result, the current window sizes would maintain a
   constant sum, presuming sufficient offered load. This would go beyond
   caching to truly sharing state, as in the RTT case.

   We pause to note that any assumption of this sharing can be
   incorrect, including this one. In current implementations, new
   congestion windows are set at an initial value of one segment, so
   that the sum of the current windows is increased for any new
   connection. This can have detrimental consequences where several
   connections share a highly congested link, such as in trans-Atlantic
   Web access.

   There are several ways to initialize the congestion window in a new
   TCB among an ensemble of current connections to a host, as shown
   below. Current TCP implementations initialize it to one segment [9],
   and T/TCP hinted that it should be initialized to the old window size
   [3]. In the former, the assumption is that new connections should
   behave as conservatively as possible. In the latter, no accommodation
   is made to concurrent aggregate behavior.

   In either case, the sum of window sizes can increase, rather than
   remain constant. Another solution is to give each pending connection



Touch                        Informational                      [Page 6]

RFC 2140           TCP Control Block Interdependence          April 1997


   its "fair share" of the available congestion window, and let the
   connections balance from there. The assumption we make here is that
   new connections are implicit requests for an equal share of available
   link bandwidth which should be granted at the expense of current
   connections. This may or may not be the appropriate function; we
   propose that it be examined further.


                ENSEMBLE SHARING - TCB Initialization
                Some Options for Sharing Window-size

    Cached TCB                           New TCB
    -----------------------------------------------------------------
    old-snd_cwnd         (current)       one segment

                         (T/TCP hint)    old-snd_cwnd

                         (proposed)      old-snd_cwnd/(N+1)
                                         subtract old-snd_cwnd/(N+1)/N
                                         from each concurrent


                 ENSEMBLE SHARING - Cache Updates

    Cached TCB   Current TCB     when?   New Cached TCB
    ----------------------------------------------------------------
    old-snd_cwnd curr-snd_cwnd   update  (adjust sum as appropriate)


Compatibility Issues

   Current TCP implementations do not use TCB caching, with the
   exception of T/TCP variants [4][7]. New connections use the default
   initial values of all non-instantiated TCB variables. As a result,
   each connection calculates its own RTT measurements, MSS value, and
   congestion information. Eventually these values are updated for each
   connection.

   For the congestion and current window information, the initial values
   may not be consistent with the long-term aggregate behavior of a set
   of concurrent connections. If a single connection has a window of 4
   segments, new connections assume initial windows of 1 segment (the
   minimum), although the current connection's window doesn't decrease
   to accommodate this additional load. As a result, connections can
   mutually interfere. One example of this has been seen on trans-
   Atlantic links, where concurrent connections supporting Web traffic
   can collide because their initial windows are too large, even when
   set at one segment.



Touch                        Informational                      [Page 7]

RFC 2140           TCP Control Block Interdependence          April 1997


   Because this proposal attempts to anticipate the aggregate steady-
   state values of TCB state among a group or over time, it should avoid
   the transient effects of new connections. In addition, because it
   considers the ensemble and temporal properties of those aggregates,
   it should also prevent the transients of short-lived or multiple
   concurrent connections from adversely affecting the overall network
   performance. We are performing analysis and experiments to validate
   these assumptions.

Performance Considerations

   Here we attempt to optimize transient behavior of TCP without
   modifying its long-term properties. The predominant expense is in
   maintaining the cached values, or in using per-host state rather than
   per-connection state. In cases where performance is affected,
   however, we note that the per-host information can be kept in per-
   connection copies (as done now), because with higher performance
   should come less interference between concurrent connections.

   Sharing TCB state can occur only at connection establishment and
   close (to update the cache), to minimize overhead, optimize transient
   behavior, and minimize the effect on the steady-state. It is possible
   that sharing state during a connection, as in the RTT or window-size
   variables, may be of benefit, provided its implementation cost is not
   high.

Implications

   There are several implications to incorporating TCB interdependence
   in TCP implementations. First, it may prevent the need for
   application-layer multiplexing for performance enhancement [6].
   Protocols like persistent-HTTP avoid connection reestablishment costs
   by serializing or multiplexing a set of per-host connections across a
   single TCP connection. This avoids TCP's per-connection OPEN
   handshake, and also avoids recomputing MSS, RTT, and congestion
   windows. By avoiding the so-called, "slow-start restart," performance
   can be optimized. Our proposal provides the MSS, RTT, and OPEN
   handshake avoidance of T/TCP, and the "slow-start restart avoidance"
   of multiplexing, without requiring a multiplexing mechanism at the
   application layer. This multiplexing will be complicated when
   quality-of-service mechanisms (e.g., "integrated services
   scheduling") are provided later.

   Second, we are attempting to push some of the TCP implementation from
   the traditional transport layer (in the ISO model [10]), to the
   network layer. This acknowledges that some state currently maintained
   as per-connection is in fact per-path, which we simplify as per-
   host-pair. Transport protocols typically manage per-application-pair



Touch                        Informational                      [Page 8]

RFC 2140           TCP Control Block Interdependence          April 1997


   associations (per stream), and network protocols manage per-path
   associations (routing). Round-trip time, MSS, and congestion
   information is more appropriately handled in a network-layer fashion,
   aggregated among concurrent connections, and shared across connection
   instances.

   An earlier version of RTT sharing suggested implementing RTT state at
   the IP layer, rather than at the TCP layer [8]. Our observations are
   for sharing state among TCP connections, which avoids some of the
   difficulties in an IP-layer solution. One such problem is determining
   the associated prior outgoing packet for an incoming packet, to infer
   RTT from the exchange. Because RTTs are still determined inside the
   TCP layer, this is simpler than at the IP layer. This is a case where
   information should be computed at the transport layer, but shared at
   the network layer.

   We also note that per-host-pair associations are not the limit of
   these techniques. It is possible that TCBs could be similarly shared
   between hosts on a LAN, because the predominant path can be LAN-LAN,
   rather than host-host.

   There may be other information that can be shared between concurrent
   connections. For example, knowing that another connection has just
   tried to expand its window size and failed, a connection may not
   attempt to do the same for some period. The idea is that existing TCP
   implementations infer the behavior of all competing connections,
   including those within the same host or LAN. One possible
   optimization is to make that implicit feedback explicit, via extended
   information in the per-host TCP area.

Security Considerations

   These suggested implementation enhancements do not have additional
   ramifications for direct attacks. These enhancements may be
   susceptible to denial-of-service attacks if not otherwise secured.
   For example, an application can open a connection and set its window
   size to 0, denying service to any other subsequent connection between
   those hosts.

   TCB sharing may be susceptible to denial-of-service attacks, wherever
   the TCB is shared, between connections in a single host, or between
   hosts if TCB sharing is implemented on the LAN (see Implications
   section).  Some shared TCB parameters are used only to create new
   TCBs, others are shared among the TCBs of ongoing connections. New
   connections can join the ongoing set, e.g., to optimize send window
   size among a set of connections to the same host.





Touch                        Informational                      [Page 9]

RFC 2140           TCP Control Block Interdependence          April 1997


   Attacks on parameters used only for initialization affect only the
   transient performance of a TCP connection.  For short connections,
   the performance ramification can approach that of a denial-of-service
   attack.  E.g., if an application changes its TCB to have a false and
   small window size, subsequent connections would experience
   performance degradation until their window grew appropriately.

   The solution is to limit the effect of compromised TCB values.  TCBs
   are compromised when they are modified directly by an application or
   transmitted between hosts via unauthenticated means (e.g., by using a
   dirty flag). TCBs that are not compromised by application
   modification do not have any unique security ramifications. Note that
   the proposed parameters for TCB sharing are not currently modifiable
   by an application.

   All shared TCBs MUST be validated against default minimum parameters
   before used for new connections. This validation would not impact
   performance, because it occurs only at TCB initialization.  This
   limits the effect of attacks on new connections, to reducing the
   benefit of TCB sharing, resulting in the current default TCP
   performance. For ongoing connections, the effect of incoming packets
   on shared information should be both limited and validated against
   constraints before use. This is a beneficial precaution for existing
   TCP implementations as well.

   TCBs modified by an application SHOULD not be shared, unless the new
   connection sharing the compromised information has been given
   explicit permission to use such information by the connection API. No
   mechanism for that indication currently exists, but it could be
   supported by an augmented API. This sharing restriction SHOULD be
   implemented in both the host and the LAN. Sharing on a LAN SHOULD
   utilize authentication to prevent undetected tampering of shared TCB
   parameters. These restrictions limit the security impact of modified
   TCBs both for connection initialization and for ongoing connections.

   Finally, shared values MUST be limited to performance factors only.
   Other information, such as TCP sequence numbers, when shared, are
   already known to compromise security.

Acknowledgements

   The author would like to thank the members of the High-Performance
   Computing and Communications Division at ISI, notably Bill Manning,
   Bob Braden, Jon Postel, Ted Faber, and Cliff Neuman for their
   assistance in the development of this memo.






Touch                        Informational                     [Page 10]

RFC 2140           TCP Control Block Interdependence          April 1997


References

   [1] Berners-Lee, T., et al., "The World-Wide Web," Communications of
       the ACM, V37, Aug. 1994, pp. 76-82.

   [2] Braden, R., "Transaction TCP -- Concepts," RFC-1379,
       USC/Information Sciences Institute, September 1992.

   [3] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional
       Specification," RFC-1644, USC/Information Sciences Institute,
       July 1994.

   [4] Braden, B., "T/TCP -- Transaction TCP: Source Changes for Sun OS
       4.1.3,", Release 1.0, USC/ISI, September 14, 1994.

   [5] Comer, D., and Stevens, D., Internetworking with TCP/IP, V2,
       Prentice-Hall, NJ, 1991.

   [6] Fielding, R., et al., "Hypertext Transfer Protocol -- HTTP/1.1,"
       Work in Progress.

   [7] FreeBSD source code, Release 2.10, <http://www.freebsd.org/>.

   [8] Jacobson, V., (mail to public list "tcp-ip", no archive found),
       1986.

   [9] Postel, Jon, "Transmission Control Protocol," Network Working
       Group RFC-793/STD-7, ISI, Sept. 1981.

   [10] Tannenbaum, A., Computer Networks, Prentice-Hall, NJ, 1988.

Author's Address

   Joe Touch
   University of Southern California/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695
   USA
   Phone: [phone] x151
   Fax:   [phone]
   URL:   http://www.isi.edu/~touch
   Email: [e-mail]









Touch                        Informational                     [Page 11]