TCP/IP Mound (SM)

TCP/IP Mound ^(SM)

04/14/01: For immediate release
Keywords: TCP/IP protocol stack mound

Electromagnetic Networks asks you if you are satisfied with your current TCP/IP implementation. Are you satisfied with your current TCP/IP implementation? Further, are you displeased with the gargantuan amount of code required to keep your TCP/IP stack upright, sometimes measuring in the tens of kilobytes? Does it bother you that the network subsystem must behave in an anal-retentive manner and carefully pile each packet on top of the previous? Do the balance issues involved in centering smaller packets in between larger ones to prevent stack toppling unbalance you? Finally, are you tired of only getting packets from the very tip-top of the stack?

Well, if your answer to any of these questions was yes, you need to seriously sit down and read TCP/IP Illustrated, and possibly seek psychiatric help. But if all of that fails, as it did here at Electromagnetic Networks, perhaps you need to take advantage of our latest breakthrough in networking software: the TCP/IP Mound ^(SM).

The TCP/IP Mound ^(SM) reduces resident networking code size by an unprecedented amount at a minimal protocol cost. No longer are packets time-consumingly ordered in a specific order in send or receive queues. By utilizing a revolutionary breakthrough in network "stack" technology, Electromagnetic Networks can successfully pioneered an implementation of TCP/IP that is almost totally RFC 791 compliant, and far more reliable than RFC 1149 based stacks. Best of all, it is far faster and simpler than traditional network stacks, and as best practices dictate, simpler code is better code.

The breakthrough hinges on treating the networking subsystem as a mound, not a stack. No longer must data be popped off of exclusively the top of the stack, but can be removed from the middle, the bottom, or even the far edges where the one bits so often slide. Finally, with industry-proven Monte Carlo techiques, this stack can be completely interoperable with other, less advanced stacks.¹

The obvious question that sprang to our minds at Electromagnetic Networks is "Why am I sitting on the cat?" But once one removes the housepet from the matter at hand, the next question was "What possible drawbacks could there be to such a fresh new implementation?" Other than previously noted,² there is only one minor difference between our implementation and older, less forward-thinking implementations: the lack of thoroughly, totally, completely "in-order" transport.

Surely this is a small price to pay for all that this protocol gives you: arbitrary access to incoming packets, simple "sieve" operations on packets to sort out the pesky one bits or remove arbitrary zero bits, easy bucket-sorting capabilities to distinguish packet sizes, and many others too numerous to even enumerate. This perceived shortcoming is easily rectified - since TCP promises reliable communication, and guarantees retransmission upon dropped packets, a trivial accumulator can be used to provide a union-find operation for the next packet in sequence, and any packets not following directly in sequence number can simply be discarded, encouraging the other side to retransmit and provide needed exercise for the transport medium.

It may have occurred to you that this elegant solution may only allow replacement of receive queues with a TCP/IP Mound ^(SM), but does not work effectively for send queues. However, further thought will show that this does not have to be the case. If send queues are implemented as "send mounds", as retransmission time t becomes large, the probability that any given packet has been sent to the far end of the socket becomes arbitrarily close to 100%. Therefore, all that is needed to effectively use such send mounds is a sufficiently patient stack on the other end. If you find that your other implementations are timing out too frequently, we suggest that you complain to your vendor, or perhaps switch to a TCP/IP Mound ^(SM) on the remote system.

Electromagnetic Networks subscribes to Open Disclosure and Open Software philosophies. Although the current state of the code is not at the point where it can be released to the general public³, all discussion in this document is protected by free speech laws and can be freely distributed as long as we are cited. We at Electromagnetic Networks welcome feedback, preferably written in the helpful memo field of otherwise nearly blank signed checks.

Note 1: Slight network degradation may result when using the TCP/IP Mound ^(SM) in a heterogeneous environment. No studies have established whether or not this degradation will occur in homogenous TCP/IP Mound ^(SM) environments.
Note 2: See Note 1.
Note 3: A serious code cleanup and sanitization is yet to be completed. Due to certain encryption and obscenity laws in force in the United States of America at this time, free unlimited access to the code is not yet possible.

(Electromagnetic Networks in no way intends the name TCP/IP Mound ^(SM) to have any connotation with dropped packets, nor with a certain tasty candy that people sometimes "feel like.")

Comments on this Document
Add a comment

TCP/IP Mound Cleanup
by meithkiller (meithkiller) on 06/04/2001 at 10:55 (#1)
You should also implement the TCP/IP Mound Cleanup application. You can call it the TCP/IP Shovel or The Scoop.
The Scoop can be set up as a retrieval mechanism for gathering the lost bits and dumping them back on top of the mound. ;o)

memory requirements
by KGB () on 09/07/2001 at 20:39 (#2)
Of course the size of the mound will be available ram in the interface. With gigabit ethernet I think you'll need a lot of memory so bits won't spill. I suggest you dump leakages to the bit bucket...

when...
by chemical reactors rule (sidewinder_forge@gmx.net) on 09/08/2001 at 07:15 (#3)
... can i get it?

bri.