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

[Wim Dumon]

Can you explain how SACK, an optimization, can fix data corruption in
the TCP stream? I am missing entire chunks of 64K when I read from the
socket.

Best regards,
Wim.

On Wed, Apr 8, 2009 at 12:55 PM, Rishi Khan <address@hidden> wrote:
> 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/
>>
>>
>
>