Subject: Re: large RTT variation caused by bandwidth oscillation

From: Mark Allman <[email-masked]>
Date: Mon, 10 Dec 2001 22:58:01 -0500

> The period of SCH+FCH bandwidth needs to be fairly long (several
> seconds according to the authors) to have RTO converge the current
> RTT.  Then you shift down to narrowband and get a spurious RTO
> since your store-and-forward delay has increased.  But at this
> point your window can afford to be smaller since your BDP is
> smaller.  It takes less time to open a smaller window in CA.  So,
> perhaps this isn't a problem after all.

As have been outlined there are two problems with spurious RTOs:

(1) The cwnd is reduced.  Here I agree with Aaron.  As it so happens
    the path has changed and so TCP should again try to figure out
    what the capacity of the current network path is.  Why should
    TCP be allowed to continue sending at the previous rate into an
    unknown network?

(2) You end up using your narrow bandwidth for spurious
    retransmits.  This is clearly a problem.  If you can detect this
    (using DSACK or eifel or whatever) you can hopefully correct
    your RTO (i.e., make it more conservative) so that it does not
    happen again.  But, really what else can you do?  Unless you
    have some sort of explicit information from the network that
    says "wait a while longer before retransmitting", what else is
    there to do?

allman

---

From: "Andrei Gurtov" <[email-masked]>
Date: Thu, 13 Dec 2001 19:02:32 +0200

>     TCP be allowed to continue sending at the previous rate into an

Well, if the delay spike occured due to a handover in 3g network having 50
KB of BDP, performing the slow start from one segment is really painful.
Perhaps the compromise of halfing cwnd and setting ssthresh to previous
value of cwnd to cause smooth rump up is preferrable. Even with this
approach, if the delay spike occured early in slow start (with small flight
size) it will put the connection in congestion avoidance preventing from
utilizing the link bandwidth.

>     says "wait a while longer before retransmitting", what else is

At least, it should be ensured that the penalty does not go beyond go-back-N
retransmissions. That includes preventing spurious fast retransmit after
go-back-N
and retransmits on partial ACKs by Newreno. Also, a second spurious RTO
during DUPACK series should be prevented with help of timestamps and
restarting the retransmit timer.

Andrei