[e2e] Spurious Timeouts in mobile wireless networks, was: Re: Retransmission Timouts revisited

[Francesco Vacirca]

Wesley Eddy wrote:
> On Thu, Sep 01, 2005 at 03:58:06PM +0200, Francesco Vacirca wrote:
> 
>>Spurious timeouts are a second (marginal) problem that in my opinion 
>>(and in my research) are not frequent events in a well engineered 
>>GPRS/UMTS network.
>>

> 
> Just curious ... Does this definition of "well-designed" include those
> networks run by major service providers?  

Well-designed is the wrong definition... I can just say that in the 
GPRS/UMTS network I analyzed spurious timeouts were a quite rare events 
with respect to "normal" timeouts and fast retransmit events.

I've witnessed a few timeouts
> due not to loss in the data path, but delay of either data or acks (TCP
> Timestamp or DSACK options make it clear that loss is not the problem),
> over one provider's North American CDMA 2000 network.  I presume that
> those delay spikes were contributed to by exactly the ARQ persistence
> you advocate, among other factors.  

Loss is not the problem IF (and only if) you do not have many losses... 
and possibly you do not have losses on the wireless channel but just due 
to congestion.

Of course ARQ persistancy can lead to spurious timeout... but I believe 
that it is better a spurious timeout that a "normal" timeout with packet 
losses
Do you believe that if you are not persistant in retransmission the next 
packet can arrive without timeout expiration?

In my (subjective) real world
> experience, data loss on this particular network is pretty rare, and
> timeouts are common enough that you see 3 or 4 of them doing normal
> things like web-surfing, fetchmail, and ssh over the course of an hour.
> I use such a link frequently and have several traces and other
> measurements (circa Spring 2004) that support this.

This is different from my experience ;-)
maybe this is due to the fact that different 3G networks have different 
terminal population (mobile terminal and data cards) with different TCP 
implementations.


Francesco

> 
> -Wes
>