[e2e] Delivery times in mobile networs? Re: Are there any persons interested in TCP over mobile wireless networks in Germany?

Detlef Bosau detlef.bosau at web.de
Thu Dec 13 07:21:48 PST 2012

Am 13.12.2012 15:57, schrieb Jim Gettys:
> On Thu, Dec 13, 2012 at 6:15 AM, Eggert, Lars <lars at netapp.com 
> <mailto:lars at netapp.com>> wrote:
>     On Dec 12, 2012, at 16:38, Detlef Bosau <detlef.bosau at web.de
>     <mailto:detlef.bosau at web.de>> wrote:
>     > My central question at the moment is: Do we have stationary
>     packet delivery times on mobile wireless links?
> Not sure what you mean by "stationary".
> This crossed my radar screen:
> http://conferences.sigcomm.org/sigcomm/2012/paper/cellnet/p1.pdf

Thanks for the hint. This is not exactly what I had in mind, however it 
is extremely closely related. I.e. at a very first glance, non 
stationary delivery times can result in a buffer bloat phenomenon.

To bring it to a simple point (Lachlan, please don't hurt me..... ;-)): 
The typically "serialization delay" which is typically used in network 
simulators is simply wrong for mobile networks. It is SIMPLY WRONG to 
use "constant rates" for mobile networks,

- first because in mobile networks net data rates may change (sometimes 
several times within the transport of one single IP packet), for 
adaptation reasons,
- second because mobile networks often employ opportunistic scheduling 
algorithms which may cause a channel getting no service for some period 
of time,
- third because mobile networks typically employ some kind of recovery 
layer with automatic retransmission.

So the simple "serialization and delivery" of a packet of, say, 1024 
bytes length in GPRS may last from 7 seconds to 375 seconds according to 
the relevant ETSI standards. There may be other delays than the 
mentioned ones and the issue is perhaps much more complex than I said, 
however one must not, as in wired networks, take a net data rate of, 
e.g., 10 MBit/s and 1024 byte and expect a "serialization delay" and 
think the "serialization delay" were 891,2 microseconds.

Actually, even the values taken from the standard are 0,95 quantiles. So 
the "serialization" delay may last much longer, it is even possible that 
the packet is not delivered at all and hence stays in the queue forever.

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/20121213/d9e819b6/attachment.html

More information about the end2end-interest mailing list