Which computer system defined the IPv4 576 byte datagram limit?

Question

The IPv4 specification requires that IPv4 devices must be able to reassemble a datagram with a length of a minimum of 576 bytes.

Looking back into the creation of the Internet...

RFC 791 in defining the IP protocol states:

Every internet destination must be able to receive a datagram of 576 octets either in one piece or in fragments to be reassembled.

And by RFC879 it has become:

HOSTS MUST NOT SEND DATAGRAMS LARGER THAN 576 OCTETS UNLESS THEY HAVE SPECIFIC KNOWLEDGE THAT THE DESTINATION HOST IS PREPARED TO ACCEPT LARGER DATAGRAMS.

     This is a long established rule.

At what point prior to the Internet being created did this become an established rule? Was this 576 byte limit set to meet the capabilities of an already existing system? For example, hardware such as a computer or a modem, or a transport layer protocol such as a dial-up protocol?

On further research, Xerox Network Systems (XNS) also specifies a value of 576 bytes. However as a maximum packet length. So while it is unusual that these numbers are identical I would rule out the thought that the intention was to tunnel XNS over IP as there would be no capacity to wrap the XNS packet.

Answer 1

576 bytes was the standard buffer size in DECnet Phase IV use inside DEC.

Why 576? Because a FILES-11 disk block was 512 bytes, you needed a few more bytes for protocol overhead, and the allocation granularity on a PDP-11 memory management unit was 64 bytes.

So, a 576-byte buffer allowed the transfer of whole disk blocks without the need to split and recombine the data into session protocol data units.

This in turn allowed the possibility of DMA from disk into the appropriate 'hole' in a file server's network buffer.

In short, it's all about efficiency.

Other networking protocols probably did not 'copy' DECnet, but I suppose that similar reasoning applies.

Answer 2

Which computer system defined the IPv4 576 byte datagram limit

The question seems to be made under the impression that this is a maximum limit defined by some machine that needed to take part. But it is not.

It is a minimum requirement. Any hardware/software to participate needs to be able to handle at least a packet of this size. This is done to establish a useful minimum packet size that can be transferred without prior negotiation over all stations involved.

Further it's important to keep in mind that IP is designed as a routable communication protocol. Messages aren't sent over a single end to end communication line, but packetized and routed through a network with an unknown, maybe large, number of components between sender and receiver of a message. Each line between each pair handles packets independently. Each component (router, switch, node, etc., vulgo hops) will have to store incoming messages from one line and store it until it can be sent out over the next one.

Since all these lines are multiplexed, a possibly high number of messages may need to be stored before forwarded again. Thus memory management in each network component is of utmost priority, as it defines capacity of the network as a whole.

Last but not least, IP is defined as a vendor/hardware independent protocol. Thus the number itself can't be defined by some hardware, but a balancing of values that makes sense. When looking closely, then 576 decimal is in binary a number with only 2 bits set: 2⁹ and 2⁵ or 512 + 64. Doesn't that look quite like a useful data block and some generic header block?

When coming up with a data size for transmission blocks one has to balance various requirements:

1. Max. Payload should be reasonable large to keep fragmentation low
2. Header size should be large enough to allow expansion
3. Both (*1) need to allow variable size
4. Dedicated buffer space (in adaptors/small nodes) is small
5. Memory management at large nodes should be fast
6. Memory management at large nodes should be not wasteful.

While for #1 disk blocks are a good indication and 512 Bytes a middle of the road approach (*1), the real antagonists are

• variable payload size vs.
• max payload size vs.
• header size

in terms of memory management in systems that manage multiple blocks at a time. Variable block size is a must to increase line utilization with short blocks. This means neither a linked list nor a fixed size list would be great, as the first will run fast into fragmentation, while the second is extremely wasteful - keep in mind that systems back then did not have many megabytes of memory to waste.

In the end, the only solution is memory management with fixed size blocks, small enough to keep fragmentation low but big enough to keep numbers of blocks low. A size that nicely fits the maximum block while not wasting much on smaller ones.

Which is exactly what these two sizes, 512+64 give: Using 64 bytes as allocation size:

• The maximum payload will fit into 8 of these blocks,
• The maximum header will fit into 1 of them.
• Fragmentation is kept in check
• Waste is kept in check

A memory management handling messages as single block will have memory block sizes of 1..9 blocks, creating 9 types, giving acceptable fragmentation with good chance of low defragmentation need. At the same time waste is limited to a maximum 63 bytes per message.

A memory management handling them as two lists will have one less fragmentation size, resulting in even better utilization (*3) but a trade off of up to 2x63 bytes waste (*4).

Now since there are only 9 different message sizes (in terms of 64-byte chunks), a memory management could use 9 (8) lists, one for each of these sizes, resulting in a lightning-fast memory management.

---

Long story short, it's all about a sensible minimum message length allowing useful transmission while keeping memory management in check.

---

*1 - Well, or at least payload

*2 - Common sizes at that time for disk sectors were 128, 256, 512, 1024 and 2048 bytes.

*3 - Well, a binary tree block size of 64,128,255 and 512 would reduce that even more.

*4 - A bit more complex as a header is certainly larger than 1 byte, but still larger waste.