Date: Fri, 28 Nov 2008 08:26:23 -0800 (PST) From: Venkat Venkatsubra <venkatvenkatsubra@yahoo.com> To: Rui Paulo <rpaulo@fnop.net>, David Malone <dwmalone@maths.tcd.ie> Cc: freebsd-net@freebsd.org, Kevin Oberman <oberman@es.net> Subject: Re: FreeBSD Window updates Message-ID: <725753.56771.qm@web58304.mail.re3.yahoo.com> References: <200811271403.aa55110@walton.maths.tcd.ie> <457EB70C-A3E6-4B3A-A707-CDE62FD2E8E0@fnop.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <rpaulo@fnop.net>=0ATo: David Malone <dwmalone@maths.tcd.ie>=0ACc: freebs=
d-net@freebsd.org; Kevin Oberman <oberman@es.net>=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?725753.56771.qm>