README.ipfragmentation
=======================

19-May-2003 - Mathias Koehrer (mathias_koehrer@yahoo.de) (original version)
21-Oct-2003 - Jan Kiszka (jan.kiszka@web.de)


This file documents the restrictions and pitfalls when using fragmented IP
packets with RTnet.


Introduction:
-------------
Ethernet provides 1500 bytes of payload within each packet. Subtracting the IP
header (20 bytes without options) and the UDP header (8 bytes), this leaves
1472 bytes of data for the (UDP) user. When sending larger packets, the RTnet
implementation of IP fragments the packet and sends it in multiple chunks over
the network. When a RTnet station receives a sequence of fragmented IP packets,
it reassembles it and passed the whole packet to the next layer (UDP)
afterwards.


Restrictions:
-------------
Incoming IP fragments are collected by the IP layer. The collector mechanism is
a global resource, when all collector slots are used, unassignable fragmented
packets are dropped! In order to guarantee bounded execution time of the
collector lookup mechanism, it is not possible to provide an unlimited number
of collectors (currently 10 are support, see ipv4/ip_fragment.c). Therefore, be
careful how many fragmented packets all of your stations are producing and if
one receiver might be overwhelmed with fragments!

Fragmented IP packets are generated AND received at the expense of the socket
rtskb pool. Adjust the pool size appropriately to provide sufficient rtskbs
(see also examples/frap_ip).

To identify the destination socket and to simplify the defragmentation, all IP
fragments must arrive in a strictly ascending order. Unordered packets are
dropped, if they can be assigned to an existing collector, the already
collected fragments are also cleaned up. However, for typically isolated
real-time networks, this requirement can be easily fulfilled.


Known Issues:
-------------
When sending fragmented IP packets over a NIC without RTmac being installed,
the NIC's transmission queue may easily overflow (take a look at the driver
source for the exact limit - typically TX_RING_SIZE). This is due to the still
lacking flow control for packet transmission. Will hopefully be fixed soon...