[e2e] Dealing with Spurious Retransmits in TCP

[Reiner Ludwig]

[I have cc:ed end2end-interest at postel.org, but please reply only to 
tsvwg at ietf.org to avoid double postings.]

What about the following rule for those TCPs that are enhanced to detect 
spurious retransmits?

     Those TCPs MUST reduce their cwnd by MSS (alternatively by the amount
     of spuriously retransmitted data) when a spurious retransmit has been
     detected.

The logic would be to say that since the TCP sender has used more than its 
fair share of bandwidth in the past (due to the spurious retransmit), it 
has to pay back for that once the spurious retransmit has been detected.

With that rule, the policies for adapting RTO and DUPTHRESH would become 
less crucial.

Moreover, a TCP sender for interactive applications (assuming that this 
implies that response time is more important than throughput) may then have 
the freedom to use a non-standard retransmission timer (more optimistic; 
not to say more aggressive), and Early Retransmit without concerns.

Taking this a step further, one could argue that as long as the TCP sender 
uses no more than its fair share of bandwidth, it is free to send what it 
wants. For example, everytime an acceptable ACK arrives, and the TCP sender 
does not have new data available, it may retransmit from the queue of 
unacked data.
RTP/UDP-based streams are also allowed to add redundancy in the form of FEC 
and retransmissions when the source rate is lower than the available 
bandwidth, or to trade some of their throughput and responsiveness for an 
increased reliability.
So, couldn't TCP also trade unused throughput for an increased 
responsiveness by adding redundancy in the form of sending potentially 
spurious retransmits?

///Reiner