Date: Mon, 01 Dec 2008 22:11:43 +0100 From: Andre Oppermann <andre@freebsd.org> To: Venkat Venkatsubra <venkatvenkatsubra@yahoo.com> Cc: David Malone <dwmalone@maths.tcd.ie>, Rui Paulo <rpaulo@fnop.net>, Kevin Oberman <oberman@es.net>, freebsd-net@freebsd.org Subject: Re: FreeBSD Window updates Message-ID: <4934530F.20104@freebsd.org> In-Reply-To: <538219.92538.qm@web58307.mail.re3.yahoo.com> References: <200811291746.aa88825@walton.maths.tcd.ie> <49331DA0.3070804@freebsd.org> <49331F3E.2090305@freebsd.org> <538219.92538.qm@web58307.mail.re3.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------070203050102030008020709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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@freebsd.org> > To: David Malone <dwmalone@maths.tcd.ie> > Cc: Rui Paulo <rpaulo@fnop.net>; freebsd-net@freebsd.org; Venkat Venkatsubra <venkatvenkatsubra@yahoo.com>; Kevin Oberman <oberman@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. > --------------070203050102030008020709 Content-Type: text/plain; name="tcp_wu_fix-20081201-2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tcp_wu_fix-20081201-2.diff" Index: tcp_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_output.c,v retrieving revision 1.158 diff -u -p -r1.158 tcp_output.c --- tcp_output.c 27 Nov 2008 13:19:42 -0000 1.158 +++ tcp_output.c 1 Dec 2008 21:06:28 -0000 @@ -539,29 +539,59 @@ after_sack_rexmit: } /* - * Compare available window to amount of window - * known to peer (as advertised window less - * next expected input). If the difference is at least two - * max size segments, or at least 50% of the maximum possible - * window, then want to send a window update to peer. + * Compare available window to amount of window known to peer + * (as advertised window less next expected input) and decide + * if we have to send a pure window update segment. + * + * When a delayed ACK is scheduled, do nothing. It will update + * the window anyway in a few milliseconds when the: + * - next segment arrives we have to ack immediately; + * - application sends some data back to the peer; + * - delayed ACK timer expires. + * + * If the receive socket buffer has less than 1/4 of space + * available and if the difference is at least two max size + * segments, send an immediate window update to peer. + * + * Otherwise if the difference is 1/8 (or more) of the receive + * socket buffer, or at least 1/2 of the maximum possible window, + * then we send a window update too. + * * Skip this if the connection is in T/TCP half-open state. * Don't send pure window updates when the peer has closed * the connection and won't ever send more data. + * + * See RFC793, Section 3.7, page 43, Window Management Suggestions + * See RFC1122: Section 4.2.3.3, When to Send a Window Update + * + * Note: We are less aggressive with sending window update than + * recommended in RFC1122. This is fine with todays large socket + * buffers and will not stall the peer. In addition we piggy back + * window update on regular ACKs and sends. */ - if (recwin > 0 && !(tp->t_flags & TF_NEEDSYN) && - !TCPS_HAVERCVDFIN(tp->t_state)) { + if (recwin > 0 && !tcp_timer_active(tp, TT_DELACK) && + !(tp->t_flags & TF_NEEDSYN) && !TCPS_HAVERCVDFIN(tp->t_state)) { /* * "adv" is the amount we can increase the window, * taking into account that we are limited by * TCP_MAXWIN << tp->rcv_scale. + * + * NB: adv must be equal or larger than the smallest + * unscaled window increment. */ long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) - (tp->rcv_adv - tp->rcv_nxt); - if (adv >= (long) (2 * tp->t_maxseg)) - goto send; - if (2 * adv >= (long) so->so_rcv.sb_hiwat) - goto send; + if (adv >= (long)0x1 << tp->rcv_scale) { + if (recwin <= (long)(so->so_rcv.sb_hiwat / 4) && + adv >= (long)(2 * tp->t_maxseg)) + goto send; + if (adv >= (long)(so->so_rcv.sb_hiwat / 8) && + adv >= (long)tp->t_maxseg) + goto send; + if (2 * adv >= (long)so->so_rcv.sb_hiwat) + goto send; + } } /* --------------070203050102030008020709--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4934530F.20104>