![]() Assuming the time needed to process a received packet is less than one RTT, the stop-and-wait mechanism will prevent data from arriving too fast. Stop-and-wait also provides a simple form of flow control to prevent data from arriving at the receiver faster than it can be handled. The transfer completes normally, but takes double the normal bandwidth. In the following diagram, the only packet retransmitted due to timeout is the second Data all the other duplications are due to the retransmit-on-duplicate strategy.Īll packets are sent twice from Data on. Let us imagine that an implementation uses this strategy, and that the initial ACK is delayed until after Data is retransmitted on timeout. See Disney’s Fantasia,, at around T = 5:35.Ī strange thing happens if one side implements retransmit-on-timeout but both sides implement retransmit-on-duplicate, as can happen if the implementer takes the naive view that retransmitting on duplicates is “safer” the moral here is that too much redundancy can be the Wrong Thing. When the basin is full, the apprentice chops the broom in half, only to find both halves carrying water. The Sorcerer’s Apprentice bug is named for the legend in which the apprentice casts a spell on a broom to carry water, one bucket at a time. If both sides implement retransmit-on-timeout with different timeout values, generally the protocol will still work. ![]() The other side must implement at least one of retransmit-on-duplicate or retransmit-on-timeout usually the former alone. Either side can also implement retransmit-on-duplicate this was done by the receiver in the second example above but not by the sender in the third example (the sender received a second ACK but did not retransmit Data).Īt least one side must implement retransmit-on-timeout otherwise a lost packet leads to deadlock as the sender and the receiver both wait forever. In principle, either side can implement retransmit-on-timeout if nothing is received. In this case we see that, after sending Data, receiving a delayed ACK (rather than the expected ACK) must be considered a normal event. Not every packet that times out is actually lost! We have assumed here that the receiver has implemented a retransmit-on-duplicate strategy, and so its response upon receipt of the duplicate Data is to retransmit ACK.Īs a final example, note that it is possible for ACK to have been delayed (or, similarly, for the first Data to have been delayed) longer than the timeout interval. ![]() The receiver has received a duplicate ACK. The right half of the diagram, by comparison, illustrates the case of a lost ACK. The receiver is not aware of the loss it sees Data as simply slow to arrive. The left half of the diagram below illustrates a lost Data packet, where the sender is the host sending Data and the Receiver is the host sending ACKs. The End-to-End principle, 12.1 The End-to-End Principle, suggests that trying to achieve a reliable transport layer by building reliability into a lower layer is a misguided approach that is, implementing reliability at the endpoints of a connection – as is described here – is in fact the correct mechanism. It turns out that the sliding-windows algorithm is also the key to managing congestion we return to this in 13 TCP Reno and Congestion Management. The strategy used to achieve this is known as sliding windows. ![]() ![]() In addition to reliability, we also want to keep as many packets in transit as the network can support. As a class, protocols where one side implements retransmit-on-timeout are known as ARQ protocols, for Automatic Repeat reQuest. This is achieved through a retransmit-on-timeout policy that is, if a packet is transmitted and there is no acknowledgment received during the timeout interval then the packet is resent. In this chapter we take a general look at how to build reliable data-transport layers on top of unreliable lower layers. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |