[e2e] Dealing with Spurious Retransmits in TCP

[john smith]

i think this would have more to do with RWIN than MSS......

eitherways, why not cap RWIN as was previously suggested once here?







>From: "Injong Rhee" <rhee at eos.ncsu.edu>
>To: "'Reiner Ludwig'" <Reiner.Ludwig at eed.ericsson.se>, <tsvwg at ietf.org>
>CC: <end2end-interest at postel.org>
>Subject: RE: [e2e] Dealing with Spurious Retransmits in TCP
>Date: Mon, 10 Mar 2003 11:40:56 -0500
>
>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
>
>


_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963