[e2e] Delays / service times / delivery times in wireless networks.

[David P. Reed]

The delays come from buffering and retrying for long times, on the basic 
theory that the underlying network is trying to be "smart" and guarantee 
delivery in the face of congestion or errors.   A decade ago this same 
issue came up running TCP over Frame Relay networks that were willing to 
buffer a minute or more's worth of traffic when congested if asked to do 
"reliable delivery".

Who could say no to such a wonderful feature in the network?   *Reliable 
Delivery*, wow, I want to build that in at the lowest layer, under IP 
(putting QoS in the lowest network layers is always good, as those who 
think the end-to-end argument is a religion keep saying).   Of course 
the real meaning of that is "reliable delivery no matter how long it 
takes" so like certain countries' mail delivery, you could get your 
piece of mail after 10 years of sitting in a bin in some warehouse, but 
no one ever would throw out a single piece of mail (other countries  
mail service does that).

Once the folks who ran IP networks over frame relay realized that you 
should never provision reliable delivery if you were running IP, this 
stopped happening.

So the story is that GPRS can, if it tries to provide QoS in the form of 
never dropping a frame, screw up TCP.

But this has nothing to do with mobility per se.   It has to do with 
GPRS, just as the old problems had to do with Frame Relay, not with high 
speed data.   The architecture of the GPRS network is too smart.

Detlef Bosau wrote:
> András Veres (IJ/ETH) wrote:
>> Hi,
>>
>> The 10 minutes reference in GPRS never happens in reality. It is 
>> similar to RFC 793 where an upper limit of TTL = one minute is set 
>> for TCP packets. Neither 1 nor 10 minutes actually happen in real 
>> networks.   
>
> O.k. Do 9 minutes 59 seconds ever happen? ;-)
>
> WRT David: You´re perfectly right that ETSI has nothing to do with 
> IETF. Similar to the IEEE (industry standards) and similar to 
> DigitalIntelXerox. However, TCP/IP sometimes runs on real networks and 
> therefore must use network technologies, e.g. IEEE 802.3 / Ethernet 
> VII AKA DIX or GPRS (and therefore about 50 or 100 ETSI standards ) ;-)
>
> Back to the subject. The GPRS standard specifies certain quantiles, a 
> 0.5 quantile and a 0.9 quantile for delays.
> Perfect.
>
> But in my opinion, this is not sufficient for a scientific discussion 
> of the suitability of mobile networks for end to end protocols _AND_ 
> applications.
>
> Now, there is a huge amount of papers (I don´t even listen examples, 
> there are literally hundreds of them, even in proceedings of highly 
> visible IEEE or ACM conferences) which deal with
> - delay spikes
> - spurious timeouts
> - large Bandwidth Delay Products
> - adverse effects on TCP caused by proportional fair scheduling
> etc. in mobile networks.
>
> In fact, the whole discussion "is there a problem with TCP in mobile 
> networks" deals exactly with these issues.
>
> So, my question is in other words: Are these issues substantiated? Or 
> do we hunt phantoms here?
>
> And because I´m interested in finding an answer to this question, I´m 
> interested to understand, where delay in mobile networks come from ;-)
>
>> Andras
>>
>>
>> -----Original Message-----
>> From: end2end-interest-bounces at postel.org 
>> [mailto:end2end-interest-bounces at postel.org] On Behalf Of Detlef Bosau
>> Sent: Tuesday, February 20, 2007 11:45 PM
>> To: e2e; Michael.kochte at gmx.net; frank.duerr
>> Subject: [e2e] Delays / service times / delivery times in wireless 
>> networks.
>>
>> Hi to all,
>>
>> I go in circles here and perhaps, someone can help me out.
>>
>> In networks like GPRS, IP packets can experience extremely large 
>> delivery times. The ETSI standard accepts up to 10 minutes.
>>
>> The effects of large and varying latencies on TCP are widely 
>> discussed. However, I still do not really understand where these 
>> delays come from.
>> When delivery times vary from 1 ms to 10 minutes, we talk about 6 
>> orders of magnitude. My question is: What is the reason for this?
>>
>> Possible delay sources (except processing, serialization, queieng,
>> propagation) are:
>>
>> - recovery / retransmission,
>> - roaming
>> - scheduling.
>>
>> I hardly belive that recovery latencies are that large because I can 
>> hardly imagine that a packet in the whole or in pieces is repeated up to
>> 1 million times. And even if this would be the case, it is 
>> interesting to see the variation of such latencies.
>>
>> In addition, I hardly believe in roaming latencies. Years ago, I was 
>> told extremely large latencies would result from roaming. However, if 
>> e.g. a mobile roams from one cell to another, to my understanding it 
>> keeps its SGSN in many cases and only the antenna station changes. 
>> So, this situation is basically not different from roaming with a 
>> normal voice stream. And that works transparent to the user.
>>
>> The only source where I ever read latencies and delay spikes of 
>> several seconds is the Globecom 2004 paper by Thierry Klein, which 
>> reported delay spikes of up to 2 seconds. And when I think about 
>> proportional fair scheduling, I think this _can_ be a source of large 
>> delay spikes.
>> However, I do not have access to any reliable material here.
>>
>> The problem appears to be quite technical and not very much TCP 
>> related. However, I´m admittedly somewhat tired to think about dely 
>> variations and delay spikes and possible adverse consequences upon 
>> TCP without having really understood the reasons for large delays and 
>> delay spikes.
>>
>> I don´t know whether this topic is of intereset here, but I would 
>> greatly appreciate any discussion of this matter. If someone can help 
>> me on this one, he is welcome to contact me off list, if this topic 
>> is not of general interest here.
>>
>> However, I´m somewhat helpless here.
>>
>> Thanks.
>>
>> Detlef
>>
>>
>>   
>
>
>
>