As per Relevance of the word congestion, we have this rfc below:
Network Working Group S.
Request for Comments: 3155 G.
BCP: 50 M.
Category: Best Current Practice V.
N.
August 2001
End-to-end Performance Implications of Links with
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document discusses the specific TCP mechanisms that
problematic in environments with high uncorrected error rates,
discusses what can be done to mitigate the problems
introducing intermediate devices into the connection
Table of
1.0 Introduction ............................................. 2
1.1 Should you be reading this recommendation? ........... 3
1.2 Relationship of this recommendation to PEPs ........... 4
1.3 Relationship of this recommendation to Link
Mechanisms............................................. 4
2.0 Errors and Interactions with TCP Mechanisms .............. 5
2.1 Slow Start and Congestion Avoidance [RFC2581] ......... 5
2.2 Fast Retransmit and Fast Recovery [RFC2581] ........... 6
2.3 Selective Acknowledgements [RFC2018, RFC2883] ......... 7
3.0 Summary of Recommendations ............................... 8
4.0 Topics For Further Work .................................. 9
4.1 Achieving, and maintaining, large windows ............. 10
5.0 Security Considerations .................................. 11
6.0 IANA Considerations ...................................... 11
7.0 Acknowledgements ......................................... 11
References ................................................... 11
Authors' Addresses ........................................... 14
Full Copyright Statement ..................................... 16
Dawkins, et al. Best Current Practice [Page 1]
RFC 3155 PILC - Links with Errors August 2001
1.0
The rapidly-growing Internet is being accessed by an
wide range of devices over an increasingly wide variety of links.
least some of these links do not provide the degree of
that hosts expect, and this expansion into unreliable links
some Internet protocols, especially TCP [RFC793], to perform poorly
Specifically, TCP congestion control [RFC2581], while appropriate
connections that lose traffic primarily because of congestion
buffer exhaustion, interacts badly with uncorrected errors when
connections traverse links with high uncorrected error rates.
result is that sending TCPs may spend an excessive amount of
waiting for acknowledgement that do not arrive, and then,
these losses are not due to congestion-related buffer exhaustion,
sending TCP transmits at substantially reduced traffic levels as
probes the network to determine "safe" traffic levels
This document does not address issues with other transport protocols
for example, UDP
Congestion avoidance in the Internet is based on an assumption
most packet losses are due to congestion. TCP's congestion
strategy treats the absence of acknowledgement as a
signal. This has worked well since it was introduced in 1988 [VJ
DCAC], because most links and subnets have relatively low error
in normal operation, and congestion is the primary cause of loss
these environments. However, links and subnets that do not enjoy
uncorrected error rates are becoming more prevalent in parts of
Internet. In particular, these include terrestrial and
wireless links. Users relying on traffic traversing these links
see poor performance because their TCP connections are
excessive time in congestion avoidance and/or slow start
triggered by packet losses due to transmission errors
The recommendations in this document aim at improving utilization
available path capacity over such high error-rate links in ways
do not threaten the stability of the Internet
Applications use TCP in very different ways, and these
interactions with TCP's behavior [RFC2861]. Nevertheless, it
possible to make some basic assumptions about TCP flows
Accordingly, the mechanisms discussed here are applicable to all
of TCP, albeit in varying degrees according to different
(as noted where appropriate).
Dawkins, et al. Best Current Practice [Page 2]
RFC 3155 PILC - Links with Errors August 2001
This recommendation is based on the explicit assumption that
changes to the entire installed base of routers and hosts are not
practical possibility. This constrains any changes to hosts that
directly affected by errored links
1.1 Should you be reading this recommendation
All known subnetwork technologies provide an "imperfect"
service - the bit error rate is non-zero. But there's no obvious
for end stations to tell the difference between packets discarded
to congestion and losses due to transmission errors
If a directly-attached subnetwork is reporting transmission errors
a host, these reports matter, but we can't rely on
transmission error reports to both hosts
Another way of deciding if a subnetwork should be considered to
a "high error rate" is by appealing to mathematics
An approximate formula for the TCP Reno response function is given
[PFTK98]:
T = --------------------------------------------------
RTT*sqrt(2p/3) + tRTO*(3*sqrt(3p/8))*p*(1 + 32p**2)
T = the sending rate in bytes per
s = the packet size in
RTT = round-trip time in
tRTO = TCP retransmit timeout value in
p = steady-state packet loss
If one plugs in an observed packet loss rate, does the math and
sees predicted bandwidth utilization that is greater than the
speed, the connection will not benefit from recommendations in
document, because the level of packet losses being encountered won'
affect the ability of TCP to utilize the link. If, however,
predicted bandwidth is less than the link speed, packet losses
affecting the ability of TCP to utilize the link
If further investigation reveals a subnetwork with
transmission error rates, the recommendations in this document
improve the ability of TCP to utilize the link
Dawkins, et al. Best Current Practice [Page 3]
RFC 3155 PILC - Links with Errors August 2001
A few caveats are in order, when doing this calculation
(1) the RTT is the end-to-end RTT, not the link RTT
(2) Max(1.0, 4*RTT) can be substituted as a simplification
tRTO
(3) losses may be bursty - a loss rate measured over an
that includes multiple bursty loss events may understate
impact of these loss events on the sending rate
1.2 Relationship of this recommendation to
This document discusses end-to-end mechanisms that do not
TCP-level awareness by intermediate nodes. This places
limitations on what the end nodes can know about the nature of
that are occurring between the end nodes. Attempts to
heuristics to distinguish between congestion and transmission
have not been successful [BV97, BV98, BV98a]. This restriction
relaxed in an informational document on Performance Enhancing
(PEPs) [RFC3135]. Because PEPs can be placed on boundaries
network characteristics change dramatically, PEPs have an
opportunity to improve performance over links with
errors
However, generalized use of PEPs contravenes the end-to-end
and is highly undesirable given their deleterious implications,
include the following: lack of fate sharing (a PEP adds a third
of failure besides the endpoints themselves), end-to-end
and diagnostics, preventing end-to-end security (particularly
layer security such as IPsec), mobility (handoffs are much
complex because state must be transferred), asymmetric routing (
typically require being on both the forward and reverse paths of
connection), scalability (PEPs add more state to maintain),
transparency and guarantees
Not every type of PEP has all the drawbacks listed above
Nevertheless, the use of PEPs may have very serious
which must be weighed carefully
1.3 Relationship of this recommendation to Link Layer
This recommendation is for use with TCP over subnetwork
(link layers) that have already been deployed. Subnetworks that
intended to carry Internet protocols, but have not been
specified are the subject of a best common practices (BCP)
which has been developed or is under development by the
Dawkins, et al. Best Current Practice [Page 4]
RFC 3155 PILC - Links with Errors August 2001
Implications of Link Characteristics WG (PILC) [PILC-WEB]. This
document is aimed at designers who still have the opportunity
reduce the number of uncorrected errors TCP will encounter
2.0 Errors and Interactions with TCP
A TCP sender adapts its use of network path capacity based
feedback from the TCP receiver. As TCP is not able to
between losses due to congestion and losses due to
errors, it is not able to accurately determine available
capacity in the presence of significant uncorrected errors
2.1 Slow Start and Congestion Avoidance [RFC2581]
Slow Start and Congestion Avoidance [RFC2581] are essential to
current stability of the Internet. These mechanisms were designed
accommodate networks that do not provide explicit
notification. Although experimental mechanisms such as [RFC2481]
moving in the direction of explicit congestion notification,
effect of ECN on ECN-aware TCPs is essentially the same as the
of implicit congestion notification through congestion-related loss
except that ECN provides this notification before packets are lost
and must then be retransmitted
TCP connections experiencing high error rates on their paths
badly with Slow Start and with Congestion Avoidance, because
error rates make the interpretation of losses ambiguous - the
cannot know whether detected losses are due to congestion or to
corruption. TCP makes the "safe" choice and assumes that the
are due to congestion
- Whenever sending TCPs receive three out-of-
acknowledgement, they assume the network is mildly
and invoke fast retransmit/fast recovery (described below).
- Whenever TCP's retransmission timer expires, the sender
that the network is congested and invokes slow start
- Less-reliable link layers often use small link MTUs.
slows the rate of increase in the sender's window size
slow start, because the sender's window is increased in
of segments. Small link MTUs alone don't improve reliability
Path MTU discovery [RFC1191] must also be used to
fragmentation. Path MTU discovery allows the most
opening of the sender's window size during slow start, but
number of round trips may still be required to open the
completely
Dawkins, et al. Best Current Practice [Page 5]
RFC 3155 PILC - Links with Errors August 2001
Recommendation: Any standards-conformant TCP will implement
Start and Congestion Avoidance, which are MUSTs in STD 3 [RFC1122].
Recommendations in this document will not interfere with
mechanisms
2.2 Fast Retransmit and Fast Recovery [RFC2581]
TCP provides reliable delivery of data as a byte-stream to
application, so that when a segment is lost (whether due to
congestion or transmission loss), the receiver TCP
must wait to deliver data to the receiving application until
missing data is received. The receiver TCP implementation
missing segments by segments arriving with out-of-order
numbers
TCPs should immediately send an acknowledgement when data is
out-of-order [RFC2581], providing the next expected sequence
with no delay, so that the sender can retransmit the required data
quickly as possible and the receiver can resume delivery of data
the receiving application. When an acknowledgement carries the
expected sequence number as an acknowledgement that has already
sent for the last in-order segment received, these
are called "duplicate ACKs".
Because IP networks are allowed to reorder packets, the receiver
send duplicate acknowledgments for segments that arrive out of
due to routing changes, link-level retransmission, etc. When a
sender receives three duplicate ACKs, fast retransmit [RFC2581]
allows it to infer that a segment was lost. The sender
what it considers to be this lost segment without waiting for
full retransmission timeout, thus saving time
After a fast retransmit, a sender halves its congestion window
invokes the fast recovery [RFC2581] algorithm, whereby it
congestion avoidance from a halved congestion window, but does
invoke slow start from a one-segment congestion window as it would
after a retransmission timeout. As the sender is still
dupacks, it knows the receiver is receiving packets sent, so the
reduction after a timeout when no communication has been received
not called for. This relatively safe optimization also saves time
It is important to be realistic about the maximum throughput that
can have over a connection that traverses a high error-rate link.
general, TCP will increase its congestion window beyond the delay
bandwidth product. TCP's congestion avoidance strategy is additive
increase, multiplicative-decrease, which means that if
errors are encountered before the congestion window
completely from a 50-percent reduction, the effect can be a "
Dawkins, et al. Best Current Practice [Page 6]
RFC 3155 PILC - Links with Errors August 2001
spiral" of the congestion window due to additional 50-
reductions. Even using Fast Retransmit/Fast Recovery, the
will halve the congestion window each time a window contains one
more segments that are lost, and will re-open the window by
additional segment for each congestion window's worth
acknowledgement received
If a connection's path traverses a link that loses one or
segments during this recovery period, the one-half reduction
place again, this time on a reduced congestion window - and
downward spiral will continue to hold the congestion window
path capacity until the connection is able to recover completely
additive increase without experiencing loss
Of course, no downward spiral occurs if the error rate is
high and the congestion window always remains small;
multiplicative-increase "slow start" will be exited early, and
congestion window remains low for the duration of the TCP connection
In links with high error rates, the TCP window may remain
small for long periods of time
Not all causes of small windows are related to errors. For example
HTTP/1.0 commonly closes TCP connections to indicate
between requested resources. This means that these applications
constantly closing "trained" TCP connections and opening "untrained
TCP connections which will execute slow start, beginning with one
two segments. This can happen even with HTTP/1.1, if
configure their HTTP/1.1 servers to close connections instead
waiting to see if the connection will be useful again
A small window - especially a window of less than four segments -
effectively prevents the sender from taking advantage of
Retransmits. Moreover, efficient recovery from multiple
within a single window requires adoption of new proposals (
[RFC2582]).
Recommendation: Implement Fast Retransmit and Fast Recovery at
time. This is a widely-implemented optimization and is currently
Proposed Standard level. [RFC2488] recommends implementation of
Retransmit/Fast Recovery in satellite environments
2.3 Selective Acknowledgements [RFC2018, RFC2883]
Selective Acknowledgements [RFC2018] allow the repair of
segment losses per window without requiring one (or more) round-
per loss
Dawkins, et al. Best Current Practice [Page 7]
RFC 3155 PILC - Links with Errors August 2001
[RFC2883] proposes a minor extension to SACK that allows
TCPs to provide more information about the order of delivery
segments, allowing "more robust operation in an environment
reordered packets, ACK loss, packet replication, and/or
retransmit timeouts". Unless explicitly stated otherwise, in
document, "Selective Acknowledgements" (or "SACK") refers to
combination of [RFC2018] and [RFC2883].
Selective acknowledgments are most useful in LFNs ("Long
Networks") because of the long round trip times that may
encountered in these environments, according to Section 1.1
[RFC1323], and are especially useful if large windows are required
because there is a higher probability of multiple segment losses
window
On the other hand, if error rates are generally low but
higher due to channel conditions, TCP will have the opportunity
increase its window to larger values during periods of
channel conditions between bursts of errors. When bursts of
occur, multiple losses within a window are likely to occur. In
case, SACK would provide benefits in speeding the recovery
preventing unnecessary reduction of the window size
Recommendation: Implement SACK as specified in [RFC2018] and
by [RFC2883], both Proposed Standards. In cases where SACK cannot
enabled for both sides of a connection, TCP senders may use
[RFC2582] to better handle partial ACKs and multiple losses within
single window
3.0 Summary of
The Internet does not provide a widely-available loss
mechanism that allows TCP to distinguish between congestion loss
transmission error. Because congestion affects all traffic on a
while transmission loss affects only the specific
encountering uncorrected errors, avoiding congestion has to
precedence over quickly repairing transmission errors. This
that the best that can be achieved without new feedback mechanisms
minimizing the amount of time that is spent unnecessarily
congestion avoidance
The Fast Retransmit/Fast Recovery mechanism allows quick repair
loss without giving up the safety of congestion avoidance. In
for Fast Retransmit/Fast Recovery to work, the window size must
large enough to force the receiver to send three
acknowledgments before the retransmission timeout interval expires
forcing full TCP slow-start
Dawkins, et al. Best Current Practice [Page 8]
RFC 3155 PILC - Links with Errors August 2001
Selective Acknowledgements (SACK) extend the benefit of
Retransmit/Fast Recovery to situations where multiple segment
in the window need to be repaired more quickly than can
accomplished by executing Fast Retransmit for each segment loss,
to discover the next segment loss
These mechanisms are not limited to wireless environments. They
usable in all environments
4.0 Topics For Further
"Limited Transmit" [RFC3042] has been specified as an
extending Fast Retransmit/Fast Recovery for TCP connections
small congestion windows that will not trigger three
acknowledgments. This specification is deemed safe, and it
provides benefits for TCP connections that experience a large
of packet (data or ACK) loss. Implementors should evaluate
standards track specification for TCP in loss environments
Delayed Duplicate Acknowledgements [MV97, VMPM99] attempts to
TCP-level retransmission when link-level retransmission is still
progress, adding additional traffic to the network. This proposal
worthy of additional study, but is not recommended at this time
because we don't know how to calculate appropriate amounts of
for an arbitrary network topology
It is not possible to use explicit congestion notification [RFC2481]
as a surrogate for explicit transmission error notification (
matter how much we wish it was!). Some mechanism to provide
notification of transmission error would be very helpful. This
be more easily provided in a PEP environment, especially when the
is the "first hop" in a connection path, because current
mechanisms do not distinguish between transmission error to a
and transmission error to the header. Furthermore, if the header
damaged, sending explicit transmission error notification to
right endpoint is problematic
Losses that take place on the ACK stream, especially while a TCP
learning network characteristics, can make the data stream
bursty (resulting in losses on the data stream, as well).
ways of limiting this burstiness have been proposed, including
transmit pacing at the sender and ACK rate control within
network
"Appropriate Byte Counting" (ABC) [ALL99], has been proposed as a
of opening the congestion window based on the number of bytes
have been successfully transfered to the receiver, giving
appropriate behavior for application protocols that
Dawkins, et al. Best Current Practice [Page 9]
RFC 3155 PILC - Links with Errors August 2001
connections with relatively short packets. For SMTP [RFC2821],
instance, the client might send a short HELO packet, a short
packet, one or more short RCPT packets, and a short DATA packet -
followed by the entire mail body sent as maximum-length packets.
ABC TCP sender would not use ACKs for each of these short packets
increase the congestion window to allow additional full-
packets. ABC is worthy of additional study, but is not
at this time, because ABC can lead to increased burstiness
acknowledgments are lost
4.1 Achieving, and maintaining, large
The recommendations described in this document will aid TCPs
injecting packets into ERRORed connections as fast as
without destabilizing the Internet, and so optimizing the use
available bandwidth
In addition to these TCP-level recommendations, there is
additional work to do at the application level, especially with
dominant application protocol on the World Wide Web, HTTP
HTTP/1.0 (and earlier versions) closes TCP connections to signal
receiver that all of a requested resource had been transmitted
Because WWW objects tend to be small in size [MOGUL], TCPs
HTTP/1.0 traffic experience difficulty in "training" on
path capacity (a substantial portion of the transfer has
happened by the time TCP exits slow start).
Several HTTP modifications have been introduced to improve
interaction with TCP ("persistent connections" in HTTP/1.0,
improvements in HTTP/1.1 [RFC2616]). For a variety of reasons,
HTTP interactions are still HTTP/1.0-style - relatively short-lived
Proposals which reuse TCP congestion information across connections
like TCP Control Block Interdependence [RFC2140], or the more
Congestion Manager [BS00] proposal, will have the effect of
multiple parallel connections impact the network as if they were
single connection, "trained" after a single startup transient.
proposals are critical to the long-term stability of the Internet
because today's users always have the choice of clicking on
"reload" button in their browsers and cutting off TCP's
backoff - replacing connections which are building knowledge of
available bandwidth with connections with no knowledge at all
Dawkins, et al. Best Current Practice [Page 10]
RFC 3155 PILC - Links with Errors August 2001
5.0 Security
A potential vulnerability introduced by Fast Retransmit/Fast
is (as pointed out in [RFC2581]) that an attacker may force
connections to grind to a halt, or, more dangerously, behave
aggressively. The latter possibility may lead to
collapse, at least in some regions of the network
Selective acknowledgments is believed to neither strengthen
weaken TCP's current security properties [RFC2018].
Given that the recommendations in this document are performed on
end-to-end basis, they continue working even in the presence of end
to-end IPsec. This is in direct contrast with mechanisms such
PEP's which are implemented in intermediate nodes (section 1.2).
6.0 IANA
This document is a pointer to other, existing IETF standards.
are no new IANA considerations
7.0
This recommendation has grown out of RFC 2757, "Long Thin Networks",
which was in turn based on work done in the IETF TCPSAT
group. The authors are indebted to the active members of the
working group. In particular, Mark Allman and Lloyd Wood gave
copious and insightful feedback, and Dan Grossman and Jamshid
provided text replacements
[ALL99] M. Allman, "TCP Byte Counting Refinements," ACM
Communication Review, Volume 29, Number 3, July 1999.
http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc
99.
[BS00] Balakrishnan, H. and S. Seshan, "The Congestion Manager",
RFC 3124, June 2001.
[BV97] S. Biaz and N. Vaidya, "Using End-to-end Statistics
Distinguish Congestion and Corruption Losses: A
Result," Texas A&M University, Technical Report 97-009,
August 18, 1997.
Dawkins, et al. Best Current Practice [Page 11]
RFC 3155 PILC - Links with Errors August 2001
[BV98] S. Biaz and N. Vaidya, "Sender-Based heuristics
Distinguishing Congestion Losses from
Transmission Losses," Texas A&M University,
Report 98-013, June 1998.
[BV98a] S. Biaz and N. Vaidya, "Discriminating Congestion
from Wireless Losses using Inter-Arrival Times at
Receiver," Texas A&M University, Technical Report 98-014,
June 1998.
[MOGUL] "The Case for Persistent-Connection HTTP", J. C. Mogul
Research Report 95/4, May 1995. Available
http://www.research.digital.com/wrl/techreports/abstracts
95.4.
[MV97] M. Mehta and N. Vaidya, "Delayed Duplicate
Acknowledgements: A Proposal to Improve Performance
TCP on Wireless Links," Texas A&M University, December 24,
1997. Available
http://www.cs.tamu.edu/faculty/vaidya/mobile.
[PILC-WEB] http://pilc.grc.nasa.gov
[PFTK98] Padhye, J., Firoiu, V., Towsley, D. and J.Kurose, "
Throughput: A simple model and its empirical validation",
SIGCOMM Symposium on Communications Architectures
Protocols, August 1998.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
793, September 1981.
[RFC2821] Klensin, J., Editor, "Simple Mail Transfer Protocol",
2821, April 2001.
[RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1191] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[RFC1323] Jacobson, V., Braden, R. and D. Borman. "TCP
for High Performance", RFC 1323, May 1992.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow "
Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140,
April 1997.
Dawkins, et al. Best Current Practice [Page 12]
RFC 3155 PILC - Links with Errors August 2001
[RFC2309] Braden, B., Clark, D., Crowcrfot, J., Davie, B., Deering
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shecker
S., Wroclawski, J. and L, Zhang, "Recommendations on
Management and Congestion Avoidance in the Internet",
2309, April 1998.
[RFC2481] Ramakrishnan K. and S. Floyd, "A Proposal to add
Congestion Notification (ECN) to IP", RFC 2481,
1999.
[RFC2488] Allman, M., Glover, D. and L. Sanchez. "Enhancing TCP
Satellite Channels using Standard Mechanisms", BCP 28,
2488, January 1999.
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP
Control", RFC 2581, April 1999.
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification
TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach P. and T. Berners-Lee, "
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2861] Handley, H., Padhye, J. and S., Floyd, "TCP
Window Validation", RFC 2861, June 2000.
[RFC2883] Floyd, S., Mahdavi, M., Mathis, M. and M. Podlosky, "
Extension to the Selective Acknowledgement (SACK)
for TCP", RFC 2883, August 1999.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
2923, September 2000.
[RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "
TCP's Loss Recovery Using Limited Transmit", RFC 3042,
January, 2001.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z
Shelby, "Performance Enhancing Proxies Intended
Mitigate Link-Related Degradations", RFC 3135, June 2001.
[VJ-DCAC] Jacobson, V., "Dynamic Congestion Avoidance / Control" e
mail dated February 11, 1988, available
http://www.kohala.com/~rstevens/vanj.88feb11.
Dawkins, et al. Best Current Practice [Page 13]
RFC 3155 PILC - Links with Errors August 2001
[VMPM99] N. Vaidya, M. Mehta, C. Perkins, and G. Montenegro
"Delayed Duplicate Acknowledgements: A TCP-
Approach to Improve Performance of TCP over Wireless,"
Technical Report 99-003, Computer Science Dept., Texas A&
University, February 1999. Also, to appear in Journal
Wireless Communications and Wireless Computing (
Issue on Reliable Transport Protocols for
Computing).
Authors'
Questions about this document may be directed to
Spencer
Fujitsu Network
2801 Telecom
Richardson, Texas 75082
Phone: +1-972-479-3782
EMail: spencer.dawkins@fnc.fujitsu.
Gabriel E.
Sun
Laboratories,
29, chemin du Vieux
38240
Phone: +33 476 18 80 45
EMail: gab@sun.
Markku
Department of Computer
University of
P.O. Box 26 (Teollisuuskatu 23)
FIN-00014
Phone: +358-9-1914-4179
EMail: kojo@cs.helsinki.
Dawkins, et al. Best Current Practice [Page 14]
RFC 3155 PILC - Links with Errors August 2001
Vincent
Alcatel Internetworking, Inc
26801 W. Agoura
Calabasas, CA, 91301
Phone: +1 818 878 4485
EMail: vincent.magret@alcatel.
Nitin H.
458 Coodinated Science Laboratory, MC-228
1308 West Main
Urbana, IL 61801
Phone: 217-265-5414
E-mail: nhv@crhc.uiuc.
Dawkins, et al. Best Current Practice [Page 15]
RFC 3155 PILC - Links with Errors August 2001
Full Copyright
Copyright (C) The Internet Society (2001). 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
Dawkins, et al. Best Current Practice [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
