As per Relevance of the word congestion, we have this rfc below:
Network Working Group J.
Request for Comments: 2140
Category: Informational April 1997
TCP Control Block
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This memo makes the case for interdependent TCP control blocks,
part of the TCP state is shared among similar concurrent connections
or across similar connection instances. TCP state includes
combination of parameters, such as connection state, current round
trip time estimates, congestion control information, and
information. This state is currently maintained on a per-
basis in the TCP control block, but should be shared
connections to the same host. The goal is to improve
transport performance, while maintaining backward-compatibility
existing implementations
This document is a product of the LSAM project at ISI
TCP is a connection-oriented reliable transport protocol layered
IP [9]. Each TCP connection maintains state, usually in a
structure called the TCP Control Block (TCB). The TCB
information about the connection state, its associated local process
and feedback parameters about the connection's
properties. As originally specified and usually implemented, the
is maintained on a per-connection basis. This document discusses
implications of that decision, and argues for an
implementation that shares some of this state across
connection instances and among similar simultaneous connections.
resulting implementation can have better transient performance
especially for numerous short-lived and simultaneous connections,
often used in the World-Wide Web [1]. These changes affect only
TCB initialization, and so have no effect on the long-term
of TCP after a connection has been established
Touch Informational [Page 1]
RFC 2140 TCP Control Block Interdependence April 1997
The TCP Control Block (TCB
A TCB is associated with each connection, i.e., with each
of a pair of applications across the network. The TCB can
summarized as containing [9]:
Local process
pointers to send and receive
pointers to retransmission queue and current
pointers to Internet Protocol (IP)
Per-connection shared
macro-
connection
local and remote host numbers and
micro-
send and receive window state (size*, current number
round-trip time and
cong. window size
cong. window size threshold
max windows seen
MSS
round-trip time and variance
The per-connection information is shown as split into macro-state
micro-state, terminology borrowed from [5]. Macro-state describes
finite state machine; we include the endpoint numbers and
(timers, flags) used to help maintain that state. This includes
protocol for establishing and maintaining shared state about
connection. Micro-state describes the protocol after a connection
been established, to maintain the reliability and congestion
of the data transferred in the connection
We further distinguish two other classes of shared micro-state
are associated more with host-pairs than with application pairs.
class is clearly host-pair dependent (#, e.g., MSS, RTT), and
other is host-pair dependent in its aggregate (*, e.g., cong.
info., curr. window sizes).
Touch Informational [Page 2]
RFC 2140 TCP Control Block Interdependence April 1997
TCB
The observation that some TCB state is host-pair specific rather
application-pair dependent is not new, and is a common
decision in layered protocol implementations. A discussion of
RTT information among protocols layered over IP, including UDP
TCP, occurred in [8]. T/TCP uses caches to maintain TCB
across instances, e.g., smoothed RTT, RTT variance,
avoidance threshold, and MSS [3]. These values are in addition
connection counts used by T/TCP to accelerate data delivery prior
the full three-way handshake during an OPEN. The goal is to
TCB components where they reflect one association - that of
host-pair, rather than artificially separating those components
connection
At least one current T/TCP implementation saves the MSS
aggregates the RTT parameters across multiple connections, but
caching the congestion window information [4], as
specified in [2]. There may be other values that may be cached,
as current window size, to permit new connections full access
accumulated channel resources
We observe that there are two cases of TCB interdependence.
sharing occurs when the TCB of an earlier (now CLOSED) connection
a host is used to initialize some parameters of a new connection
that same host. Ensemble sharing occurs when a currently
connection to a host is used to initialize another (concurrent
connection to that host. T/TCP documents considered the
case; we consider both
An Example of Temporal
Temporal sharing of cached TCB data has been implemented in the
4.1.3 T/TCP extensions [4] and the FreeBSD port of same [7].
mentioned before, only the MSS and RTT parameters are cached,
originally specified in [2]. Later discussion of T/TCP
including congestion control parameters in this cache [3].
The cache is accessed in two ways: it is read to initialize new TCBs
and written when more current per-host state is available. New
are initialized as follows; snd_cwnd reuse is not yet implemented
although discussed in the T/TCP concepts [2]:
Touch Informational [Page 3]
RFC 2140 TCP Control Block Interdependence April 1997
TEMPORAL SHARING - TCB
Cached TCB New
----------------------------------------
old-MSS old-
old-RTT old-
old-RTTvar old-
old-snd_cwnd old-snd_cwnd (not yet impl.)
Most cached TCB values are updated when a connection closes.
exception is MSS, which is updated whenever the MSS option
received in a TCP header
TEMPORAL SHARING - Cache
Cached TCB Current TCB when? New Cached
---------------------------------------------------------------
old-MSS curr-MSS MSSopt curr-
old-RTT curr-RTT CLOSE old += (curr - old) >> 2
old-RTTvar curr-RTTvar CLOSE old += (curr - old) >> 2
old-snd_cwnd curr-snd_cwnd CLOSE curr-snd_cwnd (not yet impl.)
MSS caching is trivial; reported values are cached, and the
recent value is used. The cache is updated when the MSS option
received, so the cache always has the most recent MSS value from
connection. The cache is consulted only at connection establishment
and not otherwise updated, which means that MSS options do not
current connections. The default MSS is never saved; only
MSS values update the cache, so an explicit override is required
reduce the MSS
RTT values are updated by a more complicated mechanism [3], [8].
Dynamic RTT estimation requires a sequence of RTT measurements,
though a single T/TCP transaction may not accumulate enough samples
As a result, the cached RTT (and its variance) is an average of
previous value with the contents of the currently active TCB for
host, when a TCB is closed. RTT values are updated only when
connection is closed. Further, the method for averaging the
values is not the same as the method for computing the RTT
within a connection, so that the cached value may not be appropriate
Touch Informational [Page 4]
RFC 2140 TCP Control Block Interdependence April 1997
For temporal sharing, the cache requires updating only when
connection closes, because the cached values will not yet be used
initialize a new TCB. For the ensemble sharing, this is not the case
as discussed below
Other TCB variables may also be cached between sequential instances
such as the congestion control window information. Old cache
can be overwritten with the current TCB estimates, or a MAX or
function can be used to merge the results, depending on the
or pessimism of the reused values. For example, the congestion
can be reused if there are no concurrent connections
An Example of Ensemble
Sharing cached TCB data across concurrent connections
attention to the aggregate nature of some of the shared state
Although MSS and RTT values can be shared by copying, it may not
appropriate to copy congestion window information. At this point,
present only the MSS and RTT rules
ENSEMBLE SHARING - TCB
Cached TCB New
----------------------------------
old-MSS old-
old-RTT old-
old-RTTvar old-
ENSEMBLE SHARING - Cache
Cached TCB Current TCB when? New Cached
-----------------------------------------------------------
old-MSS curr-MSS MSSopt curr-
old-RTT curr-RTT update rtt_update(old,curr
old-RTTvar curr-RTTvar update rtt_update(old,curr
For ensemble sharing, TCB information should be cached as early
possible, sometimes before a connection is closed. Otherwise,
multiple concurrent connections may not result in TCB data sharing
no connection closes before others open. An optimistic solution
Touch Informational [Page 5]
RFC 2140 TCP Control Block Interdependence April 1997
be to update cached data as early as possible, rather than only
a connection is closing. Some T/TCP implementations do this for
when the TCP MSS header option is received [4], although it is
addressed specifically in the concepts or functional
[2][3].
In current T/TCP, RTT values are updated only after a CLOSE,
does not benefit concurrent sessions. As mentioned in the
case, averaging values between concurrent connections
incorporating new RTT measurements. The amount of work involved
updating the aggregate average should be minimized, but the
value should be equivalent to having all values measured within
single connection. The function "rtt_update" in the ensemble
table indicates this operation, which occurs whenever the RTT
have been updated in the individual TCP connection. As a result,
cache contains the shared RTT variables, which no longer need
reside in the TCB [8].
Congestion window size aggregation is more complicated in
concurrent case. When there is an ensemble of connections, we
to decide how that ensemble would have shared the congestion window
in order to derive initial values for new TCBs. Because
connections between two hosts share network paths (usually),
also share whatever capacity exists along that path. With regard
congestion, the set of connections might behave as if it
multiplexed prior to TCP, as if all data were part of a
connection. As a result, the current window sizes would maintain
constant sum, presuming sufficient offered load. This would go
caching to truly sharing state, as in the RTT case
We pause to note that any assumption of this sharing can
incorrect, including this one. In current implementations,
congestion windows are set at an initial value of one segment,
that the sum of the current windows is increased for any
connection. This can have detrimental consequences where
connections share a highly congested link, such as in trans-
Web access
There are several ways to initialize the congestion window in a
TCB among an ensemble of current connections to a host, as
below. Current TCP implementations initialize it to one segment [9],
and T/TCP hinted that it should be initialized to the old window
[3]. In the former, the assumption is that new connections
behave as conservatively as possible. In the latter, no
is made to concurrent aggregate behavior
In either case, the sum of window sizes can increase, rather
remain constant. Another solution is to give each pending
Touch Informational [Page 6]
RFC 2140 TCP Control Block Interdependence April 1997
its "fair share" of the available congestion window, and let
connections balance from there. The assumption we make here is
new connections are implicit requests for an equal share of
link bandwidth which should be granted at the expense of
connections. This may or may not be the appropriate function;
propose that it be examined further
ENSEMBLE SHARING - TCB
Some Options for Sharing Window-
Cached TCB New
-----------------------------------------------------------------
old-snd_cwnd (current) one
(T/TCP hint) old-snd_
(proposed) old-snd_cwnd/(N+1)
subtract old-snd_cwnd/(N+1)/
from each
ENSEMBLE SHARING - Cache
Cached TCB Current TCB when? New Cached
----------------------------------------------------------------
old-snd_cwnd curr-snd_cwnd update (adjust sum as appropriate
Compatibility
Current TCP implementations do not use TCB caching, with
exception of T/TCP variants [4][7]. New connections use the
initial values of all non-instantiated TCB variables. As a result
each connection calculates its own RTT measurements, MSS value,
congestion information. Eventually these values are updated for
connection
For the congestion and current window information, the initial
may not be consistent with the long-term aggregate behavior of a
of concurrent connections. If a single connection has a window of 4
segments, new connections assume initial windows of 1 segment (
minimum), although the current connection's window doesn't
to accommodate this additional load. As a result, connections
mutually interfere. One example of this has been seen on trans
Atlantic links, where concurrent connections supporting Web
can collide because their initial windows are too large, even
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
the transient effects of new connections. In addition, because
considers the ensemble and temporal properties of those aggregates
it should also prevent the transients of short-lived or
concurrent connections from adversely affecting the overall
performance. We are performing analysis and experiments to
these assumptions
Performance
Here we attempt to optimize transient behavior of TCP
modifying its long-term properties. The predominant expense is
maintaining the cached values, or in using per-host state rather
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
should come less interference between concurrent connections
Sharing TCB state can occur only at connection establishment
close (to update the cache), to minimize overhead, optimize
behavior, and minimize the effect on the steady-state. It is
that sharing state during a connection, as in the RTT or window-
variables, may be of benefit, provided its implementation cost is
high
There are several implications to incorporating TCB
in TCP implementations. First, it may prevent the need
application-layer multiplexing for performance enhancement [6].
Protocols like persistent-HTTP avoid connection reestablishment
by serializing or multiplexing a set of per-host connections across
single TCP connection. This avoids TCP's per-connection
handshake, and also avoids recomputing MSS, RTT, and
windows. By avoiding the so-called, "slow-start restart,"
can be optimized. Our proposal provides the MSS, RTT, and
handshake avoidance of T/TCP, and the "slow-start restart avoidance
of multiplexing, without requiring a multiplexing mechanism at
application layer. This multiplexing will be complicated
quality-of-service mechanisms (e.g., "integrated
scheduling") are provided later
Second, we are attempting to push some of the TCP implementation
the traditional transport layer (in the ISO model [10]), to
network layer. This acknowledges that some state currently
as per-connection is in fact per-path, which we simplify as per
host-pair. Transport protocols typically manage per-application-
Touch Informational [Page 8]
RFC 2140 TCP Control Block Interdependence April 1997
associations (per stream), and network protocols manage per-
associations (routing). Round-trip time, MSS, and
information is more appropriately handled in a network-layer fashion
aggregated among concurrent connections, and shared across
instances
An earlier version of RTT sharing suggested implementing RTT state
the IP layer, rather than at the TCP layer [8]. Our observations
for sharing state among TCP connections, which avoids some of
difficulties in an IP-layer solution. One such problem is
the associated prior outgoing packet for an incoming packet, to
RTT from the exchange. Because RTTs are still determined inside
TCP layer, this is simpler than at the IP layer. This is a case
information should be computed at the transport layer, but shared
the network layer
We also note that per-host-pair associations are not the limit
these techniques. It is possible that TCBs could be similarly
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
connections. For example, knowing that another connection has
tried to expand its window size and failed, a connection may
attempt to do the same for some period. The idea is that existing
implementations infer the behavior of all competing connections
including those within the same host or LAN. One
optimization is to make that implicit feedback explicit, via
information in the per-host TCP area
Security
These suggested implementation enhancements do not have
ramifications for direct attacks. These enhancements may
susceptible to denial-of-service attacks if not otherwise secured
For example, an application can open a connection and set its
size to 0, denying service to any other subsequent connection
those hosts
TCB sharing may be susceptible to denial-of-service attacks,
the TCB is shared, between connections in a single host, or
hosts if TCB sharing is implemented on the LAN (see
section). Some shared TCB parameters are used only to create
TCBs, others are shared among the TCBs of ongoing connections.
connections can join the ongoing set, e.g., to optimize send
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
transient performance of a TCP connection. For short connections
the performance ramification can approach that of a denial-of-
attack. E.g., if an application changes its TCB to have a false
small window size, subsequent connections would
performance degradation until their window grew appropriately
The solution is to limit the effect of compromised TCB values.
are compromised when they are modified directly by an application
transmitted between hosts via unauthenticated means (e.g., by using
dirty flag). TCBs that are not compromised by
modification do not have any unique security ramifications. Note
the proposed parameters for TCB sharing are not currently
by an application
All shared TCBs MUST be validated against default minimum
before used for new connections. This validation would not
performance, because it occurs only at TCB initialization.
limits the effect of attacks on new connections, to reducing
benefit of TCB sharing, resulting in the current default
performance. For ongoing connections, the effect of incoming
on shared information should be both limited and validated
constraints before use. This is a beneficial precaution for
TCP implementations as well
TCBs modified by an application SHOULD not be shared, unless the
connection sharing the compromised information has been
explicit permission to use such information by the connection API.
mechanism for that indication currently exists, but it could
supported by an augmented API. This sharing restriction SHOULD
implemented in both the host and the LAN. Sharing on a LAN
utilize authentication to prevent undetected tampering of shared
parameters. These restrictions limit the security impact of
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,
already known to compromise security
The author would like to thank the members of the High-
Computing and Communications Division at ISI, notably Bill Manning
Bob Braden, Jon Postel, Ted Faber, and Cliff Neuman for
assistance in the development of this memo
Touch Informational [Page 10]
RFC 2140 TCP Control Block Interdependence April 1997
[1] Berners-Lee, T., et al., "The World-Wide Web," Communications
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
Specification," RFC-1644, USC/Information Sciences Institute
July 1994.
[4] Braden, B., "T/TCP -- Transaction TCP: Source Changes for Sun
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, .
[8] Jacobson, V., (mail to public list "tcp-ip", no archive found),
1986.
[9] Postel, Jon, "Transmission Control Protocol," Network
Group RFC-793/STD-7, ISI, Sept. 1981.
[10] Tannenbaum, A., Computer Networks, Prentice-Hall, NJ, 1988.
Author's
Joe
University of Southern California/Information Sciences
4676 Admiralty
Marina del Rey, CA 90292-6695
Phone: +1 310-822-1511 x151
Fax: +1 310-823-6714
URL: http://www.isi.edu/~
Email: touch@isi.
Touch Informational [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
