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

Submitted by:  Joel Cunningham <jcunningham>
Submitted on:  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
Percent Complete:  100% Assigned to:  Joel Cunningham <jcunningham>
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>
Project 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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
Mon 07 Mar 2016 09:19:36 AM UTC, comment #1:

Any progress on this?

Simon Goldschmidt <goldsimon>
Project 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>
Project MemberIn charge of this item.


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)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




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