data block X+1 Computer D receives the second copy of block X, and sends another acknowledgement for X back to S Computer D receives block X+1, and sends an acknowledgement for X+1 back to S Computer S receives the second acknowledgement for X, and sends a second copy of data block X+1 Computer S receives the acknowledgement for X+1, and sends data block X+2 Computer D receives the second copy of block X+1, and sends another acknowledgement for X+1 back to S Computer D receives block X+2, and sends an acknowledgement for X+2 back to S It will be seen that at this point the situation is now stable, and repeats; every packet from then on is duplicated (that is, two identical copies are sent across the internetwork). Even worse, the increased number of packets being sent around the internetwork was likely to cause congestion, which was likely to cause a packet to be delayed past the timeout yet again, which would then cause yet another duplicate packet to be generated by a timeout, and from then on a third copy of each packet would be sent. Needless to say, at that point, the situation would usually snowball, and further copies would be generated — hence the name given to this pattern of behaviour. For a small file, the transfer would complete, and the duplicate packets would eventually drain from the internetwork. If the file were large, however, congestive collapse would result, and only when the transfer failed would the mass of packets drain from the internetwork. Solution The fix to SAS involved modifying the TFTP specification to break the loop. Only the first instance of a received acknowledgment should cause the next data block to be sent; further copies of the acknowledgment for a particular data block would be ignored, thus breaking the retransmission loop. In the new version of the protocol, a block would only be retransmitted on timeout. This change also makes it possible to simplify the implementation of the receiving end (often, a bootstrap program written in a low-level language) by omitting the retransmission timer, as any lost packet would cause retransmission of the last packet sent by the sender. However, keeping the timer has its benefits, such as dealing with lost ACKs more efficiently. References Network protocols Internet architecture Software bugs