<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-15">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Because of the recent discussion on congestion control, let me
please refer to the following table,<br>
which is taken from <br>
"European Telecommunications Standards Institute. Digital cellular<br>
telecommunications system (phase 2+); General Packet Radio Service<br>
(GPRS); Service description; Stage 1. ETSI Standard EN 301 113<br>
V6.1.1, 1998."<br>
<br>
and to my understanding describes the SDU delivery times via GPRS
from the SGSN to the mobile. <br>
<br>
<br>
<br>
<pre class="moz-signature" cols="72"><img alt="GPRS Delay Classes" src="cid:part1.06070700.01040902@web.de" align="right" height="205" width="471"></pre>
<br>
<br>
<br>
<pre class="moz-signature" cols="72">
</pre>
Hopefully, this table appears on the list, otherwise I would to have
to write it down in ASCII characters. <br>
<br>
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.<br>
<br>
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.<br>
In the first example, the resulting throughput is about 22.8
bit/second.<br>
<br>
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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
<br>
The second question is how we can explain the "serialization delay"
and which consequences must be drawn from a "serialization delay"
375 seconds.<br>
<br>
I occasionally refered to "PERFORMANCE EVALUATION OF A<br>
TCP PROXY IN WCDMA NETWORKS" by Meyer, Holtzke, Sachs. IEEE Wireless
Communications October 2003.<br>
<br>
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.<br>
<br>
So the reader is made to expect a "path capacity" 384 kbit/s * 375
seconds = 144.000 kbit. (750 Mbit respectively.)<br>
<br>
And of course, this huge path capacity should be utilized by an
appropriate initial TCP window.<br>
<br>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
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. <br>
<br>
Detlef <br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<pre class="moz-signature" cols="72">
--
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30
70565 Stuttgart Tel.: +49 711 5208031
mobile: +49 172 6819937
skype: detlef.bosau
ICQ: 566129673
<a class="moz-txt-link-abbreviated" href="mailto:detlef.bosau@web.de">detlef.bosau@web.de</a> <a class="moz-txt-link-freetext" href="http://www.detlef-bosau.de">http://www.detlef-bosau.de</a>
</pre>
</body>
</html>