tasklwIP - A Lightweight TCP/IP stack - Tasks: task #13757, Investigate whether fast rexmit...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #13757: Investigate whether fast rexmit should restart RTO timer

Submitter:  Joel Cunningham <jcunningham>
Submitted:  Thu 01 Oct 2015 10:41:18 PM UTC
   
 
Category:  TCP Should Start On:  Thu 01 Oct 2015 12:00:00 AM UTC
Should be Finished on:  Thu 01 Oct 2015 12:00:00 AM UTC Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  jcunningham Percent Complete:  100%
Open/Closed:  Closed Planned Release:  None
Effort:  0.00

Wed 16 Mar 2016 08:51:03 PM UTC, comment #4: 

Excellent! I've set rtime=0 in tcp_rexmit_fast(). Thanks for digging into this!

Simon Goldschmidt <goldsimon>
Group administrator
Tue 08 Mar 2016 11:25:12 PM UTC, comment #3: 

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

Joel Cunningham <jcunningham>
Group Member
Mon 07 Mar 2016 04:52:31 PM UTC, comment #2: 

Not yet, thanks for getting this back on my radar, it has slipped down the backlog.  I might have time this week or next to review the RFCs

Joel Cunningham <jcunningham>
Group Member
Mon 07 Mar 2016 09:19:36 AM UTC, comment #1: 

Any progress on this?

Simon Goldschmidt <goldsimon>
Group administrator
Thu 01 Oct 2015 10:41:18 PM UTC, original submission:  

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.

Joel Cunningham <jcunningham>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by jcunningham (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-03-16 goldsimon StatusNone Done
        Percent Complete0% 100%
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code