[e2e] Delays / service times / delivery times in wireless networks.
detlef.bosau at web.de
Fri Feb 23 07:14:16 PST 2007
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
> 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
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"?
More information about the end2end-interest