[e2e] Spurious Timeouts in mobile wireless networks, was: Re: Retransmission Timouts revisited
fla at inescporto.pt
Fri Sep 2 11:24:18 PDT 2005
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.
>> the RTO would expire for K with infinite retransmissions, it would
>> expire also for K+1 with N retransmissions... with no advantages for
> 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.
Filipe Lameiro Abrantes
Campus da FEUP
Rua Dr. Roberto Frias, 378
Phone: +351 22 209 4266
E-mail: fla at inescporto.pt
More information about the end2end-interest