RFC relevance of acknowledge

As per Relevance of the word acknowledge, we have this rfc below:

Network Working Group S.
Request for Comments: 2883
Category: Standards Track J.

M.
Pittsburgh Supercomputing
M.
UC
July 2000

An Extension to the Selective Acknowledgement (SACK) Option for

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (2000). All Rights Reserved

This note defines an extension of the Selective
(SACK) Option [RFC2018] for TCP. RFC 2018 specified the use of
SACK option for acknowledging out-of-sequence data not covered
TCP's cumulative acknowledgement field. This note extends RFC 2018
by specifying the use of the SACK option for acknowledging
packets. This note suggests that when duplicate packets
received, the first block of the SACK option field can be used
report the sequence numbers of the packet that triggered
acknowledgement. This extension to the SACK option allows the
sender to infer the order of packets received at the receiver
allowing the sender to infer when it has unnecessarily
a packet. A TCP sender could then use this information for
robust operation in an environment of reordered packets [BPS99],
loss, packet replication, and/or early retransmit timeouts

1. Conventions and

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in
document, are to be interpreted as described in [B97].

Floyd, et al. Standards Track [Page 1]

RFC 2883 SACK Extension July 2000

2.

The Selective Acknowledgement (SACK) option defined in RFC 2018
used by the TCP data receiver to acknowledge non-contiguous blocks
data not covered by the Cumulative Acknowledgement field. However
RFC 2018 does not specify the use of the SACK option when
segments are received. This note specifies the use of the
option when acknowledging the receipt of a duplicate packet [F99].
We use the term D-SACK (for duplicate-SACK) to refer to a SACK
that reports a duplicate segment

This document does not make any changes to TCP's use of
cumulative acknowledgement field, or to the TCP receiver's
of *when* to send an acknowledgement packet. This document
concerns the contents of the SACK option when an acknowledgement
sent

This extension is compatible with current implementations of the
option in TCP. That is, if one of the TCP end-nodes does
implement this D-SACK extension and the other TCP end-node does,
believe that this use of the D-SACK extension by one of the end
will not introduce problems

The use of D-SACK does not require separate negotiation between a
sender and receiver that have already negotiated SACK capability
The absence of separate negotiation for D-SACK means that the
receiver could send D-SACK blocks when the TCP sender does
understand this extension to SACK. In this case, the TCP sender
simply discard any D-SACK blocks, and process the other SACK
in the SACK option field as it normally would

Floyd, et al. Standards Track [Page 2]

RFC 2883 SACK Extension July 2000

3. The Sack Option Format as defined in RFC 2018

The SACK option as defined in RFC 2018 is as follows

+--------+--------+
| Kind=5 | Length |
+--------+--------+--------+--------+
| Left Edge of 1st Block |
+--------+--------+--------+--------+
| Right Edge of 1st Block |
+--------+--------+--------+--------+
| |
/ . . . /
| |
+--------+--------+--------+--------+
| Left Edge of nth Block |
+--------+--------+--------+--------+
| Right Edge of nth Block |
+--------+--------+--------+--------+

The Selective Acknowledgement (SACK) option in the TCP
contains a number of SACK blocks, where each block specifies the
and right edge of a block of data received at the TCP receiver.
particular, a block represents a contiguous sequence space of
received and queued at the receiver, where the "left edge" of
block is the first sequence number of the block, and the "right edge
is the sequence number immediately following the last sequence
of the block

RFC 2018 implies that the first SACK block specify the segment
triggered the acknowledgement. From RFC 2018, when the data
chooses to send a SACK option, "the first SACK block ... MUST
the contiguous block of data containing the segment which
this ACK, unless that segment advanced the Acknowledgment
field in the header."

However, RFC 2018 does not address the use of the SACK option
acknowledging a duplicate segment. For example, RFC 2018
that "each block represents received bytes of data that
contiguous and isolated". RFC 2018 further specifies that "if
at all, SACK options SHOULD be included in all ACKs which do not
the highest sequence number in the data receiver's queue." RFC 2018
does not specify the use of the SACK option when a duplicate
is received, and the cumulative acknowledgement field in the
acknowledges all of the data in the data receiver's queue

