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

[Detlef Bosau]

In a sense, Ham is nothing else than "WiFi in big" :-) So, the problems
should be pretty much the same.

Perhaps, Ham misses the /CA and the line coding is  certainly more
simple than in WiFi, but the basics should be very similar.

Am 01.05.2015 um 20:40 schrieb David P. Reed:
> Detlef's comments make huge sense to me. I'm a Ham licensee and also
> quite aware of physics and networks. The nonsense in the peer review
> ed literature is shameful for the most part.
>
> On May 1, 2015, Detlef Bosau <detlef.bosau at web.de> wrote:
>
>     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."
>
>
> -- Sent with *K-@ Mail
> <https://play.google.com/store/apps/details?id=com.onegravity.k10.pro2>*
> - the evolution of emailing. 


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