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











Network Working Group J.
Request for Comments: 1025
September 1987


TCP AND IP BAKE


Status of This

This memo describes some of the procedures, scoring, and tests
in the TCP and IP bake offs held in the early development of
protocols. These procedures and tests may still be of use in
newly implemented TCP and IP modules. Distribution of this memo
unlimited



In the early days of the development of TCP and IP, when there
very few implementations and the specifications were still evolving
the only way to determine if an implementation was "correct" was
test it against other implementations and argue that the
showed your own implementation to have done the right thing.
tests and discussions could, in those early days, as likely
the specification as change the implementation

There were a few times when this testing was focused,
together all known implementations and running through a set of
in hopes of demonstrating the N squared connectivity and
implementation of the various tricky cases. These events were
"Bake Offs".

An early version of the list of tests included here appears in IEN-69
of October 1978. A demonstration of four TCP implementations
held at the Defense Communication Engineering Center in Reston
Virginia on 4 December 1978, and reported in IEN-70 of December 1978.
A bake off of six implementations was held 27-28 January 1979
USC-Information Sciences Institute in Marina del Rey, California
reported in IEN-77 of February 1979. And a distributed bake off
held in April 1980 over the network and reported in IEN-145 of
1980.

The following section reproduces (with very slight editing)
procedure, tests, and scoring of the April 1980 Bake Off







Postel [Page 1]

RFC 1025 TCP and IP Bake Off September 1987




This is the procedure for the TCP and IP Bake Off. Each
of a TCP and IP is to perform the following tests and to report
results. In general, this is done by using a test program or
Telnet program to open connections to your own or other
implementations

Some test are made more interesting by the use of a "flakeway".
flakeway is a purposely flakey gateway. It should have
parameters that can be adjusted while it is running to specify
percentage of datagrams to be dropped, a percentage of datagrams
be corrupted and passed on, and a percentage of datagrams to
reordered so that they arrive in a different order than sent

Many of the following apply for each distinct TCP contacted (
example, in the Middleweight Division there is a possibility of 20
points for each other TCP in the Bake Off).

Note Bene: Checksums must be enforced. No points will be awarded
the checksum test is disabled

Featherweight

1 point for talking to yourself (opening a connection).

1 point for saying something to yourself (sending and
data).

1 point for gracefully ending the conversation (closing
connection without crashing).

2 points for repeating the above without reinitializing
TCP

5 points for a complete conversation via the testing gateway

Middleweight

2 points for talking to someone else (opening a connection).

2 points for saying something to someone else (sending
receiving data).

2 points for gracefully ending the conversation (closing
connection without crashing).





Postel [Page 2]

RFC 1025 TCP and IP Bake Off September 1987


4 points for repeating the above without reinitializing
TCP

10 points for a complete conversation via the testing gateway

Heavyweight

10 points for being able to talk to more than one other TCP
the same time (multiple connections open and
simultaneously with different TCPs).

10 points for correctly handling urgent data

10 points for correctly handling sequence number wraparound

10 points for correctly being able to process a "Kamikaze
packet (AKA nastygram, christmas tree packet, lamp
segment, et al.). That is, correctly handle a segment with
maximum combination of features at once (e.g., a SYN URG
FIN segment with options and data).

30 points for KOing your opponent with legal blows. (That is
operate a connection until one TCP or the other crashes,
surviving TCP has KOed the other. Legal blows are
that meet the requirements of the specification.)

20 points for KOing your opponent with dirty blows. (
blows are segments that violate the requirements of
specification.)

10 points for showing your opponents checksum test is faulty
disabled

Host & Gateway IP

25 points for doing fragmentation and reassembly

15 points for doing loose source route option

15 points for doing strict source route option

10 points for doing return route option

10 points for using source quench messages

10 points for using routing advice messages

5 points for doing something with the type of service



Postel [Page 3]

RFC 1025 TCP and IP Bake Off September 1987


5 points for doing something with the security option

5 points for doing something with the timestamp option

5 points for showing that a gateway forwards datagrams
decreasing the time to live (showing a gateway is faulty).

5 points for showing that a gateway forwards datagrams with
time to live equal zero (showing a gateway is faulty).

10 points for showing that a gateway or hosts checksum test
faulty or disabled (showing a gateway is faulty).

Bonus

10 points for the best excuse

20 points for the fewest excuses

30 points for the longest conversation

40 points for the most simultaneous connections

50 points for the most simultaneous connections with
TCPs



The following tests have been identified for checking
capabilities of a TCP implementation. These may be useful
attempting to KO an opponent

1. Single connection. Open & close a single connection
times

2. Multi connections. Open several
simultaneously. Two connections to the same
(i.e., a-b and a-c) check proper separation of data

3. Half Open Connection. Open a connection, crash local
and attempt to open same connection again










Postel [Page 4]

RFC 1025 TCP and IP Bake Off September 1987


4. Piggy-back Loop. Open connections via Telnet

user telnet--->TCP--->IP--->net--->IP--->TCP--->server
|

server telnet<---TCP<---IP<---net<---IP<---TCP<---user
|

user telnet--->...

5. Maximum connections. Open connections between a pair
TCP until refused or worse

6. Refused connection. Open a connection to a non-
socket, does it get refused

7. Zero Window. Try to send data to a TCP that is
a zero window

8. Fire Hose. Make many connections to data source ports,
connections to a data sink and send as fast as you can

9. Urgent Test. Try to send data to a user program that
receives data when in urgent mode

10. Kamikazi Segment. Send and receive nastygrams.
nastygram is a segment with SYN, EOL, URG, and FIN on
carrying one octet of data

11. Sequence Wraparound. Test proper functioning when
numbers (a) pass 2**31 (i.e., go from plus to "minus")
(b) pass 2**32 (i.e., go from 2**32-1 to 0).

12. Buffer size. With buffer size not equal to one, send
in segments of various sizes, use urgent occasionally

13. Send a nastygram into a half open connection when
sequence number is about to wrap around













Postel [Page 5]

RFC 1025 TCP and IP Bake Off September 1987


New

The above tests check for basic operation and handling of some of
tricky cases. They do not consider performance in any way, or
to see if some of the recently developed ideas have been implemented

New

1. The John Nagel Procedures (RFC-896).

2. The Van Jacobson Procedures (slow start, RTT measurements
etc).

3. The SQuID Procedures (RFC-1016).

Performance

Performance tests are difficult to specify because the
depend so much on the state of the environment of the test
Here are a few possibilities

1. FTP Throughput: Send a 1 megabyte file to a locally
machine on an Ethernet measuring the elapsed time

2. FTP Throughput: Send a 1 megabyte file to a locally
machine on an ARPANET measuring the elapsed time

3. NETBLT Throughput: Send a 1 megabyte file to a
nearby machine on an Ethernet measuring the elapsed time

4. NETBLT Throughput: Send a 1 megabyte file to a
nearby machine on an ARPANET measuring the elapsed time

5. Character Test: Use a test program to send a character
TCP to the Echo Server (RFC-862), time the round trip (
the time the character is sent until the echo is
to the test program).



For History Buffs Only

The following item was in the original 1980 tests, but has
moved to this appendix since it no longer applies

10 points for correctly handling rubber baby buffer bumpers
both directions (End of Letter sequence number adjustments).




Postel [Page 6]







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







Spectrum