By backoff if you are referring to sender side mistakenly counting the window
updates
for a "fastretransmit" on a count of 3 dup acks, isn't the following in
tcp_input.c taking care of it ?
[Only when twin == tp->snd_wnd it is counted as a dup ack.]
1836 if (SEQ_LEQ(th->th_ack, tp->snd_una)) {
1837 if (tlen == 0 && tiwin == tp->snd_wnd) {
1838 V_tcpstat.tcps_rcvdupack++;
1839 /*
1840 * If we have outstanding data (other than
1841 * a window probe), this is a completely
1842 * duplicate ack (ie, window info didn't
1843 * change), the ack is the biggest we've
1844 * seen and we've seen exactly our rexmt
1845 * threshhold of them, assume a packet
1846 * has been dropped and retransmit it.
1847 * Kludge snd_nxt & the congestion
1848 * window so we send only this one
1849 * packet.
1850 *
How many acks do you see for every 2 full-sized segments received ? 2 or 1 ?
At least one ack needs to go out for every 2 incoming segments as per the rfc.
Associating window updates with delayed ack was not clear to me.
If I see the tcpdump output I might understand better.
Venkat
________________________________
From: Rui Paulo <[EMAIL PROTECTED]>
To: David Malone <[EMAIL PROTECTED]>
Cc: freebsd-net@freebsd.org; Kevin Oberman <[EMAIL PROTECTED]>
Sent: Friday, November 28, 2008 9:36:45 AM
Subject: Re: FreeBSD Window updates
On 27 Nov 2008, at 14:03, David Malone wrote:
> I was looking at some tcpdumps from a FreeBSD box receiving a TCP
> stream with someone yesterday and noticed that it seemed to be
> generating quite a lot of dupliacte acks. Looking more carefully,
> we noticed that the duplicates were actually window updates. The
> code for sending window updates can be found in:
>
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c?annot
> ate=1.157
>
> around lines 541-565. It seems that we generate a window update if
> the available buffer space changes by more than two packets, or if
> it changes by more than half the buffer size. This is probably a
> little aggressive, and in some cases seems to result in bursts of
> window updates that look like they should be batched. I wonder if
> it would make sense to not do a window update if a delayed ack is
> scheduled? It might even be possible to do them as a delayed ack
> without causing problems.
Yes, this makes sense. Probably this is a bug since 4.4BSD-Lite.
> I note that there is at least one PR mentioning we generate many
> window updates:
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=116335
>
> I also wonder if it might cause non-FreeBSD senders to back off,
> we are careful not to retransmit if we get window updates (see
>
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c?annota
> te=1.392
>
> about line 1836, but other OSes might not be and that might degrade
> our performance when receiving from a non-FreeBSD sender.
So, from what I understand, we do back off and that implies we are
losing performance in the FreeBSD to FreeBSD case, right?
--
Rui Paulo
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
