Network Packet - Terminology

Terminology

In the seven-layer OSI model of computer networking, 'packet' strictly refers to a data unit at layer 3, the Network Layer. The correct term for a data unit at the Data Link Layer—Layer 2 of the seven-layer OSI model—is a frame, and at Layer 4, the Transport Layer, the correct term is a segment or datagram. Hence, e.g., a TCP segment is carried in one or more IP Layer packets, which are each carried in one or more Ethernet frames—though the mapping of TCP, IP, and Ethernet, to the layers of the OSI model is not exact.

In general, the term packet applies to any message formatted as a packet, while the term datagram is reserved for packets of an "unreliable" service. A "reliable" service is one that notifies the user if delivery fails, while an "unreliable" one does not notify the user if delivery fails. For example, IP provides an unreliable service. Together, TCP and IP provide a reliable service, whereas UDP and IP provide an unreliable one. All these protocols use packets, but UDP packets are generally called datagrams.

When the ARPANET pioneered packet switching, it provided a reliable packet delivery procedure to its connected hosts via its 1822 interface. A host computer simply arranged the data in the correct packet format, inserted the address of the destination host computer, and sent the message across the interface to its connected Interface Message Processor. Once the message was delivered to the destination host, an acknowledgement was delivered to the sending host. If the network could not deliver the message, it would send an error message back to the sending host.

Meanwhile, the developers of CYCLADES and of ALOHAnet demonstrated that it was possible to build an effective computer network without providing reliable packet transmission. This lesson was later embraced by the designers of Ethernet.

If a network does not guarantee packet delivery, then it becomes the host's responsibility to provide reliability by detecting and retransmitting lost packets. Subsequent experience on the ARPANET indicated that the network itself could not reliably detect all packet delivery failures, and this pushed responsibility for error detection onto the sending host in any case. This led to the development of the end-to-end principle, which is one of the Internet's fundamental design assumptions.