TCP/IP Design
Reaction to {“A Protocol for Packet Network Intercommunication” by Vinton G. Cerf and Robert E. Khan}
The paper discusses the design considerations of the TCP/IP protocol suite widely used nowadays for internetworking.
Addressing/Routing
It used to be that different networks had different addressing schemes, which prior to internetworking, was okay since it is internal to each network. Internetworking, however, would require that all networks would be able to understand each other, so a common addressing scheme in TCP/IP was pushed for implementation — having all addressing schemes implemented on devices is unfavorable because these are unbounded.
The hosts are responsible for attaching the source and destination addresses, while routing is done by the network switches and gateways/routers. Much like our (snail) mailing services, the correspondents are responsible for their letters/packages, and indicating who sent it (return address) and to whom it is for (destination). The mailing service is only concerned with the delivery and does not (should not!) open or modify the letters/packages; it just forwards the letters/packages to the appropriate office until the final local post office can deliver it to the supposed recipient.
The packets also contain other information such as the byte count, sequence number and flags. Going back to our letter/package analogy, these can be likened to miscellaneous information such as the package dimensions and weight, as well as flags like “urgent” or “priority”.
Fragmentation and Reassembly
The acceptable packet sizes may vary for each network, so the gateway may split the packets into smaller fragments to let it through the next network. Reassembly is the done at the hosts, because if implemented at the gateways could potentially lead to buffering problems and deadlocks since all fragments of a packet will have to be collected in the gateways for reassembly. What happens if a fragment goes missing, and what if the resulting reassembled packets are too large to fit the router’s buffer? Aside from these problems, reassembly at the routers cause delay due to processing and is a wasted effort, since packets will have to be re-fragmented at the next router anyway.
The maximum packet size is not specified (1) to preserve the individual network’s internal parameters; (2) to make provisions for future developments which might support larger packet sizes, and (3) to allow expansion of packets when new information is attached or incorporated during transit.
Reliability/Sequenced Delivery
While multiplexed packets may be addressed to the same destination, the destination TCP should be able to identify which packets are for the specific processes. It does this by incorporating a process header to indicate the source and destination ports of the communicating processes. Each segment is encapsulated in a packet with its own checksum and byte count, and a sequence number unique to the communicating processes. These information, together with the flags in the packet, helps the destination TCP in determining the sequence of the fragments to reassemble the split message.
As the previous sentence suggests, TCP/IP puts the responsibility of ensuring ordered delivery and reassembly on the hosts. The network is only used for delivery, and even then, delivery is only best-effort and not 100% guaranteed. It is up to the hosts to verify the correct arrival of the messages and to request a resend should there be problems encountered. Acknowledgement and timeout mechanisms are applied to ensure successful delivery.
Security
Authentication is the responsibility of the host processes. The network lacks the capacity to intelligently verify the legitimacy or authenticity of the messages, since it does not have sufficient knowledge on the nature of the communication between the host processes. It is a different matter, however, when the encryption of entire network is desired to protect itself from misbehaving users.
Real-time Guarantees
The Internet is “best-effort” and does not assure 100% reliability. Application requirements for services vary: some applications, such as speech, require low latency and can tolerate packet loss, whereas others have can tolerate delays as long as the packets are delivered in-order.
Filed under: Computer Networks, Internet | Leave a Comment
No Responses Yet to “TCP/IP Design”