Floyd, et al. Standards Track [Page 3]

RFC 2883 SACK Extension July 2000

4. Use of the SACK option for reporting a duplicate

This section specifies the use of SACK blocks when the SACK option
used in reporting a duplicate segment. When D-SACK is used,
first block of the SACK option should be a D-SACK block
the sequence numbers for the duplicate segment that triggers
acknowledgement. If the duplicate segment is part of a larger
of non-contiguous data in the receiver's data queue, then
following SACK block should be used to specify this larger block
Additional SACK blocks can be used to specify additional non
contiguous blocks of data, as specified in RFC 2018.

The guidelines for reporting duplicate segments are summarized below

(1) A D-SACK block is only used to report a duplicate
sequence of data received by the receiver in the most recent packet

(2) Each duplicate contiguous sequence of data received is
in at most one D-SACK block. (I.e., the receiver sends two
D-SACK blocks in subsequent packets only if the receiver receives
duplicate segments.)

(3) The left edge of the D-SACK block specifies the first
number of the duplicate contiguous sequence, and the right edge
the D-SACK block specifies the sequence number immediately
the last sequence in the duplicate contiguous sequence

(4) If the D-SACK block reports a duplicate contiguous sequence
a (possibly larger) block of data in the receiver's data queue
the cumulative acknowledgement, then the second SACK block in
SACK option should specify that (possibly larger) block of data

(5) Following the SACK blocks described above for reporting
segments, additional SACK blocks can be used for reporting
blocks of data, as specified in RFC 2018.

Note that because each duplicate segment is reported in only one
packet, information about that duplicate segment will be lost if
ACK packet is dropped in the network

4.1 Reporting Full Duplicate

We illustrate these guidelines with three examples. In each example
we assume that the data receiver has first received eight segments
500 bytes each, and has sent an acknowledgement with the
acknowledgement field set to 4000 (assuming the first sequence
is zero). The D-SACK block is underlined in each example

Floyd, et al. Standards Track [Page 4]

RFC 2883 SACK Extension July 2000

4.1.1. Example 1: Reporting a duplicate segment

Because several ACK packets are lost, the data sender
packet 3000-3499, and the data receiver subsequently receives
duplicate segment with sequence numbers 3000-3499. The
sends an acknowledgement with the cumulative acknowledgement
set to 4000, and the first, D-SACK block specifying sequence
3000-3500.

