32

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.

1
46

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.

10
  • 2
    Back in the day, DEC ruled! You weren't a first-class citizen on the Arpanet if you didn't have a PDP-10. Sep 26 at 13:41
  • 1
    True, but those PDP-10s weren't running DECnet :-( Sep 26 at 14:10
  • 13
    576 octets also happens to be 128 words of 36 bits each. Sep 26 at 19:05
  • 1
    I will accept this answer after a respectable delay. My ongoing research had led to the discovery that XNS had a similar command to copy a block of 512 bytes from a remotely mounted disk, and that the XNS datagram size was was probably set by the need to carry the response message to this command. Now it is a matter of dates and timing working out who copied whom.
    – user22965
    Sep 26 at 21:44
  • 5
    There wasn't necessarily actual copying - the same problem can lead to the same answer. Sep 26 at 22:06
14

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.

8
  • 6
    RFC 791 supports 512+64: "The number 576 is selected to allow a reasonable sized data block to be transmitted in addition to the required header information. For example, this size allows a data block of 512 octets plus 64 header octets to fit in a datagram.
    – richardb
    Sep 26 at 21:37
  • @richardb ??? Not sure what you want to tell.
    – Raffzahn
    Sep 26 at 22:10
  • 1
    This a valid answer and would be applicable to why disk drives store data on disk in blocks of 512 bytes. However I think another-dave's answer addresses my question more directly. The disk drives that were in use at the time. by the people who were developing networking protocols, happened to store data in blocks of 512 bytes.
    – user22965
    Sep 26 at 22:45
  • 3
    @Raffzahn, many machines used 512 byte pages (makes sense for that to be disk sector size too).
    – vonbrand
    Sep 27 at 1:56
  • 2
    @Raffzahn Only that the standard explictly supports the 512 byte data and 64 byte header.
    – richardb
    Sep 27 at 7:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.