buglwIP - A Lightweight TCP/IP stack - Bugs: bug #26349, Nagle algorithm doesn't send...

 
 

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

bug #26349: Nagle algorithm doesn't send although segment is full

Submitted by:  Simon Goldschmidt <goldsimon>
Submitted on:  Sun 26 Apr 2009 12:06:59 PM UTC  
 
Category:  TCP Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Fixed
Privacy:  Public Assigned to:  Simon Goldschmidt <goldsimon>
Open/Closed:  Closed Planned Release:  None
lwIP version:  CVS Head

Sun 03 May 2009 02:18:14 PM UTC, comment #4: 

Fixed by checking unsent->len >= pcb->mss in define tcp_do_output_nagle()

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Sun 03 May 2009 12:22:29 PM UTC, comment #3: 

I discovered there is just the test missing if unsent->len >= pcb->mss (which is the case if we enqueued just MSS of data, nothing more, so unsent->next is still NULL).

I'll add just that line and it should be fixed.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Mon 27 Apr 2009 06:05:10 AM UTC, comment #2: 

Well, at least that's something to start with (although I'd really like to know where Comer got that from).

> .. but do not send additional segments until there is sufficient
> data to fill a maximum-sized segment.


That's the point where we are currently doing wrong.

> If still waiting to send when an acknowledgement arrives, send
> all data that has accumulated in the buffer.


Obviously, he can't mean 'send more than the tx window'. But we have a problem with lwIP here in that we can't split already enqueued data to send less than MSS (if that much data is enqueued).

This is a generic limitation but has not yet been seen as serious: we just wait until the window opens a bit more.

BTW: this suggests lwIP does not work well with window sizes < 2*MSS (or even 4*MSS).

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Sun 26 Apr 2009 11:30:52 PM UTC, comment #1: 

I had a look at what my TCP/IP book says (Internetworking with TCP/IP, vol 1 by Comer).

"Send-Side Silly Window Avoidance: When a sending application generates additional data to be sent over a connection for which previous data has been transmitted but not yet acknowledged, place the new data in the output buffer as usual, but do not send additional segments until there is sufficient data to fill a maximum-sized segment. If still waiting to send when an acknowledgement arrives, send all data that has accumulated in the buffer. Apply the rule even when the user requests a push operation."

According to this description, a Nagle implementation should send when it has accumulated a full packet, and I agree that LWIP should do this.

Not sure how this interacts with the transmit window size. For example, what would happen if the transmit window is currently less than MSS? Should the "send now" trigger be the lesser of the tx window size and MSS?

The original description of the algorithm is RFC0896 (by Nagle) but it isn't an official standard and it concentrates on avoiding the problem of small packets without explaining possible exceptions when there is no point waiting for further data to send. I haven't spotted an RFC which goes into more detail but I haven't done an extensive search.

David Empson <dempson>
Sun 26 Apr 2009 12:06:59 PM UTC, original submission:  

While debugging the fix for bug #24212 (Deadlocked tcp_retransmit due to exceeded pcb->cwnd), I discovered that the nagle algorithm doesn't send data (because unsent->next is null) although the unsent segment is as big as it can get (i.e. 1460 bytes).

My question is: is this OK? Transmission speed would be better when sending that packet right away, e.g. based on "unsent->len == pcb->mss", since there is nothing to be improved here.

However, I don't know what the standards say to this, thus this bug entry to discuss it.

Simon Goldschmidt <goldsimon>
Project AdministratorIn 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 dempson (Posted a comment)
  • -email is unavailable- added by goldsimon (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
    2009-05-03 goldsimon StatusNone => Fixed
        Assigned toNone => goldsimon
        Open/ClosedOpen => Closed

    Back to the top


    Powered by Savane 3.5