_
From: Andre Oppermann <[EMAIL PROTECTED]>
To: Venkat Venkatsubra <[EMAIL PROTECTED]>
Cc: David Malone <[EMAIL PROTECTED]>; Rui Paulo <[EMAIL PROTECTED]>; Kevin
Oberman <[EMAIL PROTECTED]>; freebsd-net@freebsd.org
Sent: Monday, December 1, 2008 3:11:43 PM
Subj
gt;; freebsd-net@freebsd.org; Venkat Venkatsubra
<[EMAIL PROTECTED]>; Kevin Oberman <[EMAIL PROTECTED]>
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
So the apps read buffer is possibly 32 times 2^8 = 8KB ?
(32 being the increment in each of those window updates.)
From: David Malone <[EMAIL PROTECTED]>
To: Venkat Venkatsubra <[EMAIL PROTECTED]>
Cc: Rui Paulo <[EMAIL PROTECTED]>; freeb
dates.
(Since I don't know the window scale factor for the connection, I couldn't
figure out
how much each of the window updates was opening up the window.)
Venkat
From: David Malone <[EMAIL PROTECTED]>
To: Venkat Venkatsubra <[EMAIL PROTECTED
Looking at some very old versions (4.3 BSD Reno for instance),
the regular acks used to be sent only through these window updates.
i.e. acks were sent only when the apps read the data. Acks are piggybacked
with window updates. Or, delayed till the delayed ack timer expires if the apps
is not readin
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)) {
18
