> > 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?
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.
> (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?
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
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:29 EST