Subject: [Tsvwg] RE: [e2e] Dealing with Spurious Retransmits in TCP

From: "john smith" <[email-masked]>
Date: Tue, 11 Mar 2003 13:34:01 +0000

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" <[email-masked]>
>To: "'Reiner Ludwig'" <[email-masked]>, <[email-masked]>
>CC: <[email-masked]>
>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.
>[email-masked]
>http://www.csc.ncsu.edu/faculty/rhee
>
>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Reiner Ludwig
>Sent: Monday, March 10, 2003 4:53 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: [e2e] Dealing with Spurious Retransmits in TCP
>
>[I have cc:ed [email-masked], but please reply only to
>[email-masked] 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

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg