[e2e] Wireless Networks. An Example: GPRS.
detlef.bosau at web.de
Mon Mar 11 05:19:39 PDT 2013
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
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.
70565 Stuttgart Tel.: +49 711 5208031
mobile: +49 172 6819937
detlef.bosau at web.de http://www.detlef-bosau.de
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 32960 bytes
Desc: not available
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20130311/19691f30/attachment-0001.png
More information about the end2end-interest