Transmitted Received ACK
Segment Segment (Including SACK Blocks

3000-3499 3000-3499 3500 (ACK dropped
3500-3999 3500-3999 4000 (ACK dropped
3000-3499 3000-3499 4000, SACK=3000-3500
---------
4.1.2. Example 2: Reporting an out-of-order segment and a
segment

Following a lost data packet, the receiver receives an out-of-
data segment, which triggers the SACK option as specified in
2018. Because of several lost ACK packets, the sender
retransmits a data packet. The receiver receives the
packet, and reports it in the first, D-SACK block

Transmitted Received ACK
Segment Segment (Including SACK Blocks

3000-3499 3000-3499 3500 (ACK dropped
3500-3999 3500-3999 4000 (ACK dropped
4000-4499 (data packet dropped
4500-4999 4500-4999 4000, SACK=4500-5000 (ACK dropped
3000-3499 3000-3499 4000, SACK=3000-3500, 4500-5000
---------

Floyd, et al. Standards Track [Page 5]

RFC 2883 SACK Extension July 2000

4.1.3. Example 3: Reporting a duplicate of an out-of-order segment

Because of a lost data packet, the receiver receives two out-of-
segments. The receiver next receives a duplicate segment for one
these out-of-order segments

Transmitted Received ACK
Segment Segment (Including SACK Blocks

3500-3999 3500-3999 4000
4000-4499 (data packet dropped
4500-4999 4500-4999 4000, SACK=4500-5000
5000-5499 5000-5499 4000, SACK=4500-5500
(duplicated packet
5000-5499 4000, SACK=5000-5500, 4500-5500
---------
4.2. Reporting Partial Duplicate

It may be possible that a sender transmits a packet that includes
or more duplicate sub-segments--that is, only part but not all of
transmitted packet has already arrived at the receiver. This
occur when the size of the sender's transmitted segments increases
which can occur when the PMTU increases in the middle of a
session, for example. The guidelines in Section 4 above apply
reporting partial as well as full duplicate segments. This
gives examples of these guidelines when reporting partial
segments

When the SACK option is used for reporting partial
segments, the first D-SACK block reports the first duplicate sub
segment. If the data packet being acknowledged contains
partial duplicate sub-segments, then only the first such
sub-segment is reported in the SACK option. We illustrate this
the examples below

4.2.1. Example 4: Reporting a single duplicate subsegment

The sender increases the packet size from 500 bytes to 1000 bytes
The receiver subsequently receives a 1000-byte packet containing
500-byte subsegment that has already been received and one which
not. The receiver reports only the already received subsegment
a single D-SACK block

Floyd, et al. Standards Track [Page 6]

RFC 2883 SACK Extension July 2000

Transmitted Received ACK
Segment Segment (Including SACK Blocks

500-999 500-999 1000
1000-1499 (delayed
1500-1999 (data packet dropped
2000-2499 2000-2499 1000, SACK=2000-2500
1000-2000 1000-1499 1500, SACK=2000-2500
1000-2000 2500, SACK=1000-1500
---------

4.2.2. Example 5: Two non-contiguous duplicate subsegments covered
the cumulative acknowledgement

After the sender increases its packet size from 500 bytes to 1500
bytes, the receiver receives a packet containing two non-
duplicate 500-byte subsegments which are less than the
acknowledgement field. The receiver reports the first such
segment in a single D-SACK block

Transmitted Received ACK
Segment Segment (Including SACK Blocks

500-999 500-999 1000
1000-1499 (delayed
1500-1999 (data packet dropped
2000-2499 (delayed
2500-2999 (data packet dropped
3000-3499 3000-3499 1000, SACK=3000-3500
1000-2499 1000-1499 1500, SACK=3000-3500
2000-2499 1500, SACK=2000-2500, 3000-3500
1000-2499 2500, SACK=1000-1500, 3000-3500
---------

4.2.3. Example 6: Two non-contiguous duplicate subsegments not
by the cumulative acknowledgement

This example is similar to Example 5, except that after the
increases the packet size, the receiver receives a packet
two non-contiguous duplicate subsegments which are above
cumulative acknowledgement field, rather than below. The first, D
SACK block reports the first duplicate subsegment, and the second
SACK block reports the larger block of non-contiguous data that
belongs to

Floyd, et al. Standards Track [Page 7]

RFC 2883 SACK Extension July 2000

Transmitted Received ACK
Segment Segment (Including SACK Blocks

500-999 500-999 1000
1000-1499 (data packet dropped
1500-1999 (delayed
2000-2499 (data packet dropped
2500-2999 (delayed
3000-3499 (data packet dropped
3500-3999 3500-3999 1000, SACK=3500-4000
1000-1499 (data packet dropped
1500-2999 1500-1999 1000, SACK=1500-2000, 3500-4000
2000-2499 1000, SACK=2000-2500, 1500-2000,
3500-4000
1500-2999 1000, SACK=1500-2000, 1500-3000,
---------
3500-4000

4.3. Interaction Between D-SACK and

RFC 1323 [RFC1323] specifies an algorithm for Protection
Wrapped Sequence Numbers (PAWS). PAWS gives a method
distinguishing between sequence numbers for new data, and
numbers from a previous cycle through the sequence number space
Duplicate segments might be detected by PAWS as belonging to
previous cycle through the sequence number space

RFC 1323 specifies that for such packets, the receiver should do
following

Send an acknowledgement in reply as specified in RFC 793 page 69,
and drop the segment

Since PAWS still requires sending an ACK, there is no
interaction between PAWS and the use of D-SACK. The D-SACK block
be included in the SACK option of the ACK, as outlined in Section 4,
independently of the use of PAWS by the TCP receiver,
independently of the determination by PAWS of the validity
invalidity of the data segment

TCP senders receiving D-SACK blocks should be aware that a
reported as a duplicate segment could possibly have been from a
cycle through the sequence number space. This is independent of
use of PAWS by the TCP data receiver. We do not anticipate that
will present significant problems for senders using D-
information

Floyd, et al. Standards Track [Page 8]

RFC 2883 SACK Extension July 2000

5. Detection of Duplicate

This extension to the SACK option enables the receiver to
report the reception of duplicate data. Because each receipt of
duplicate packet is reported in only one ACK packet, the loss of
single ACK can prevent this information from reaching the sender.
addition, we note that the sender can not necessarily trust
receiver to send it accurate information [SCWA99].

In order for the sender to check that the first (D)SACK block of
acknowledgement in fact acknowledges duplicate data, the
should compare the sequence space in the first SACK block to
cumulative ACK which is carried IN THE SAME PACKET. If the
sequence space is less than this cumulative ACK, it is an
that the segment identified by the SACK block has been received
than once by the receiver. An implementation MUST NOT compare
sequence space in the SACK block to the TCP state variable snd.
(which carries the total cumulative ACK), as this may result in
wrong conclusion if ACK packets are reordered

If the sequence space in the first SACK block is greater than
cumulative ACK, then the sender next compares the sequence space
the first SACK block with the sequence space in the second
block, if there is one. This comparison can determine if the
SACK block is reporting duplicate data that lies above the
ACK

TCP implementations which follow RFC 2581 [RFC2581] could
duplicate packets in each of the following four situations.
document does not specify what action a TCP implementation
take in these cases. The extension to the SACK option simply
the sender to detect each of these cases. Note that these
conditions are not an exhaustive list of possible cases for
packets, but are representative of the most common/likely cases
Subsequent documents will describe experimental proposals for
responses to the detection of unnecessary retransmits due
reordering, lost ACKS, or early retransmit timeouts

Floyd, et al. Standards Track [Page 9]

RFC 2883 SACK Extension July 2000

5.1. Replication by the

If a packet is replicated in the network, this extension to the
option can identify this. For example

Transmitted Received ACK
Segment Segment (Including SACK Blocks

500-999 500-999 1000
1000-1499 1000-1499 1500
(replicated
1000-1499 1500, SACK=1000-1500
---------

In this case, the second packet was replicated in the network.
ACK containing a D-SACK block which is lower than its ACK field
is not identical to a previously retransmitted segment is
of a replication by the network

WITHOUT D-SACK

If D-SACK was not used and the last ACK was piggybacked on a
packet, the sender would not know that a packet had been
in the network. If D-SACK was not used and neither of the last
ACKs was piggybacked on a data packet, then the sender
reasonably infer that either some data packet *or* the final
packet had been replicated in the network. The receipt of the D-
packet gives the sender positive knowledge that this data packet
replicated in the network (assuming that the receiver is not lying).

RESEARCH ISSUES

The current SACK option already allows the sender to
duplicate ACKs that do not acknowledge new data, but the D-
option gives the sender a stronger basis for inferring that
duplicate ACK does not acknowledge new data. The knowledge that
duplicate ACK does not acknowledge new data allows the sender
refrain from using that duplicate ACKs to infer packet loss (e.g.,
Fast Retransmit) or to send more data (e.g., Fast Recovery).

5.2. False retransmit due to

If packets are reordered in the network such that a segment
more than 3 packets out of order, TCP's Fast Retransmit
will retransmit the out-of-order packet. An example of this is
below

Floyd, et al. Standards Track [Page 10]

RFC 2883 SACK Extension July 2000

Transmitted Received ACK
Segment Segment (Including SACK Blocks

500-999 500-999 1000
1000-1499 (delayed
1500-1999 1500-1999 1000, SACK=1500-2000
2000-2499 2000-2499 1000, SACK=1500-2500
2500-2999 2500-2999 1000, SACK=1500-3000
1000-1499 1000-1499 3000
1000-1499 3000, SACK=1000-1500
---------

In this case, an ACK containing a SACK block which is lower than
ACK field and identical to a previously retransmitted segment
indicative of a significant reordering followed by a
(unnecessary) retransmission

WITHOUT D-SACK

With the use of D-SACK illustrated above, the sender knows
either the first transmission of segment 1000-1499 was delayed in
network, or the first transmission of segment 1000-1499 was
and the second transmission of segment 1000-1499 was duplicated
Given that no other segments have been duplicated in the network
this second option can be considered unlikely

Without the use of D-SACK, the sender would only know that either
first transmission of segment 1000-1499 was delayed in the network
or that either one of the data segments or the final ACK
duplicated in the network. Thus, the use of D-SACK allows the
to more reliably infer that the first transmission of
1000-1499 was not dropped

[AP99], [L99], and [LK00] note that the sender could
detect an unnecessary retransmit with the use of the
option. [LK00] proposes a timestamp-based algorithm that
the penalty for an unnecessary retransmit. [AP99] proposes
heuristic for detecting an unnecessary retransmit in an
with neither timestamps nor SACK. [L99] also proposes a two-
field as an alternate to the timestamp option for
marking the first three retransmissions of a packet. A similar
was proposed in [ISO8073].

RESEARCH ISSUES

The use of D-SACK allows the sender to detect some cases (e.g.,
no ACK packets have been lost) when a a Fast Retransmit was due
packet reordering instead of packet loss. This allows the TCP

Floyd, et al. Standards Track [Page 11]

RFC 2883 SACK Extension July 2000

to adjust the duplicate acknowledgment threshold, to prevent
unnecessary Fast Retransmits in the future. Coupled with this,
the sender determines, after the fact, that it has made
unnecessary window reduction, the sender has the option of "undoing
that reduction in the congestion window by resetting ssthresh to
value of the old congestion window, and slow-starting until
congestion window has reached that point

Any proposal for "undoing" a reduction in the congestion window
have to address the possibility that the TCP receiver could be
in its reports of received packets [SCWA99].

5.3. Retransmit Timeout Due to ACK

If an entire window of ACKs is lost, a timeout will result.
example of this is given below

Transmitted Received ACK
Segment Segment (Including SACK Blocks

500-999 500-999 1000 (ACK dropped
1000-1499 1000-1499 1500 (ACK dropped
1500-1999 1500-1999 2000 (ACK dropped
2000-2499 2000-2499 2500 (ACK dropped
(timeout
500-999 500-999 2500, SACK=500-1000
--------

In this case, all of the ACKs are dropped, resulting in a timeout
This condition can be identified because the first ACK
following the timeout carries a D-SACK block indicating
data was received

WITHOUT D-SACK

Without the use of D-SACK, the sender in this case would be unable
decide that no data packets has been dropped

RESEARCH ISSUES

For a TCP that implements some form of ACK congestion
[BPK97], this ability to distinguish between dropped data packets
dropped ACK packets would be particularly useful. In this case,
connection could implement congestion control for the return (ACK
path independently from the congestion control on the forward (data
path

Floyd, et al. Standards Track [Page 12]

RFC 2883 SACK Extension July 2000

5.4. Early Retransmit

If the sender's RTO is too short, an early retransmission timeout
occur when no packets have in fact been dropped in the network.
example of this is given below

Transmitted Received ACK
Segment Segment (Including SACK Blocks

500-999 (delayed
1000-1499 (delayed
1500-1999 (delayed
2000-2499 (delayed
(timeout
500-999 (delayed
500-999 1000
1000-1499 (delayed
1000-1499 1500
...
1500-1999 2000
2000-2499 2500
500-999 2500, SACK=500-1000
--------
1000-1499 2500, SACK=1000-1500
---------
...

In this case, the first packet is retransmitted following
timeout. Subsequently, the original window of packets arrives at
receiver, resulting in ACKs for these segments. Following this,
retransmissions of these segments arrive, resulting in ACKs
SACK blocks which identify the duplicate segments

This can be identified as an early retransmission timeout because
ACK for byte 1000 is received after the timeout with no
information, followed by an ACK which carries SACK information (500-
999) indicating that the retransmitted segment had already
received

WITHOUT D-SACK

If D-SACK was not used and one of the duplicate ACKs was
on a data packet, the sender would not know how many
packets had been received. If D-SACK was not used and none of
duplicate ACKs were piggybacked on a data packet, then the
would have sent N duplicate packets, for some N, and received
duplicate ACKs. In this case, the sender could reasonably infer

Floyd, et al. Standards Track [Page 13]

RFC 2883 SACK Extension July 2000

some data or ACK packet had been replicated in the network, or
an early retransmission timeout had occurred (or that the receiver
lying).

RESEARCH ISSUES

After the sender determines that an unnecessary (i.e., early
retransmit timeout has occurred, the sender could adjust
for setting the RTO, to prevent more unnecessary retransmit timeouts
Coupled with this, when the sender determines, after the fact,
it has made an unnecessary window reduction, the sender has
option of "undoing" that reduction in the congestion window

6. Security

This document neither strengthens nor weakens TCP's current
properties

7.

We would like to thank Mark Handley, Reiner Ludwig, and
Padmanabhan for conversations on these issues, and to thank
Allman for helpful feedback on this document

8.

[AP99] Mark Allman and Vern Paxson, On Estimating End-to-
Network Path Properties, SIGCOMM 99, August 1999.
"http://www.acm.org/sigcomm/sigcomm99/papers/session7-
3.html".

[BPS99] J.C.R. Bennett, C. Partridge, and N. Shectman,
Reordering is Not Pathological Network Behavior, IEEE/
Transactions on Networking, Vol. 7, No. 6, December 1999,
pp. 789-798.

[BPK97] Hari Balakrishnan, Venkata Padmanabhan, and Randy H. Katz
The Effects of Asymmetry on TCP Performance, Third ACM/
Mobicom Conference, Budapest, Hungary, Sep 1997.
"http://www.cs.berkeley.edu/~padmanab
index.html#Publications".

[F99] Floyd, S., Re: TCP and out-of-order delivery, Message
<199902030027.QAA06775@owl.ee.lbl.gov> to the end-to-end
interest mailing list, February 1999.
"http://www.aciri.org/floyd/notes/TCP_Feb99.email".

Floyd, et al. Standards Track [Page 14]

RFC 2883 SACK Extension July 2000

[ISO8073] ISO/IEC, Information-processing systems - Open
Interconnection - Connection Oriented Transport
Specification, Internation Standard ISO/IEC 8073,
1988.

[L99] Reiner Ludwig, A Case for Flow Adaptive Wireless links
Technical Report UCB//CSD-99-1053, May 1999.
"http://iceberg.cs.berkeley.edu/papers/Ludwig
FlowAdaptive/".

[LK00] Reiner Ludwig and Randy H. Katz, The Eifel Algorithm
Making TCP Robust Against Spurious Retransmissions,
Computer Communication Review, V. 30, N. 1, January 2000.
URL "http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr
toc-2000.html".

[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
High Performance", RFC 1323, May 1992.

[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "
Selective Acknowledgement Options", RFC 2018, April 1996.

[RFC2581] Allman, M., Paxson,V. and W. Stevens, "TCP
Control", RFC 2581, April 1999.

[SCWA99] Stefan Savage, Neal Cardwell, David Wetherall,
Anderson, TCP Congestion Control with a
Receiver, ACM Computer Communications Review, pp. 71-78, V
29, N. 5, October, 1999.
"http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc
99.html".

Floyd, et al. Standards Track [Page 15]

RFC 2883 SACK Extension July 2000

Authors'

Sally
AT&T Center for Internet Research at ICSI (ACIRI

Phone: +1 510-666-6989
EMail: floyd@aciri.
URL: http://www.aciri.org/floyd

Jamshid

Phone: 1-408-967-3806
EMail: mahdavi@novell.

Matt
Pittsburgh Supercomputing

Phone: 412 268-3319
EMail: mathis@psc.
URL: http://www.psc.edu/~mathis

Matthew
UC Berkeley Electrical Engineering & Computer Science Dept

Phone: 510-649-8914
EMail: podolsky@eecs.berkeley.
URL: http://www.eecs.berkeley.edu/~

Floyd, et al. Standards Track [Page 16]

RFC 2883 SACK Extension July 2000

Full Copyright

Copyright (C) The Internet Society (2000). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Floyd, et al. Standards Track [Page 17]

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