When a packet sent by a previous TDN is indeed lost, how does TDTCP acknowledge and handle this situation? about tdtcp

[shuoshuc]

Hi,

For non-spurious loss, we rely on the regular triple dupack and tlp mechanism for recovery. Specifically, if a packet in the streak of a (same) TDN is lost, the triple dupack mechanism will correctly identify the event and retransmit accordingly. If the last packet of a TDN streak is lost, this qualifies as a tail loss, which is covered by the RACK-TLP timer (see RFC 8985). Sender and receiver procedures are standard as codified by the rfc.

Hope this helps!

[moningchen]

Thank you for your answer. If packet loss is confirmed, the triple dupack and tlp mechanism is used to recover. I can understand that. However, how do we know if a package is lost? Specifically, when the packet sent by the previous TDN has not reached the receiver, while the packet sent by the next TDN has reached the receiver, how to confirm whether the packet sent by the previous TDN arrived late or lost?

[shuoshuc]

IIUC you are describing a tail loss event (last few packets of a TDN are lost). In which case, we make no assumption but just rely on RACK-TLP. The timeout is set to a pessimistic value assuming the return path has longest delay (see sec 4.4 in the paper). In shallow-buffered networks, RACK-TLP's estimation is pretty accurate, so spurious retransmission is actually very rare, most scenarios are true losses.