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

[Joel Cunningham]

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

                 Summary: Investigate whether fast rexmit should restart RTO
timer
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: jcunningham
            Submitted on: Thu 01 Oct 2015 10:41:18 PM GMT
                Category: TCP
         Should Start On: Thu 01 Oct 2015 12:00:00 AM GMT
   Should be Finished on: Thu 01 Oct 2015 12:00:00 AM GMT
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
        Percent Complete: 0%
             Assigned to: jcunningham
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
                  Effort: 0.00

    _______________________________________________________

Details:

>From static analysis of LwIP code, it appears that if TCP fast retransmission
happens, the normal retransmission timeout (RTO) is not reset.  The timer is
controlled by the variable pcb->rtime.

This is reset in the following conditions:

 1. RTO times out
 2. ACK is received for new data and there is additional unacked data

This could lead to a case where if a fast retransmit is sent less than the
round trip time away from when the RTO expires, we would end up sending a
duplicate retransmit. Or if the fast retransmit is dropped, we'll end up
sending another retransmission shortly after.

This is a little wasteful to send the additional retransmit in this case but
I'm not sure if it qualifies as a bug.

I'll go through RFC 5681 (TCP Congestion Control) and other stacks (Linux/BSD)
to see how those stacks are behaving.




    _______________________________________________________

Reply to this item at:

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

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