[lwip-devel] [task #13757] Investigate whether fast rexmit should restart RTO timer

[Joel Cunningham]

Follow-up Comment #3, task #13757 (project lwip):

Spent some time looking this up and I found no mention of how to handle the
RTO timer from RFC 5681 after entering recovery mode and performing the fast
retransmit.

I looked at Linux and FreeBSD next.

FreeBSD appears to be clearing then starting the RTO timer.  Here is the
appropriate function that handles duplicate ACKs:
https://svnweb.freebsd.org/base/head/sys/netinet/tcp_input.c?view=markup#l2577

Here we can see if the number of duplicate ACKs equals tcprexmtthresh, it
calls tcp_timer_activate(tp, TT_REXMT, 0); which stops the timer.  Then it
calls tfb_tcp_output which is a function pointer mapped to tcp_output(), where
I believe the timer is restarted

For Linux, I found a research paper describing the behavior of TCP RTO timer
management.  http://people.cs.clemson.edu/~westall/853/linuxtcp.pdf On page
6-7, section 3.3.1 "Retransmission timer calculation"

"The RTO timer is reset every time an acknowledgement advancing
the window arrives at the sender. The RTO timer is also reset when the sender
enters the Recovery state and retransmits the first segment. During the rest
of the Recovery state the RTO timer is not reset, but a packet is marked lost,
if more than RTO's worth of time has passed from the first transmission of
the
same segment"

I think as far as LwIP is concerned, we can easily restart the timer when
entering recovery mode.  This would ensure we don't have an early
retranmission after the fast retransmit and shouldn't cause any functional
problems as we will continue the timer based retranmits after the RTO period
following the fast retransmit

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?13757>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/