From owner-freebsd-net@FreeBSD.ORG Fri Nov 28 16:53:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C19F1065674 for ; Fri, 28 Nov 2008 16:53:04 +0000 (UTC) (envelope-from venkatvenkatsubra@yahoo.com) Received: from web58304.mail.re3.yahoo.com (web58304.mail.re3.yahoo.com [68.142.236.157]) by mx1.freebsd.org (Postfix) with SMTP id EA0F18FC08 for ; Fri, 28 Nov 2008 16:53:03 +0000 (UTC) (envelope-from venkatvenkatsubra@yahoo.com) Received: (qmail 57497 invoked by uid 60001); 28 Nov 2008 16:26:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=5Utts67klHw1RsQC2CV1OL6waGevB9v0KXY5+0lUue+NvzHe1i2rh2EgLiqSIhGybGKhVTqdjE+AfcioWBFph04R21yONgXSm+Q8ZoRGUDpgEAJP1aZ6gdPPenzTLDkfOs5IOwVpmPpvFPyjF0sxg+F+UbGa2FfUrif8AvgdJu8=; X-YMail-OSG: cbHm.ucVM1lWDw1bRM45cRKkecCvO9Wq.NxvMsOSHrqi6k14vqFFzTBnGPRAcfr3DuxVo2sXvf1VkGyWGI1juYvLWTz_HFyQW43VDAW_vv9FEXvdZCdwPal26YpROp9d4gcqNpR4OtP2mhZuTVgmmoiIfxZJ8GSHuozqBxdVofQkHgXKVn3Z6Z994gHG Received: from [70.112.131.248] by web58304.mail.re3.yahoo.com via HTTP; Fri, 28 Nov 2008 08:26:23 PST X-Mailer: YahooMailRC/1155.32 YahooMailWebService/0.7.260.1 References: <200811271403.aa55110@walton.maths.tcd.ie> <457EB70C-A3E6-4B3A-A707-CDE62FD2E8E0@fnop.net> Date: Fri, 28 Nov 2008 08:26:23 -0800 (PST) From: Venkat Venkatsubra To: Rui Paulo , David Malone MIME-Version: 1.0 Message-ID: <725753.56771.qm@web58304.mail.re3.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Kevin Oberman Subject: Re: FreeBSD Window updates X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2008 16:53:04 -0000 By backoff if you are referring to sender side mistakenly counting the wind= ow updates=0Afor=A0a "fastretransmit" on a count of 3 dup acks, isn't the f= ollowing in tcp_input.c taking care of it ?=0A[Only when twin =3D=3D tp->sn= d_wnd it is counted as a dup ack.]=0A1836 if (SEQ_LEQ(th->th_ack, tp->snd_u= na)) {=0A1837 if (tlen =3D=3D 0 && tiwin =3D=3D tp->snd_wnd) {=0A1838 V_tcp= stat.tcps_rcvdupack++;=0A1839 /*=0A1840 * If we have outstanding data (othe= r than=0A1841 * a window probe), this is a completely=0A1842 * duplicate ac= k (ie, window info didn't=0A1843 * change), the ack is the biggest we've=0A= 1844 * seen and we've seen exactly our rexmt=0A1845 * threshhold of them, a= ssume a packet=0A1846 * has been dropped and retransmit it.=0A1847 * Kludge= snd_nxt & the congestion=0A1848 * window so we send only this one=0A1849 *= packet.=0A1850 *=0AHow many acks do you see for every 2 full-sized segment= s received ? 2 or 1 ?=0AAt least one ack needs to go out for every 2 incomi= ng segments as per the rfc.=0AAssociating window updates with delayed ack= =A0was not clear to me.=0AIf I see the tcpdump output I might understand be= tter.=0A=0AVenkat=0A=0A=0A________________________________=0AFrom: Rui Paul= o =0ATo: David Malone =0ACc: freebs= d-net@freebsd.org; Kevin Oberman =0ASent: Friday, November = 28, 2008 9:36:45 AM=0ASubject: Re: FreeBSD Window updates=0A=0A=0AOn 27 Nov= 2008, at 14:03, David Malone wrote:=0A=0A> I was looking at some tcpdumps = from a FreeBSD box receiving a TCP=0A> stream with someone yesterday and no= ticed that it seemed to be=0A> generating quite a lot of dupliacte acks. Lo= oking more carefully,=0A> we noticed that the duplicates were actually wind= ow updates. The=0A> code for sending window updates can be found in:=0A>=0A= > =A0=A0=A0 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_outpu= t.c?annot=0A> ate=3D1.157=0A>=0A> around lines 541-565. It seems that we ge= nerate a window update if=0A> the available buffer space changes by more th= an two packets, or if=0A> it changes by more than half the buffer size. Thi= s is probably a=0A> little aggressive, and in some cases seems to result in= bursts of=0A> window updates that look like they should be batched. I wond= er if=0A> it would make sense to not do a window update if a delayed ack is= =0A> scheduled? It might even be possible to do them as a delayed ack=0A> w= ithout causing problems.=0A=0AYes, this makes sense. Probably this is a bug= since 4.4BSD-Lite.=0A=0A> I note that there is at least one PR mentioning = we generate many=0A> window updates:=0A>=0A> =A0=A0=A0 http://www.freebsd.o= rg/cgi/query-pr.cgi?pr=3D116335=0A>=0A> I also wonder if it might cause non= -FreeBSD senders to back off,=0A> we are careful not to retransmit if we ge= t window updates (see=0A>=0A> =A0=A0=A0 http://www.freebsd.org/cgi/cvsweb.c= gi/src/sys/netinet/tcp_input.c?annota=0A> te=3D1.392=0A>=0A> about line 183= 6, but other OSes might not be and that might degrade=0A> our performance w= hen receiving from a non-FreeBSD sender.=0A=0A=0ASo, from what I understand= , we do back off and that implies we are=A0 =0Alosing performance in the Fr= eeBSD to FreeBSD case, right?=0A=0A--=0ARui Paulo=0A=0A____________________= ___________________________=0Afreebsd-net@freebsd.org mailing list=0Ahttp:/= /lists.freebsd.org/mailman/listinfo/freebsd-net=0ATo unsubscribe, send any = mail to "freebsd-net-unsubscribe@freebsd.org"=0A=0A=0A