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

[Rishi Khan]

I'm mistaken. I think Kieran is correct. See below:

> On Wed, 2009-04-08 at 06:55 -0400, Rishi Khan wrote:
>
> > You need to implement SACK. That will fix it.
>
> I don't think so.  His problem is not caused by the other side
> retransmitting lots of data, but by us concatenating the whole OOSEG
> queue into a single pbuf and overflowing the length field.
>
> Kieran






On Apr 8, 2009, at 8:17 AM, Wim Dumon wrote:

> 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/