[e2e] Dealing with Spurious Retransmits in TCP

[Injong Rhee]

I agree with Reiner. The main problem lies in unnecessary coupling of
recovery and congestion control in TCP. I view CC is an independent from
recovery. Whether it can transmit spurious retransmission or simply do
no-op, it should left to the application or other layer decision.
Therefore, CC must tell the current rate (or window size) that the data
(including retransmission) must be sent at and the recovery layer
decides on whether it should retransmit, forward-error correction or
other data packets. 

Injong Rhee
Computer Science Dept
North Carolina State Univ.
rhee at csc.ncsu.edu
http://www.csc.ncsu.edu/faculty/rhee

-----Original Message-----
From: end2end-interest-admin at postel.org
[mailto:end2end-interest-admin at postel.org] On Behalf Of Reiner Ludwig
Sent: Monday, March 10, 2003 4:53 AM
To: tsvwg at ietf.org
Cc: end2end-interest at postel.org
Subject: [e2e] Dealing with Spurious Retransmits in TCP

[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