[PDF] TCP/IP Issues

The IP Service Model The underlying networks provide a possibly unreliable “datagram” sevice Unreliable: packets may be dropped, damaged, duplicated, reordered Packets are forwarded to the next hop to their eventual destination—or dropped if not deliverable Packets may be dropped because of network congestion Very little concern for the correctness of any packet Stateless forwarding—what happens with a packet does not affect what happens to the next packet Note: this is the service model—implementations can behave differently to optimize things if they wish TCP/IP Issues 10 / 42 … sequence number Note that at this point, the server has to create state for this half-opened connection The client’s reply has only the ACK bit set, plus n acknowledgment of the server’s initial sequence number This is called the three-way handshake, which takes 1.5 round trips The connection is not fully open until the server receives this last message TCP/IP Issues 22 / 42 … Error Handling Only in TCP Why doesn’t the IP layer drop damaged packets? TCP/IP Issues 25 / 42 Error Handling Only in TCP Why doesn’t the IP layer drop damaged packets? IP could check (and many link layers do check)—but that’s redundant TCP has to check anyway UDP might not want a check–think OFB encryption This is the end-to-end principle Worth noting: because most links are very reliable (and many have their own checksums), very, very few packets are dropped because of TCP checksum issues TCP/IP Issues 25 / 42