This directory contains "plug-in" classes that define the actual "TCP
flavour" to be used. You can configure TCP to use a particular "flavour" or
algorithm class by setting its tcpAlgorithmClass NED parameter to the given
class name.

In practice, you do it by adding either this:
**.tcp.tcpAlgorithmClass="TCPReno" or this:
**.tcp.tcpAlgorithmClass="TCPTahoe" or this:
**.tcp.tcpAlgorithmClass="TCPNewReno" or this:
**.tcp.tcpAlgorithmClass="TCPNoCongestionControl" or this:
**.tcp.tcpAlgorithmClass="DumbTCP" to your omnetpp.ini.

(It is also possible for apps to specify it individually for each
connection in the active/passive open commands, but this is probably not
that useful in practice).

What is inside these "flavour" classes?

TCP implementations may differ significantly in the presence and flavour of
congestion control, fast retransmit/recovery, selective acknowledgement and
other schemes -- while the "base part", defined in RFC 793 is always the
same. In this TCP model, this "base" part is implemented in the
TCPConnection class, while the rest is outsourced to "flavour" classes that
are used via the TCPAlgorithm interface (an abstract base class).

TCP congestion control, fast retransmit/recovery etc. algorithms are
encapsulated into the "flavour" class, subclassed from TCPAlgorithm. Thus
one can create several classes, all subclassed from TCPAlgorithm which
provide various TCP behaviours, and choose one of them for any particular
simulation. Examples of such classes can be e.g. Reno, NewReno, LinuxTCP,
etc. The particular class to be used is selected at runtime (via a module
parameter, e.g. from omnetpp.ini). This feature makes it easier to
experiment with various flavours of TCP, test experimental congestion
control schemes etc.



