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

[David P. Reed]

You are right that there is a difference between congestion and lossy 
links, but persisting for a long time to transmit a packet causes 
congestion back up the path from the source, and that backed up queueing 
can hurt TCP, because TCP depends on a fast end-to-end control loop to 
manage window size.

So the FR and GPRS cases are different to some extent, I agree.

Francesco Vacirca wrote:
> I think the comparison between FR and GPRS is not correct...
>
> It is different to wait in the buffer because the system waits for 
> congestion ending and to wait in the buffer for link failure 
> (retransmitting packets)....
>
> In the second case the delay cannot be avoided... if the wireless link 
> is down for packet #1 (very high bit error rate), the link is down 
> also for the next packets, so the delay cannot be avoided... and 
> limiting the number of link layer retransmissions or avoid LL 
> retransmissions does not benefit TCP.
>
> The difference is between avoiding packet losses due to congestion and 
> packet losses due to link failures.
>
> Francesco
>
>
> David P. Reed wrote:
>> 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
>>>>
>>>>
>>>>   
>>>
>>>
>>>
>>>
>>
>