[e2e] Dealing with Spurious Retransmits in TCP

[Ibrahim Matta]

Yes, this is the *well-known* problem of coupling
between error control and congestion control
in window-based schemes. Rate-based schemes
naturally decouple the two - see Keshav's textbook
for example.

ibrahim



Injong Rhee wrote:
> 
> 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

--
Ibrahim Matta       Dept of Comp Sci, 111 Cummington St, MCS-271
matta at cs.bu.edu     Assistant Prof, Boston Univ., Boston, MA 02215
Tel: (617)358-1062, Fax: (617)353-6457, URL: www.cs.bu.edu/fac/matta/