Scalable Retransmissions

When a receiver discovers there is an inconsistency between its data and that of another site, it cannot just send a message to resolve the inconsistency immediately - if it did so there is a high probability that its message would be synchronised with identical messages from other receivers causing a NACK implosion. Instead we require a mechanism to ensure that approximately one site sends the message. If such a message is an update, it should be multicast as this may update other sites with out of date information. In fact, if such a message is a retransmission request, it should also be multicast, as then the reception of the request can be used at other sites to suppress their retransmission requests.

Van Jacobson uses such a scheme in wb[#!van:95!#] where a retransmission request is delayed by a period of time dependent on the round-trip time between the receiver and the original source plus a random amount. This scheme requires all participants to calculate a delay (round trip time) matrix to all other sites, and this is done using timestamps in the session messages.

wb is more dependent on its retransmission mechanism than nte is, as wb has no natural redundancy, and thus it requires its retransmission scheme to be extremely timely. nte does not wish its retransmission scheme to be as timely as wb's scheme, as it expects most of its loss to be repaired by the next character to be typed. In fact, in many cases this results in very significantly fewer packet exchanges because in a large conference on the current Mbone, the probability of at least one receiver losing a particular packet can be very high. Thus what we require is a retransmission scheme that ensures that genuine inconsistencies are resolved in a bounded length of time, but that temporary inconsistencies due to loss which will be repaired anyway do not often trigger the retransmission scheme.

Wb's scheme can be simply tailored to do this effectively by adding a ``dead time'' to the retransmission timer to allow a window during which the next modification to the line could arrive. If we used wb's randomised time based scheme, then we would probably opt for not sending summary messages but instead adding ID/timestamp pairs to the session messages as described above. These would then tend to spread the retransmission requests more evenly.

In fact, wb's mechanism has not been described in detail at the time nte was designed and implemented, and we used a different sender driven retransmission request scheme.