[e2e] Spurious Timeouts in mobile wireless networks, was: Re: Retransmission Timouts revisited
detlef.bosau at web.de
Thu Sep 1 10:07:25 PDT 2005
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
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
> 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
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.
Mail: detlef.bosau at web.de
Mobile: +49 172 681 9937
More information about the end2end-interest