As per Relevance of the word extension, we have this rfc below:
Network Working Group V.
Request for Comments: 1072
R.
October 1988
TCP Extensions for Long-Delay
Status of This
This memo proposes a set of extensions to the TCP protocol to
efficient operation over a path with a high bandwidth*delay product
These extensions are not proposed as an Internet standard at
time. Instead, they are intended as a basis for
experimentation and research on transport protocol performance
Distribution of this memo is unlimited
1.
Recent work on TCP performance has shown that TCP can work well
a variety of Internet paths, ranging from 800 Mbit/sec I/O
to 300 bit/sec dial-up modems [Jacobson88]. However, there is
a fundamental TCP performance bottleneck for one transmission regime
paths with high bandwidth and long round-trip delays.
significant parameter is the product of bandwidth (bits per second
and round-trip delay (RTT in seconds); this product is the number
bits it takes to "fill the pipe", i.e., the amount of
data that TCP must handle in order to keep the pipeline full.
performance problems arise when this product is large, e.g.,
significantly exceeds 10**5 bits. We will refer to an Internet
operating in this region as a "long, fat pipe", and a
containing this path as an "LFN" (pronounced "elephan(t)").
High-capacity packet satellite channels (e.g., DARPA's Wideband Net
are LFN's. For example, a T1-speed satellite channel has
bandwidth*delay product of 10**6 bits or more; this corresponds
100 outstanding TCP segments of 1200 bytes each! Proposed
terrestrial fiber-optical paths will also fall into the LFN class
for example, a cross-country delay of 30 ms at a DS3
(45Mbps) also exceeds 10**6 bits
Clever algorithms alone will not give us good TCP performance
LFN's; it will be necessary to actually extend the protocol.
RFC proposes a set of TCP extensions for this purpose
There are three fundamental problems with the current TCP over
Jacobson & Braden [Page 1]
RFC 1072 TCP Extensions for Long-Delay Paths October 1988
paths
(1) Window Size
The TCP header uses a 16 bit field to report the receive
size to the sender. Therefore, the largest window that can
used is 2**16 = 65K bytes. (In practice, some
implementations will "break" for windows exceeding 2**15,
because of their failure to do unsigned arithmetic).
To circumvent this problem, we propose a new TCP option to
windows larger than 2**16. This option will define an
scale factor, to be used to multiply the window size value
in a TCP header to obtain the true window size
(2) Cumulative
Any packet losses in an LFN can have a catastrophic effect
throughput. This effect is exaggerated by the simple
acknowledgment of TCP. Whenever a segment is lost,
transmitting TCP will (eventually) time out and retransmit
missing segment. However, the sending TCP has no
about segments that may have reached the receiver and
queued because they were not at the left window edge, so it
be forced to retransmit these segments unnecessarily
We propose a TCP extension to implement
acknowledgements. By sending selective acknowledgments,
receiver of data can inform the sender about all segments
have arrived successfully, so the sender need retransmit
the segments that have actually been lost
Selective acknowledgments have been included in a number
experimental Internet protocols -- VMTP [Cheriton88],
[Clark87], and RDP [Velten84]. There is some empirical
in favor of selective acknowledgments -- simple experiments
RDP have shown that disabling the selective
facility greatly increases the number of retransmitted
over a lossy, high-delay Internet path [Partridge87].
simulation study of a simple form of selective
added to the ISO transport protocol TP4 also showed promise
performance improvement [NBS85].
Jacobson & Braden [Page 2]
RFC 1072 TCP Extensions for Long-Delay Paths October 1988
(3) Round Trip
TCP implements reliable data delivery by measuring the RTT
i.e., the time interval between sending a segment and
an acknowledgment for it, and retransmitting any segments
are not acknowledged within some small multiple of the
RTT. Experience has shown that accurate, current RTT
are necessary to adapt to changing traffic conditions and
without them, a busy network is subject to an instability
as "congestion collapse" [Nagle84].
In part because TCP segments may be repacketized
retransmission, and in part because of complications due to
cumulative TCP acknowledgement, measuring a segments's RTT
involve a non-trivial amount of computation in
implementations. To minimize this computation,
implementations time only one segment per window. While
yields an adequate approximation to the RTT for small
(e.g., a 4 to 8 segment Arpanet window), for an LFN (e.g., 100
segment Wideband Network windows) it results in an
poor RTT estimate
In the presence of errors, the problem becomes worse.
[Zhang86], Jain [Jain86] and Karn [Karn87] have shown that it
not possible to accumulate reliable RTT estimates
retransmitted segments are included in the estimate. Since
full window of data will have been transmitted prior to
retransmission, all of the segments in that window will have
be ACKed before the next RTT sample can be taken. This means
least an additional window's worth of time between
measurements and, as the error rate approaches one per window
data (e.g., 10**-6 errors per bit for the Wideband Net),
becomes effectively impossible to obtain an RTT measurement
We propose a TCP "echo" option that allows each segment to
its own timestamp. This will allow every segment,
retransmissions, to be timed at negligible computational cost
In designing new TCP options, we must pay careful attention
interoperability with existing implementations. The only TCP
defined to date is an "initial option", i.e., it may appear only on
SYN segment. It is likely that most implementations will
ignore any options in the SYN segment that they do not understand,
new initial options should not cause a problem. On the other hand
we fear that receiving unexpected non-initial options may cause
TCP's to crash
Jacobson & Braden [Page 3]
RFC 1072 TCP Extensions for Long-Delay Paths October 1988
Therefore, in each of the extensions we propose, non-initial
may be sent only if an exchange of initial options has indicated
both sides understand the extension. This approach will also allow
TCP to determine when the connection opens how big a TCP header
will be sending
2. TCP WINDOW SCALE
The obvious way to implement a window scale factor would be to
a new TCP option that could be included in any segment specifying
window. The receiver would include it in every
segment, and the sender would interpret it. Unfortunately,
simple approach would not work. The sender must reliably know
receiver's current scale factor, but a TCP option in
acknowledgement segment will not be delivered reliably (unless
ACK happens to be piggy-backed on data).
However, SYN segments are always sent reliably, suggesting that
side may communicate its window scale factor in an initial
option. This approach has a disadvantage: the scale must
established when the connection is opened, and cannot be
thereafter. However, other alternatives would be much
complicated, and we therefore propose a new initial option
Window Scale
2.1 Window Scale
This three-byte option may be sent in a SYN segment by a TCP (1)
to indicate that it is prepared to do both send and receive
scaling, and (2) to communicate a scale factor to be applied
its receive window. The scale factor is encoded logarithmically
as a power of 2 (presumably to be implemented by binary shifts).
Note: the window in the SYN segment itself is never scaled
TCP Window Scale Option
Kind: 3
+---------+---------+---------+
| Kind=3 |Length=3 |shift.cnt
+---------+---------+---------+
Here shift.cnt is the number of bits by which the receiver right
shifts the true receive-window value, to scale it into a 16-
value to be sent in TCP header (this scaling is explained below).
The value shift.cnt may be zero (offering to scale, while
a scale factor of 1 to the receive window).
Jacobson & Braden [Page 4]
RFC 1072 TCP Extensions for Long-Delay Paths October 1988
This option is an offer, not a promise; both sides must
Window Scale options in their SYN segments to enable
scaling in either direction
2.2 Using the Window Scale
A model implementation of window scaling is as follows, using
notation of RFC-793 [Postel81]:
* The send-window (SND.WND) and receive-window (RCV.WND)
in the connection state block and in all sequence
calculations are expanded from 16 to 32 bits
* Two window shift counts are added to the connection state
snd.scale and rcv.scale. These are shift counts to
applied to the incoming and outgoing windows, respectively
The precise algorithm is shown below
* All outgoing SYN segments are sent with the Window
option, containing a value shift.cnt = R that the TCP
like to use for its receive window
* Snd.scale and rcv.scale are initialized to zero, and
changed only during processing of a received SYN segment.
the SYN segment contains a Window Scale option with shift.
= S, set snd.scale to S and set rcv.scale to R; otherwise
both snd.scale and rcv.scale are left at zero
* The window field (SEG.WND) in the header of every
segment, with the exception of SYN segments, will be left
shifted by snd.scale bits before updating SND.WND
SND.WND = SEG.WND << snd.
(assuming the other conditions of RFC793 are met, and
the "C" notation "<<" for left-shift).
* The window field (SEG.WND) of every outgoing segment,
the exception of SYN segments, will have been right-
by rcv.scale bits
SEG.WND = RCV.WND >> rcv.scale
TCP determines if a data segment is "old" or "new" by testing
its sequence number is within 2**31 bytes of the left edge of
window. If not, the data is "old" and discarded. To insure
new data is never mistakenly considered old and vice-versa,
Jacobson & Braden [Page 5]
RFC 1072 TCP Extensions for Long-Delay Paths October 1988
left edge of the sender's window has to be at least 2**31
from the right edge of the receiver's window. Similarly with
sender's right edge and receiver's left edge. Since the right
left edges of either the sender's or receiver's window differ
the window size, and since the sender and receiver windows can
out of phase by at most the window size, the above
imply that 2 * the max window size must be less than 2**31,
max window < 2**30
Since the max window is 2**S (where S is the scaling shift count
times at most 2**16 - 1 (the maximum unscaled window), the
window is guaranteed to be < 2*30 if S <= 14. Thus, the
count must be limited to 14. (This allows windows of 2**30 = 1
Gbyte.) If a Window Scale option is received with a shift.
value exceeding 14, the TCP should log the error but use 14
instead of the specified value
3. TCP SELECTIVE ACKNOWLEDGMENT
To minimize the impact on the TCP protocol, the
acknowledgment extension uses the form of two new TCP options.
first is an enabling option, "SACK-permitted", that may be sent in
SYN segment to indicate that the the SACK option may be used once
connection is established. The other is the SACK option itself
which may be sent over an established connection once permission
been given by SACK-permitted
The SACK option is to be included in a segment sent from a TCP
is receiving data to the TCP that is sending that data; we will
to these TCP's as the data receiver and the data sender
respectively. We will consider a particular simplex data flow;
data flowing in the reverse direction over the same connection can
treated independently
3.1 SACK-Permitted
This two-byte option may be sent in a SYN by a TCP that has
extended to receive (and presumably process) the SACK option
the connection has opened
Jacobson & Braden [Page 6]
RFC 1072 TCP Extensions for Long-Delay Paths October 1988
TCP Sack-Permitted Option
Kind: 4
+---------+---------+
| Kind=4 | Length=2|
+---------+---------+
3.2 SACK
The SACK option is to be used to convey extended
information over an established connection. Specifically, it
to be sent by a data receiver to inform the data transmitter
non-contiguous blocks of data that have been received and queued
The data receiver is awaiting the receipt of data in
retransmissions to fill the gaps in sequence space between
blocks. At that time, the data receiver will acknowledge the
normally by advancing the left window edge in the
Number field of the TCP header
It is important to understand that the SACK option will not
the meaning of the Acknowledgment Number field, whose value
still specify the left window edge, i.e., one byte beyond the
sequence number of fully-received data. The SACK option
advisory; if it is ignored, TCP acknowledgments will continue
function as specified in the protocol
However, SACK will provide additional information that the
transmitter can use to optimize retransmissions. The TCP
receiver may include the SACK option in an acknowledgment
whenever it has data that is queued and unacknowledged.
course, the SACK option may be sent only when the TCP has
the SACK-permitted option in the SYN segment for that connection
TCP SACK Option
Kind: 5
Length:
+--------+--------+--------+--------+--------+--------+...---+
| Kind=5 | Length | Relative Origin | Block Size | |
+--------+--------+--------+--------+--------+--------+...---+
This option contains a list of the blocks of contiguous
space occupied by data that has been received and queued
Jacobson & Braden [Page 7]
RFC 1072 TCP Extensions for Long-Delay Paths October 1988
the window. Each block is contiguous and isolated; that is,
octets just below the block
Acknowledgment Number + Relative Origin -1,
and just above the block
Acknowledgment Number + Relative Origin + Block Size
have not been received
Each contiguous block of data queued at the receiver is defined
the SACK option by two 16-bit integers
* Relative
This is the first sequence number of this block, relative
the Acknowledgment Number field in the TCP header (i.e.,
relative to the data receiver's left window edge).
* Block
This is the size in octets of this block of contiguous data
A SACK option that specifies n blocks will have a length of 4*n+2
octets, so the 44 bytes available for TCP options can specify
maximum of 10 blocks. Of course, if other TCP options
introduced, they will compete for the 44 bytes, and the limit
10 may be reduced in particular segments
There is no requirement on the order in which blocks can appear
a single SACK option
Note: requiring that the blocks be ordered would allow
slightly more efficient algorithm in the transmitter; however
this does not seem to be an important optimization
3.3 SACK with Window
If window scaling is in effect, then 16 bits may not be
for the SACK option fields that define the origin and length of
block. There are two possible ways to handle this
(1) Expand the SACK origin and length fields to 24 or 32 bits
Jacobson & Braden [Page 8]
RFC 1072 TCP Extensions for Long-Delay Paths October 1988
(2) Scale the SACK fields by the same factor as the window
The first alternative would significantly reduce the number
blocks possible in a SACK option; therefore, we have chosen
second alternative, scaling the SACK information as well as
window
Scaling the SACK information introduces some loss of precision
since a SACK option must report queued data blocks whose
and lengths are multiples of the window scale factor rcv.scale
These reported blocks must be equal to or smaller than the
blocks of queued data
Specifically, suppose that the receiver has a contiguous block
queued data that occupies sequence numbers L, L+1, ... L+N-1,
that the window scale factor is S = rcv.scale. Then
corresponding block that will be reported in a SACK option
be
Relative Origin = int((L+S-1)/S
Block Size = int((L+N)/S) - (Relative Origin
where the function int(x) returns the greatest integer
in x
The resulting loss of precision is not a serious problem for
sender. If the data-sending TCP keeps track of the boundaries
all segments in its retransmission queue, it will generally
able to infer from the imprecise SACK data which full
don't need to be retransmitted. This will fail only if S
larger than the maximum segment size, in which case some
may be retransmitted unnecessarily. If the sending TCP does
keep track of transmitted segment boundaries, the imprecision
the scaled SACK quantities will only result in retransmitting
small amount of unneeded sequence space. On the average, the
sender will unnecessarily retransmit J*S bytes of the
space for each SACK received; here J is the number of
reported in the SACK, and S = snd.scale
3.4 SACK Option
Assume the left window edge is 5000 and that the data
sends a burst of 8 segments, each containing 500 data bytes
Unless specified otherwise, we assume that the scale factor S = 1.
Jacobson & Braden [Page 9]
RFC 1072 TCP Extensions for Long-Delay Paths October 1988
Case 1: The first 4 segments are received but the last 4
dropped
The data receiver will return a normal TCP ACK
acknowledging sequence number 7000, with no SACK option
Case 2: The first segment is dropped but the remaining 7
received
The data receiver will return a TCP ACK segment
acknowledges sequence number 5000 and contains a SACK
specifying one block of queued data
Relative Origin = 500; Block Size = 3500
Case 3: The 2nd, 4th, 6th, and 8th (last) segments
dropped
The data receiver will return a TCP ACK segment
acknowledges sequence number 5500 and contains a SACK
specifying the 3 blocks
Relative Origin = 500; Block Size = 500
Relative Origin = 1500; Block Size = 500
Relative Origin = 2500; Block Size = 500
Case 4: Same as Case 3, except Scale Factor S = 16.
The SACK option would specify the 3 scaled blocks
Relative Origin = 32; Block Size = 30
Relative Origin = 94; Block Size = 31
Relative Origin = 157; Block Size = 30
These three reported blocks have sequence numbers 512
991, 1504 through 1999, and 2512 through 2992, respectively
3.5 Generating the SACK
Let us assume that the data receiver maintains a queue of
segments that it has neither passed to the user nor
because of earlier missing data, and that this queue is ordered
starting sequence number. Computation of the SACK option can
done with one pass down this queue. Segments that
Jacobson & Braden [Page 10]
RFC 1072 TCP Extensions for Long-Delay Paths October 1988
contiguous sequence space are aggregated into a single SACK block
and each gap in the sequence space (except a gap that
terminated by the right window edge) triggers the start of a
SACK block. If this algorithm defines more than 10 blocks,
the first 10 can be included in the option
3.6 Interpreting the SACK
The data transmitter is assumed to have a retransmission
that contains the segments that have been transmitted but not
acknowledged, in sequence-number order. If the data
performs re-packetization before retransmission, the
boundaries in a SACK option that it receives may not fall
boundaries of segments in the retransmission queue; however,
does not pose a serious difficulty for the transmitter
Let us suppose that for each segment in the retransmission
there is a (new) flag bit "ACK'd", to be used to indicate
this particular segment has been entirely acknowledged. When
segment is first transmitted, it will be entered into
retransmission queue with its ACK'd bit off. If the ACK'd bit
subsequently turned on (as the result of processing a
SACK option), the data transmitter will skip this segment
any later retransmission. However, the segment will not
dequeued and its buffer freed until the left window edge
advanced over it
When an acknowledgment segment arrives containing a SACK option
the data transmitter will turn on the ACK'd bits for segments
have been selectively acknowleged. More specifically, for
block in the SACK option, the data transmitter will turn on
ACK'd flags for all segments in the retransmission queue that
wholly contained within that block. This requires
sequence number comparisons
4. TCP ECHO
A simple method for measuring the RTT of a segment would be:
sender places a timestamp in the segment and the receiver
that timestamp in the corresponding ACK segment. When the ACK
arrives at the sender, the difference between the current time
the timestamp is the RTT. To implement this timing method,
receiver must simply reflect or echo selected data (the timestamp
from the sender's segments. This idea is the basis of the "TCP Echo
and "TCP Echo Reply" options
Jacobson & Braden [Page 11]
RFC 1072 TCP Extensions for Long-Delay Paths October 1988
4.1 TCP Echo and TCP Echo Reply
TCP Echo Option
Kind: 6
Length: 6
+--------+--------+--------+--------+--------+--------+
| Kind=6 | Length | 4 bytes of info to be echoed |
+--------+--------+--------+--------+--------+--------+
This option carries four bytes of information that the receiving
may send back in a subsequent TCP Echo Reply option (see below).
TCP may send the TCP Echo option in any segment, but only if a
Echo option was received in a SYN segment for the connection
When the TCP echo option is used for RTT measurement, it will
included in data segments, and the four information bytes will
the time at which the data segment was transmitted in any
convenient to the sender
TCP Echo Reply Option
Kind: 7
Length: 6
+--------+--------+--------+--------+--------+--------+
| Kind=7 | Length | 4 bytes of echoed info |
+--------+--------+--------+--------+--------+--------+
A TCP that receives a TCP Echo option containing four
bytes will return these same bytes in a TCP Echo Reply option
This TCP Echo Reply option must be returned in the next
(e.g., an ACK segment) that is sent. If more than one Echo option
received before a reply segment is sent, the TCP must choose only
of the options to echo, ignoring the others; specifically, it
choose the newest segment with the oldest sequence number (see
section.)
To use the TCP Echo and Echo Reply options, a TCP must send a
Echo option in its own SYN segment and receive a TCP Echo option in
SYN segment from the other TCP. A TCP that does not implement
TCP Echo or Echo Reply options must simply ignore any TCP
options it receives. However, a TCP should not receive one of
Jacobson & Braden [Page 12]
RFC 1072 TCP Extensions for Long-Delay Paths October 1988
options in a non-SYN segment unless it included a TCP Echo option
its own SYN segment
4.2 Using the Echo
If we wish to use the Echo/Echo Reply options for RTT measurement,
have to define what the receiver does when there is not a one-to-
correspondence between data and ACK segments. Assuming that we
to minimize the state kept in the receiver (i.e., the number
unprocessed Echo options), we can plan on a receiver remembering
information value from at most one Echo between ACKs. There
three situations to consider
(A) Delayed ACKs
Many TCP's acknowledge only every Kth segment out of a group
segments arriving within a short time interval; this policy
known generally as "delayed ACK's". The data-sender TCP
measure the effective RTT, including the additional time due
delayed ACK's, or else it will retransmit unnecessarily. Thus
when delayed ACK's are in use, the receiver should reply
the Echo option information from the earliest
segment
(B) A hole in the sequence space (segment(s) have been lost).
The sender will continue sending until the window is filled,
we may be generating ACKs as these out-of-order segments
(e.g., for the SACK information or to aid "fast retransmit").
An Echo Reply option will tell the sender the RTT of
recently sent segment (since the ACK can only contain
sequence number of the hole, the sender may not be able
determine which segment, but that doesn't matter). If the
was due to congestion, these RTTs may be particularly
to the sender since they reflect the network
immediately after the congestion
(C) A filled hole in the sequence space
The segment that fills the hole represents the most
measurement of the network characteristics. On the other hand
an RTT computed from an earlier segment would probably
the sender's retransmit time-out, badly biasing the sender'
average RTT estimate
Case (A) suggests the receiver should remember and return the
option information from the oldest unacknowledged segment. Cases (B
Jacobson & Braden [Page 13]
RFC 1072 TCP Extensions for Long-Delay Paths October 1988
and (C) suggest that the option should come from the most
unacknowledged segment. An algorithm that covers all three cases
for the receiver to return the Echo option information from
newest segment with the oldest sequence number, as specified earlier
A model implementation of these options is as follows
(1) Receiver
A 32-bit slot for Echo option data, rcv.echodata, is added
the receiver connection state, together with a flag
rcv.echopresent, that indicates whether there is anything in
slot. When the receiver generates a segment, it
rcv.echopresent and, if it is set, adds an echo-reply
containing rcv.echodata to the outgoing segment then
rcv.echopresent
If an incoming segment is in the window and contains an
option, the receiver checks rcv.echopresent. If it isn't set
the value of the echo option is copied to rcv.echodata
rcv.echopresent is set. If rcv.echopresent is already set,
receiver checks whether the segment is at the left edge of
window. If so, the segment's echo option value is copied
rcv.echodata (this is situation (C) above). Otherwise,
segment's echo option is ignored
(2) Sender
The sender's connection state has a single flag bit
snd.echoallowed, added. If snd.echoallowed is set or if
segment contains a SYN, the sender is free to add a TCP
option (presumably containing the current time in some
convenient to the sender) to every outgoing segment
Snd.echoallowed should be set if a SYN is received with a
Echo option (presumably, a host that implements the option
attempt to use it to time the SYN segment).
5. CONCLUSIONS AND
We have proposed five new TCP options for scaled windows,
acknowledgments, and round-trip timing, in order to provide
operation over large-bandwidth*delay-product paths. These
are designed to provide compatible interworking with TCP's that do
implement the extensions
Jacobson & Braden [Page 14]
RFC 1072 TCP Extensions for Long-Delay Paths October 1988
The Window Scale option was originally suggested by Mike St. Johns
USAF/DCA. The present form of the option was suggested by Mike
of UC Berkeley in response to a more cumbersome scheme proposed by
Jacobson. Gerd Beling of FGAN (West Germany) contributed the
definition of the SACK option
All three options have evolved through discussion with the End-to-
Task Force, and the authors are grateful to the other members of
Task Force for their advice and encouragement
6.
[Cheriton88] Cheriton, D., "VMTP: Versatile Message
Protocol", RFC 1045, Stanford University, February 1988.
[Jain86] Jain, R., "Divergence of Timeout Algorithms for
Retransmissions", Proc. Fifth Phoenix Conf. on Comp. and Comm.,
Scottsdale, Arizona, March 1986.
[Karn87] Karn, P. and C. Partridge, "Estimating Round-Trip
in Reliable Transport Protocols", Proc. SIGCOMM '87, Stowe, VT
August 1987.
[Clark87] Clark, D., Lambert, M., and L. Zhang, "NETBLT: A
Data Transfer Protocol", RFC 998, MIT, March 1987.
[Nagle84] Nagle, J., "Congestion Control in IP/
Internetworks", RFC 896, FACC, January 1984.
[NBS85] Colella, R., Aronoff, R., and K. Mills, "
Improvements for ISO Transport", Ninth Data Comm Symposium
published in ACM SIGCOMM Comp Comm Review, vol. 15, no. 5,
September 1985.
[Partridge87] Partridge, C., "Private Communication",
1987.
[Postel81] Postel, J., "Transmission Control Protocol -
Internet Program Protocol Specification", RFC 793, DARPA
September 1981.
[Velten84] Velten, D., Hinden, R., and J. Sax, "Reliable
Protocol", RFC 908, BBN, July 1984.
[Jacobson88] Jacobson, V., "Congestion Avoidance and Control",
be presented at SIGCOMM '88, Stanford, CA., August 1988.
[Zhang86] Zhang, L., "Why TCP Timers Don't Work Well", Proc
Jacobson & Braden [Page 15]
RFC 1072 TCP Extensions for Long-Delay Paths October 1988
SIGCOMM '86, Stowe, Vt., August 1986.
Jacobson & Braden [Page 16]
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
