[e2e] Spurious Timeouts in mobile wireless networks, was: Re: Retransmission Timouts revisited

Detlef Bosau detlef.bosau at web.de
Fri Sep 2 12:27:44 PDT 2005


Filipe Abrantes wrote:
> 
>>
> 
> Hmmmm, some misunderstanding here i beleive: packet K and K+1 arrive at 
> destination, (K is the seqno of TCP), however packet K has to be 
> retransmitted in some wireless hop in the path, due to transmission 

O.k.


> errors. What Francesco was saying (if i understood it correctly) is that 
> this restransmission will lead to an increase of the rtt which will be 
> noted by the sender both in packet K and packet K+1 because packet K+1 
> goes imediatly after packet K. So if packet K time's out, then packet 


O.k.

> K+1 will also timeout. Francesco claimed that this would have some 
> effect on the spurious timeout detection which i didn't quite 
> understood, but im also not that familiar with rto estimation procedures.


So, there is some variation in the end to end latency. Right?

RTO = E + 2*V,

in later Implementations:

RTO = E + 4*V.

Variance increases => RTO increases.

That´s the simple view.

The other problem is perhaps the delay spike, you talk about, because we 
try to maintain the packet order at any cost.

This was my question, whether delay spikes were a problem.

One way to hide delay spikes from a sender are PEP.

Another, perhaps much more appealing way (and _please_, if this sounds 
reasonable and no one did it, let me the chance to publish it 
myself....) because it does not require any PEP or splitting or 
something else on L3 and above is to exploit the robustness TCP 
following actual RFCs against packet reordering, is to interleave the
radio blocks of more than one TCP packet and thus to spread delay spikes 
about several packets. It´s just a rough idea now. However, if it is 
helpful, please leave it to me. If it is nonsense, please tell it to me 
as well. It would be a possiblity to map a behaviour, TCP cannot deal 
with, unto one which can be dealt with without difficulties.
One could call this "delay spreading". I don´t know, whether it works.
I thouht of it spontaneously yesterday after the recent posts here.

Detlef



-- 
Detlef Bosau
Galileistrasse 30
70565 Stuttgart
Mail: detlef.bosau at web.de
Web: http://www.detlef-bosau.de
Mobile: +49 172 681 9937



More information about the end2end-interest mailing list