[e2e] Wireless Networks. An Example: GPRS.

[Detlef Bosau]

Because of the recent discussion on congestion control, let me please 
refer to the following table,
which is taken from
"European Telecommunications Standards Institute. Digital cellular
telecommunications system (phase 2+); General Packet Radio Service
(GPRS); Service description; Stage 1. ETSI Standard EN 301 113
V6.1.1, 1998."

and to my understanding describes the SDU delivery times via GPRS from 
the SGSN to the mobile.



GPRS Delay Classes












Hopefully, this table appears on the list, otherwise I would to have to 
write it down in ASCII characters.

First, we can model this transport latency using the terms 
"serialization delay" and "propagation delay". In GPRS the maximum cell 
radius is about 32 kilometers, IIRC, so the propagation latency is 
certainly less than 0,1 milliseconds. Hence we can simply neglect the 
the propagation latency in this case.

So let's talk about the "serialization delay". For 1024 octets, this may 
be up to 375 seconds, for 128 octets, it may be up to 250 seconds.
In the first example, the resulting throughput is about 22.8 bit/second.

The first question is, whether or not the RTT (the table above shows STT 
from the SGSN to the terminal) is stationary, so that we can derive some 
kind of RTO.

BTW: Deriving an RTO from an observed RTT via Chebycheff/Cantelli/Edge 
is simply ridiculous here: The RTO is nothing but a, say, 0.95 quantile 
and would be 375 seconds here, which is far to long for any practical 
use. On the other hand, GPRS uses transport blocks / radio blocks for 
transmission and has a quite precise knowledge of the distance 
Antenna/Terminal (necessary for the GSM timing advance) and hence a much 
more realistic RTO for its own recovery layer.

I strongly expect objections here because I didn't mention the 
appropriate reliability classes for the aforementioned delay classes. 
IIRC, the "QoS Profile" for delay class 3 ensures an SDU corruption 
probability less than 10^-9. So the recovery layer in that case is 
extremely strong. Particularly, any loss differentiation 
(corruption/congestion) is simply not necessary here. From TCP's point 
of view, corruption is negligible here.


The second question is how we can explain the "serialization delay" and 
which consequences must be drawn from a "serialization delay" 375 seconds.

I occasionally refered to "PERFORMANCE EVALUATION OF A
TCP PROXY IN WCDMA NETWORKS" by Meyer, Holtzke, Sachs. IEEE Wireless 
Communications October 2003.

Throughout this paper, the authors talk about a "latency bandwidth 
product" where "bandwidth" is the GPRS gross data rate 384 kBit/s. Even 
a WCDMA "bandwidth", i.e. 2 MBit/s is mentioned.

So the reader is made to expect a "path capacity" 384 kbit/s * 375 
seconds = 144.000 kbit. (750 Mbit respectively.)

And of course, this huge path capacity should be utilized by an 
appropriate initial TCP window.

Now, neither the air interface in GPRS or UMTS has a path capacity 
comparable to a 5 1/4" floppy disk nor the "serialization" of a 1024 
octed SDU using a data rate 2 MBit/s lasts 375 seconds.

So, the interpretation of the delay als "serialization time" is at 
least, say, strange, the so called "latency bandwidth" product in this 
case is simply an abuse of Little's formula.

First of all, the "mean" value and the 0.95 quantiles in the table above 
indicate that the transport latency exhibits an extreme skew. So, the 
immediate question is, whether the expectations for service time, rate 
of arrival and jobs in the system exist at all and hence whether or not 
Little's law is applicable.

Second, what are the jobs in the "system"? Packets sent via GPRS or UMTS 
are typically split up into a sequence of RLP blocks, so there are 
blocks for new transmissions, there are blocks for repeated 
transmissions, there are blocks for RLP control, hence the data to be 
transmitted (represented by the first transmission only) are only a part 
of the traffic in flight. And because GPRS offers only little adaptivity 
in its channel- and line-coding, but QoS profiles with an extremely low 
SDU corruption ratio, I strongly believe, that the payload interesting 
for higher layers is only a minor part of the traffic in flight.

I did not yet get any sound explanation for the high transport times in 
GPRS. However, I think the major part is more or less queueing delay.

And because the real air interface has hardly any "transient storage 
capacity" at all, I think, a sliding window approach for GPRS networks 
is completely inappropriate. We should use stop 'n wait here and that's it.

Detlef








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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130311/19691f30/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 32960 bytes
Desc: not available
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20130311/19691f30/attachment-0001.png