FreeBSD Window updates

[Venkat Venkatsubra]

Hi Andre,

>To answer your question: I do think we are fine with waiting for the
>delayed ACK.  If an application starts to seriously lag behind like
>in your example the feedback mechanism should work and cause the sender
>to slow down too.  The feedback loop in TCP is not only the network but

The case I was thinking was not apps lagging behind on the read.
The incoming packets got ahead and got dumped on the socket receive buffer
before the app's blocked read could get scheduled by the OS and start reading
the data. I am assuming the read needs the socket lock and it has to contend for this lock
with the incoming packets. The stack may not have any control over when the read eventually
gets to run. Suppose it runs after the 13th incoming packet got copied to the socket buffer 
and the window size is 13 MSS ?

> > What's the purpose of the 2 MSS check by the way ? 

>This is part of the Silly Window Syndrome prevention.  A good description is here:

Even without the 2 MSS check you are going to prevent SWS, isn't that right ?
The other checks will make sure small window updates are not sent.

Venkat



________________________________
From: Andre Oppermann <andre at freebsd.org>
To: Venkat Venkatsubra <venkatvenkatsubra at yahoo.com>
Cc: David Malone <dwmalone at maths.tcd.ie>; Rui Paulo <rpaulo at fnop.net>; Kevin Oberman <oberman at es.net>; freebsd-net at freebsd.org
Sent: Monday, December 1, 2008 3:11:43 PM
Subject: Re: FreeBSD Window updates

Venkat Venkatsubra wrote:
> Hi Andre,
> 
> When delayed Ack is set the window update is not sent.
> Does this mean when odd number of packets are received and later read,
> a window update won't go out either till the next segment arrives or
> 200 msecs delayed ack timer ? Can this reduced window block the sender from
> sending the next segment that we are waiting for to open up the window ?

Yes.  The very idea of delayed ACK is to reduce the network utilization
by ACKing only every other segment.  Window updates should not override
this as they currently do.  Nagle comes into plays as well where we wait
for the application to write something within the delayed ACK timeout to
piggyback the answer together with the ACK (and window update).

To answer your question: I do think we are fine with waiting for the
delayed ACK.  If an application starts to seriously lag behind like
in your example the feedback mechanism should work and cause the sender
to slow down too.  The feedback loop in TCP is not only the network but
also the sending and receiving application.  In a normal bulk transfer
where the receiving application services the receive buffer in regular
intervals we update the window with every ACK.

I'm open to other ideas if they fix the problem David is seeing without
having more serious shortcomings.

> What's the purpose of the 2 MSS check by the way ? 

This is part of the Silly Window Syndrome prevention.  A good description is here:
http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow.htm

PS: Attached is an updated version of the patch.  The flag TF_DELACK
can't be used to test for the presence of a delayed ACK.  The presence
of the delack timer has to be tested.

-- Andre

> Venkat  
> 
> 
> 
> ________________________________
> From: Andre Oppermann <andre at freebsd.org>
> To: David Malone <dwmalone at maths.tcd.ie>
> Cc: Rui Paulo <rpaulo at fnop.net>; freebsd-net at freebsd.org; Venkat Venkatsubra <venkatvenkatsubra at yahoo.com>; Kevin Oberman <oberman at es.net>
> Sent: Sunday, November 30, 2008 5:18:22 PM
> Subject: Re: FreeBSD Window updates
> 
> Andre Oppermann wrote:
>> David Malone wrote:
>>> I've got an example extract tcpdump of this at the end of the mail
>>> - here 6 ACKs are sent, 5 of which are pure window updates and
>>> several are 2us apart!
>>> 
>>> I think the easy option is to delete the code that generates explicit
>>> window updates if the window moves by 2*MSS. We then should be doing
>>> something similar to Linux. The other easy alternative would be to
>>> add a sysclt that lets us generate an window update every N*MSS and
>>> by default set it to something big, like 10 or 100. That should
>>> effectively eliminate the updates during bulk data transfer, but
>>> may still generate some window updates after a loss.
>> The main problem of the pure window update test in tcp_output() is
>> its complete ignorance of delayed ACKs.  Second is the strict 4.4BSD
>> adherence to sending an update for every window increase of >= 2*MSS.
>> The third issue of sending a slew of window updates after having
>> received a FIN (telling us the other end won't ever send more data)
>> I have already fixed some moons ago.
>> 
>> In my new-tcp work I've come across the window update logic some time
>> ago and backchecked with relevant RFCs and other implementations.
>> Attached is a compiling but otherwise untested backport of the new logic.
> 
> Slightly improved version attached.
>