Roadshow MTU and MRU

[duga]

Perhaps of interest for someone:

From the SDK (version 1.5):

/*
* Default maximum segment size for TCP.
* With an IP MSS of 576, this is 536,
* but 512 is probably more convenient.
* This should be defined as MIN(512, IP_MSS - sizeof (struct tcpiphdr)).
*/
#define TCP_MSS 512

/*
* Internet implementation parameters.
*/
#define MAXTTL 255 /* maximum time to live (seconds) */
#define IPDEFTTL 64 /* default ttl, from RFC 1340 */
#define IPFRAGTTL 60 /* time to live for frags, slowhz */
#define IPTTLDEC 1 /* subtracted when forwarding */

#define IP_MSS 576 /* default maximum segment size */


Why is TCP_MSS set to 512 and not 536?

[olsen]

Does Roadshow set and respect the TCP maximum segment size (MSS) option?

Yes, through the RoadshowControl command. But it should also respect the MTU size of the first router it passes traffic through: if that router states that it cannot handle IP datagrams larger than what Roadshow hoped for, Roadshow will adapt.

PPPoE, VPNs or other tunnels may reduce the path MTU. In most cases, the box reducing the MTU applies MSS clamping, i.e., it rewrites the MSS to a lower value in order to make sure both sides don't send packets that are too large. Normally that is because PMTUD often breaks, but with Roadshow that would be important because otherwise a lot of fragmentation will occur which is bad for performance and may also be blocked by firewalls.

There's the next problem: the TCP/IP stack which Roadshow uses was published before path MTU discovery was merged into the BSD kernel code. I investigated retrofitting this through code patches from the early NetBSD releases but it turned out to involve a massive set of changes which (among other things) also include path MTU discovery. So retrofitting would amoung to porting the TCP/IP kernel stack all over again

I wonder how much checksum offloading will help for performance. If the checksum calculation is done during a copy cycle that needs to happen anyway it's basically free on any decent CPU, and remember, we're almost entirely talking about 10 Mbps cards.

Memory and bus bandwidth are the limiting factors here. On a classic 10 Mbit/s Ethernet device the transmit buffer sits in Zorro II space and is slow to read/write. You might get lucky by precalculating the IP checksum before it is written to the receive/transmit buffer, but the read operation will take its toll. Checksums are a tax on the TCP/IP stack performance and it would be much better if it could just copy the contents of the receive/transmit buffer and not have to worry about also calculating the checksum. Copying operations can be made very fast, but the arithmetic operations that have to be performed on the contents are really something else: each 16 bit word of the buffer has to be read and processed one at a time.

And I guess with TCP/IP code from 1994 IPv6 support is low on the backlog...

In order to use IPv6 on the Amiga, you have to use the IPv6-enabled data structures of the TCP/IP stack, and the TCP/IP stack APIs (including the name resolution service) have to be IPv6-aware. The AmiTCP V4 API which Roadshow (as well as AmiTCP Genesis and Miami) implements is limited to IPv4 only. The only Amiga TCP/IP stack which supports IPv6 is Holger Kruse's Miami Deluxe, if I remember correctly. And Miami Deluxe has a completely separate API for IPv6 which is distinct from the standard AmiTCP V4 API. Because of this, the number of shell commands and applications which support IPv6 is extremely small.