[e2e] Delays / service times / delivery times in wireless networks.

[Detlef Bosau]

Srinivasan Seshan wrote:
> Actually, how smart is not too hard to estimate - assuming that we are 
> really just doing this for TCP.
>
> As far as packet loss rates are concerned, the target probably 
> shouldn't be something fixed like 10^-3. It really depends on the link 
> speed. What you want to probably do is ensure that the packet 
> corruption rate is an order of magnitude less than the drop rate due 
> to congestion.

O.k. So, that would be an API problem / implementation problem: The 
congestion drop rate may be flow dependent.  Hence, the question is 
whether the link layer should act flow dependent here or whether "one 
size fits all". Particularly for GPRS the user is given the choice 
between two packet corruption rates IIRC: 10^-3 and 10^-9.  And even 
that must be broken down in the parameters for lower layers like
- coding scheme
- maximum acceptable number of retransmissions in ARQ
- etc.

> You can get the congestion drop rate by estimating the average RTT for 
> flows and the raw speed of the link. Apply some TCP modeling magic and 
> you should be able to pull out a loss rate. Note that I assumed a 
> single flow here, which is the worst case. Multiple flows will raise 
> the congestion loss rate. So, if you can assume that you have more 
> flows, you can accommodate higher corruption loss rates.
>

O.k. However, my intention was somewhat different. I´m still with the 
myth / truth (perhaps, we should combine the words ;-)) that TCP 
experiences fundamental problems over wireless links.

Just some hours ago I got a paper "Interaction between UMTS MAC 
Scheduling and TCP Flow Control Mechanisms" by Malkowski and Heier. One 
claim in this work is that the TCP flow control mechanism was to slow 
for a highly dynamic link.
Hm. So, I learned a wireless link may change its rate perhaps a dozen 
time during one IP packet transmission or even more.
So, what´s the problem? I don´t mind the link change its rate a million 
of times during one IP packet transmission, as long as the transmission 
time for the whole packet shows only little variation about some average 
value or some slow drift into the one or the other direction.

Of course, pure observation of IP packet round trip times is much too 
coarse to estimate channel properties beginning at the 15 position after 
the decimal point. However, as long as this observation suffices to 
provide reasonable TCP throughput, I have no problem with that.

So, from that point of view, we should debunk the religion "TCP does not 
work in mobile networks".

There are several other myths from the same religion.

Spurious timeouts is one myth - already debunked by Francesco Vacirca, 
Thomas Ziegler and Eduard Hasenleitner in 2005, "TCP Spurious Timeout 
estimation in an operational GPRS/UMTS network".  It is said: "seek and 
you will find". So the authors sought - and did not find... ;-)

Another myth could be ACK compression.

Is it myth? Or truth?

I don´t know.

So, basically I´m interested in IP packet service times in mobile 
wireless networks as they are perceived by the upper layers.
If there is anything what should be hidden from upper layers, one could 
talk about how this can be achieved.

However, if there is no need to hide anything from upper layers - we 
could even dismiss this poor dead horse and dismount.

What makes me mad is: There is a huge amount of papers - even those few 
ones I made hard copies from don´t fit into my appartement any longer - 
which claim there would be terrible problems with TCP over mobile networks.

And I´m absolutely not convinced that even one of these claims will hold 
in reality.

Perhaps, it´s my fault that I don´t see it, but it does not matter which 
problem I have a closer look at - each one I looked at during the last 
years broke into pieces.

It is however always much more difficult to prove the absence of a 
problem than it´s existence. And an author would hardly gain anything 
from it. If there is a problem, one can present a solution. If there is 
no problem - there is no need for a solution. And who would ever submit 
a paper: "We did not find a problem, so we don´t present a solution"?

Detlef