[e2e] Wireless Networks. An Example: GPRS.

[Jon Crowcroft]

SLAs are far more politics than technics...

but more importantly, GPRS has a lot of protocol cruft 
(though less than 3G and 4G - just look at fast dormancy and 
tail energy use in those nets, if you want a laugh)...

this protocol stuff (as Martin Heusse has indicated) masks the 
details of the wireless channel under layers of behaviours
so a latency SLA above the packet radio +service+ layer
has to include the expected 95centile of packet loss  (due to
noise/interference) and impact of ARQ in the radio link layer protocol,
below IP (and therefore hidden from TCP too)....

anyhow, standards organisations only ever agree to publish SLAs if they
are unbelievelable conservative:)

In missive <513DCBDB.30703 at web.de>, Detlef Bosau typed:

 >>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=20
 >>the SGSN to the mobile.
 >>
 >>
 >>
 >>GPRS Delay Classes
 >>
 >>
 >>
 >>
 >>
 >>
 >>
 >>
 >>
 >>
 >>
 >>
 >>Hopefully, this table appears on the list, otherwise I would to have to=20
 >>write it down in ASCII characters.
 >>
 >>First, we can model this transport latency using the terms=20
 >>"serialization delay" and "propagation delay". In GPRS the maximum cell=20
 >>radius is about 32 kilometers, IIRC, so the propagation latency is=20
 >>certainly less than 0,1 milliseconds. Hence we can simply neglect the=20
 >>the propagation latency in this case.
 >>
 >>So let's talk about the "serialization delay". For 1024 octets, this may=20
 >>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=20
 >>from the SGSN to the terminal) is stationary, so that we can derive some=20
 >>kind of RTO.
 >>
 >>BTW: Deriving an RTO from an observed RTT via Chebycheff/Cantelli/Edge=20
 >>is simply ridiculous here: The RTO is nothing but a, say, 0.95 quantile=20
 >>and would be 375 seconds here, which is far to long for any practical=20
 >>use. On the other hand, GPRS uses transport blocks / radio blocks for=20
 >>transmission and has a quite precise knowledge of the distance=20
 >>Antenna/Terminal (necessary for the GSM timing advance) and hence a much=20
 >>more realistic RTO for its own recovery layer.
 >>
 >>I strongly expect objections here because I didn't mention the=20
 >>appropriate reliability classes for the aforementioned delay classes.=20
 >>IIRC, the "QoS Profile" for delay class 3 ensures an SDU corruption=20
 >>probability less than 10^-9. So the recovery layer in that case is=20
 >>extremely strong. Particularly, any loss differentiation=20
 >>(corruption/congestion) is simply not necessary here. From TCP's point=20
 >>of view, corruption is negligible here.
 >>
 >>
 >>The second question is how we can explain the "serialization delay" and=20
 >>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=20
 >>Communications October 2003.
 >>
 >>Throughout this paper, the authors talk about a "latency bandwidth=20
 >>product" where "bandwidth" is the GPRS gross data rate 384 kBit/s. Even=20
 >>a WCDMA "bandwidth", i.e. 2 MBit/s is mentioned.
 >>
 >>So the reader is made to expect a "path capacity" 384 kbit/s * 375=20
 >>seconds =3D 144.000 kbit. (750 Mbit respectively.)
 >>
 >>And of course, this huge path capacity should be utilized by an=20
 >>appropriate initial TCP window.
 >>
 >>Now, neither the air interface in GPRS or UMTS has a path capacity=20
 >>comparable to a 5 1/4" floppy disk nor the "serialization" of a 1024=20
 >>octed SDU using a data rate 2 MBit/s lasts 375 seconds.
 >>
 >>So, the interpretation of the delay als "serialization time" is at=20
 >>least, say, strange, the so called "latency bandwidth" product in this=20
 >>case is simply an abuse of Little's formula.
 >>
 >>First of all, the "mean" value and the 0.95 quantiles in the table above=20
 >>indicate that the transport latency exhibits an extreme skew. So, the=20
 >>immediate question is, whether the expectations for service time, rate=20
 >>of arrival and jobs in the system exist at all and hence whether or not=20
 >>Little's law is applicable.
 >>
 >>Second, what are the jobs in the "system"? Packets sent via GPRS or UMTS=20
 >>are typically split up into a sequence of RLP blocks, so there are=20
 >>blocks for new transmissions, there are blocks for repeated=20
 >>transmissions, there are blocks for RLP control, hence the data to be=20
 >>transmitted (represented by the first transmission only) are only a part=20
 >>of the traffic in flight. And because GPRS offers only little adaptivity=20
 >>in its channel- and line-coding, but QoS profiles with an extremely low=20
 >>SDU corruption ratio, I strongly believe, that the payload interesting=20
 >>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=20
 >>GPRS. However, I think the major part is more or less queueing delay.
 >>
 >>And because the real air interface has hardly any "transient storage=20
 >>capacity" at all, I think, a sliding window approach for GPRS networks=20
 >>is completely inappropriate. We should use stop 'n wait here and that's i=
 >>t.
 >>
 >>Detlef
 >>
 >>
 >>
 >>
 >>

 cheers

   jon