lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] Re: [patch #6537] wnd_scale TCP option addition


From: Rishi Khan
Subject: [lwip-devel] Re: [patch #6537] wnd_scale TCP option addition
Date: Wed, 8 Apr 2009 06:55:18 -0400

You need to implement SACK. That will fix it.
On Apr 8, 2009, at 5:39 AM, Wim Dumon wrote:


Follow-up Comment #6, patch #6537 (project lwip):

I encountered an issue with this patch. I observed data loss and performance degradation when receiving data over TCP connections with large window sizes (e.g. TCP_WND=120KBytes). My shift is set at 7 (but it could be anything
else).
This is the problem: suppose window is usually filled for about 70K, caused by the bandwidth*delay principle. Imagine that the link works well, and at a certain moment a single packet is dropped. The OOSEQ code queues packets, but there is a little gap in the sequence number for the first ooseq packet. When
that gap is filled by a retransmit of the missing data, all the
out-of-sequence queued packets, amounting to 70K of data in our example, is concatenated in one pbuf (it is called recv_data). But the tot_len field of a pbuf is only 16bit.... The result I observe is that there is a 64K gap in the
received data stream.

Isn't the intention of this patch to allow TCP_WND to be > 64K? Any hints on how to solve this? I have the feeling that simply changing tot_len to a u32_t
will not be sufficient. Using multiple pbufs is probably easier?


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?6537>

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







reply via email to

[Prev in Thread] Current Thread [Next in Thread]