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

[Filipe Abrantes]

Detlef Bosau wrote:
> Francesco Vacirca wrote:
> 
>> I'm agree with that... what I'm trying to say is that L2 
>> retransmissions are due to transmission errors on the wireless 
>> channel... and with all kind of ARQ protocols (from Stop'n Wait to 
>> Selective Repeat) if you drop packet K (because one or more PDUs 
>> belonging to that TCP-SDU reached the max number of retransmissions 
>> N), that implies that if packet K+1 crosses the wireless channel it 
>> will arrive after the moment that K would arrived with some more 
>> retransmissions... and this implies that if 
> 
> 
> 
> 
> I admit: I cannot follow.
> 
> Packet K is lost. Packet K+1 not. What´s the problem?
> 
> And what do you mean with "K+1 .... will arrive after the moment K would 
> arrived with...."?
> 
> K did not arrive.
> 
> So K´s arrivale time in case of ... does not matter.
> 

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 
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 
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.

Regards,

Filipe

>> the RTO would expire for K with infinite retransmissions, it would 
>> expire also for K+1 with N retransmissions... with no advantages for 
> 
> 
> Why?
> 
> I do not the the connection from your maximum retransmission count N and 
> the TCP RTO. In addition, N is purely a L2 topic. For TCP/IP, a packet 
> is either delivered and experiences a certian latency or it is lost.
> 
> 
>> TCP,  but with some small disadvantages that I do not think could 
>> influence the overall goodput.
>> Moreover with FRTO (or other mechanisms) TCP can recover a spurious 
>> timeout, but a normal timeout (due to real loss) can just be recovered 
>> by slow-start because it is a real loss with RTO expiration and there 
>> is no possibility to distinguish it from a congestion event (without 
>> explicit notification).
> 
> 
> 
> Nevertheless, there are situations where a slow start is not necessary.
> 
> Basically, my question is: Do spurious timeouts happen really that often?
> 
> Or in different terms: From what I´ve learned during the last few weeks,
> 3G networks are basically understood, spurious timeouts do happen, 
> occasionally, now and then. If so, we are able to detect them and 
> recover from, e.g. unnecessar congestion handling.
> 
> So, for the case of TCP over 3G networks: Is this case closed?
> 
> Just a question.
> 
> Detlef
> 

-- 
Filipe Lameiro Abrantes
INESC Porto
Campus da FEUP
Rua Dr. Roberto Frias, 378
4200-465 Porto
Portugal

Phone: +351 22 209 4266
E-mail: fla at inescporto.pt