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

[Detlef Bosau]

Francesco Vacirca wrote:
> 

> 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


The question is: What is "few"?

In addition: Are these timeouts due to "real" delay spikes? Or due to 
normal delay variation?

 From what I´ve learned recently, we could use k=4 in RTO=E+k*V as it is 
proposed in a revised version of the congavoid paper. Perhaps, we could 
even use k=8. However, we can make RTO sufficiently large to cope with 
"normal fluctuations".

My basic question is: Are these timeouts due to the TCP implementations 
in use? Or due to unforseeable spikes? In case of the latter: How often 
does this happen? Is it an "issue", i.e. it happens three or four times 
a minute? Or is it neglectible, e.g. it happens two or three times a year?

> 
>> 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.  
> 

The more I think about our actual discussion, the more I dont expect 
spurious timeouts as a result only from ARQ that often. Perhaps, a great 
deal of ARQ caused latency variation can be covered by a sufficiently 
large choice of K.

I don´t know.

At this point, I think there is no alternative to real traces which 
reflect observed latencies in different scenarios. Anyhing else would 
result in speculation.

> 
> 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.


Personally I make a strong difference between 802.11 networks and mobile 
wireless networks like GPRS or UMTS.

 From what I have read in many manuals for WLAN and from what I have 
seen in practical experience, loss is no issue there. If your run those 
networks properly (and placing sender and receiver on two sides of a 
wall from reinforced concrete does surely not mean to run the network 
properly), you can reach corruption rates as seen in Ethernet.

In mobile wireless networks, the situation is different for two reasons.

1. The physical properties of a path are often beyound the user´s 
control. If a user stays outside, he hardly can influence the weather.
A user has limited influence on the traffic, think of multiplath shading 
  due to reflection at vehicles, etc.

2. Typically, mobile wireless networks are used for line switching, 
best effort packet switching, QoS packet switching in parallel.
So, in some situation a packet must be postponed becuase a time slot or 
a packet is reserved for traffic with higher priority.

I did not mention roaming here.

I´m using a mobile phone for about 10 years now. And sometimes I must 
have roamed among differenct cells while I was talking to somebody with 
my cell phone for sure.

Honestly: I did not notice that. And when I don´t notice roaming in a 
speech flow, it´s somewhat hard to make me believe that micromobility is 
really an issue  ;-) This is admittedly no strong scientific argument.



> 
> 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?

I´m not quite sure whether I got you correctly. What exactly do you mean 
by ARQ persistancy? Do you mean a "stop'n wail" scheme, i.e. you send 
one packet as long until it is successfuly delivered, than the next one?
I.e. you inhibit packet reordering?

 From what I´ve leardn from the RFCs, Mark Allman pointed me at, some 
degree of packet reordering should not really result in a problem.

> 
> 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.

Sounds af if theres not really something to worry about.


>> 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.
> 


And that´s why I said that real traces are helpful here. At least with 
respect to the different degree of mobility, different locations etc.

Detlef

-- 
Detlef Bosau
Galileistrasse 30
70565 Stuttgart
Mail: detlef.bosau at web.de
Web: http://www.detlef-bosau.de
Mobile: +49 172 681 9937