Re: receiver window questions

[Michael Tuexen <tuexen@xxxxxxxxxxxxxx>]

Dear all,

for message size larger or equal to 176 byte, the behaviour seems
to be OK, for smaller ones there is a problem.

Please find attached two traces. arwnd175.pcap shows the buggy  
behaviour,
arwnd176.pcap shows the acceptable behaviour.

One the receiver side we just opened a listening 1-to-many style socket,
waited until the sender (a testtool) sent all its data and then started
to receive all messages. This is how we figured out that messages were  
lost.

Please let us know if you need more information.

Best regards
Michael

Attachment: arwnd175.pcap.gz
Description: GNU Zip compressed data

Attachment: arwnd176.pcap.gz
Description: GNU Zip compressed data

On May 30, 2008, at 1:51 AM, Neil Horman wrote:

> On Thu, May 29, 2008 at 11:50:56AM -0400, Vlad Yasevich wrote:
> > Neil Horman wrote:
> > > On Thu, May 29, 2008 at 11:06:11AM -0400, Vlad Yasevich wrote:
> >
> > I think this is hitting a condition where the receiver buffer is  
> > exhausted
> > prior
> > to rwnd.  We generally mark the TSN as received prior to attempting  
> > an
> > internal allocation to carry the data.  Thus, if this allocation  
> > fails,
> > we'll continue
> > reporting the tsn as received and move the cum-tsn if appropriate.
> >
> > We've been trying to figure out what the correct way to solve this
> > condition is
> > and so far haven't come up with a workable solution.
> You're right it does sound like that.  You know, I haven't visited  
> that code
> since we rewrote the receive buffer management code to expand  
> according to
> available memory with the sk_mem_schedule api.  Do you think this  
> could be as
> simple as removing this drop point?
>
> Neil