[e2e] A very prominent example for the "bandwidth fallacy" and LFN in mobile networks.

[Detlef Bosau]

The following article deals with GPRS.

> @article{ meyer,
>     author ="Michael Meyer and Joachim Sachs and Markus Holzke",
>     title  ="{Performance Evaluation of A TCP Proxy in WCDMA Networks}",
>     journal ="IEEE Wireless Communications",
>     year = "2003",
>     month = "October"
> }
>


Let me quote only a short passage from "TCP in the context of WCDMA":

> Depending on the assigned data rate,
> WCDMA offers links with small to large band-
> width delay products. For simplicity, the working
> assumption of a TCP RTT of 500 ms is used for
> the following considerations. For 64 kb/s this
> would result in a bandwidth delay product of 4
> kbytes, but for 384 kb/s it would be 24 kbytes.
> The latter value is large enough to cause a link
> underutilization for three to six round-trips
> depending on the maximum segment size (MSS)
> and the initial window size of TCP used for a
> particular TCP connection.

I intentionally will not delve into the gory details of GPRS here, but
this nonsense is absolutely ludicrous.

What the authors actually claim is that in a TCP connection including a
GPRS link with 500 ms RTT, there is 24 kByte of data IN FLIGHT!

The whole discussion of "bandwidth delay products" (or to avoid the
abuse of "bandwidth" rate delay products) well makes sense in the
context of long lines where actually a huge number of data is in flight
along the line. Imagine a long fibre, which may well have a length of
some hundred kilometres and offer a data rate of, say, 2 MBit/s. 

This is not the case in GPRS.


The authors simply ignore the fact, that GPRS employs a *recovery
layer*, which is necessary to provide for acceptable SDU corruption
ratios at all.
Depending on the QoS profile in use (I wrote this in this list several
times) the simple transport latency for a packet to be delivered over
the air interface from the base station to the mobile may reach SEVERAL
MINUTES.

Now, there are quite a few parameters which are important here.
- The line coding scheme (IIRC QPSK in early GSM/GPRS versions, in more
recent flavers 64 QAM or 256 QAM)
- The channel coding scheme (four different ones, when I started to work
with mobile networks)
- The RLP in use: IP packets are not conveyed as one single piece here,
the loss ratio would be far to high, typical payloads for Radio Link
Protocols here are 20 to 24 byte. So there is some overhead depending on
the RLP in use.
- The scheduling scheme, GPRS allows up to 8 mobiles in one cell.


All these things can be modified by management layers etc. And of
course, the achievable throughput may be severely decreased, if,e.g.,
the channel coding scheme or the line coding scheme are chosen
inappropriately.

Nevertheless, the most important factor which dominates the achievable
throughput is the radio channel itself. When even BPSK for line coding
and the most robust channel coding, GPRS has to offer, don't succeed to
deliver a RLP block in one or two attempts but a block needs up to 200
or 400 sending attempts until it eventually is successfully received, we
can play "three man in a boat" with the tin of pine apples: We can
hammer the management square, we can hammer the management flat, we can
hammer the management to all forms known to geometry.

The throughput won't increase.

However, we would have an explanation for the 500 ms RTT.

Which alone debunk the "perpetuum mobile" nonsense in the quoted paper.

We all know the saying: "You cannot make a silk purse from a sows ear."


-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30   
70565 Stuttgart                            Tel.:   +49 711 5208031
                                           mobile: +49 172 6819937
                                           skype:     detlef.bosau
                                           ICQ:          566129673
detlef.bosau at web.de                     http://www.detlef-bosau.de