Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!ucbvax!HELIOS.EE.LBL.GOV!van
From: van@HELIOS.EE.LBL.GOV (Van Jacobson)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Go-Ahead Considered Harmless??
Message-ID: <8901051158.AA14205@helios.ee.lbl.gov>
Date: 5 Jan 89 11:58:38 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 70

> I've spent a few minutes trying to figure out what interactions exist
> between Jacobson style TCP and TACs but did not get far, so far.

Bill -

The 20 line comment preceeding the relevant code in tcp_output
probably makes it hard to find (I keep telling Mike Karels that
C is self documenting -- he insists on these huge block comments
that just use up screen real estate when you're trying to read
the code :-).  Take a look at the code below the comment that
starts "TCP window updates are not reliable,...".  If the timer
setup in tcp_setpersist seems obscure, see the 30 or so lines of
comment in tcp_input that start with the line "srtt is stored as
fixed point with 3 bits ...".  (Some other code relevant to
poor, buffer-starved TACs, but not with zero windows, is
associated with the sender's estimate of the peer's receive
buffer size, max_sndwnd.  See the comment starting "Sender silly
window avoidance..." in tcp_output.)

The code does just what you thought it should -- probe with
exponential backoff from the current RTO -- and has done this in
every version of BSD since 4.1c.  There is no 2 minute timer and
never has been.  There is a 5 second minimum interprobe time
(which seems to accommodate the human response time in the usual
zero window cause on a local net -- ^S on a terminal -- and is
effectively a nop on a long haul net).  Attached is a trace of
what happens when the window goes to zero (obtained by starting
an ftp from a file on yak to a terminal window on okeeffe then
^S'ing the window).  Note the first probe goes out 5 sec after
the zero window is announced, there are 3 probes at 5 sec
spacing (it takes 2 backoffs to ramp the 1 sec rto above the
minimum interprobe time), then pure binary exponential after
that (if you don't want to compute them, the deltas between probe
sends are 5, 5, 5, 8, 16, 32 & 64 sec starting from the zero-window
ack at 00:56:14.65 and the probe at 00:56:19.48).

If your comment referred to interaction between slow-start
and/or congestion avoidance and TACs, the answer is there isn't
any.  The only 4BSD congestion algorithm that comes into play
with TACs is John Nagle's small packet avoidance algorithm
(which is essentially the computation of "idle" and the line
"if ((idle || tp->t_flags & TF_NODELAY) &&" below the comment
starting "Sender silly window avoidance..." in tcp_output) and
by all reports this is an unmitigated win.

 - Van


00:56:14.31  okeeffe.1064 > yak.ftp-data: . ack 114177 win 4096
00:56:14.31  yak.ftp-data > okeeffe.1064: . 116225:116737(512) ack 1 win 4096
00:56:14.32  yak.ftp-data > okeeffe.1064: . 116737:117249(512) ack 1 win 4096
00:56:14.32  yak.ftp-data > okeeffe.1064: . 117249:117761(512) ack 1 win 4096
00:56:14.32  yak.ftp-data > okeeffe.1064: P 117761:118273(512) ack 1 win 4096
00:56:14.45  okeeffe.1064 > yak.ftp-data: . ack 116225 win 2048
00:56:14.51  okeeffe.1064 > yak.ftp-data: . ack 117761 win 512
00:56:14.65  okeeffe.1064 > yak.ftp-data: . ack 118273 win 0
00:56:19.48  yak.ftp-data > okeeffe.1064: . 118273:118274(1) ack 1 win 4096
00:56:19.52  okeeffe.1064 > yak.ftp-data: . ack 118273 win 0
00:56:24.48  yak.ftp-data > okeeffe.1064: . 118273:118274(1) ack 1 win 4096
00:56:24.52  okeeffe.1064 > yak.ftp-data: . ack 118273 win 0
00:56:29.48  yak.ftp-data > okeeffe.1064: . 118273:118274(1) ack 1 win 4096
00:56:29.52  okeeffe.1064 > yak.ftp-data: . ack 118273 win 0
00:56:37.48  yak.ftp-data > okeeffe.1064: . 118273:118274(1) ack 1 win 4096
00:56:37.52  okeeffe.1064 > yak.ftp-data: . ack 118273 win 0
00:56:53.48  yak.ftp-data > okeeffe.1064: . 118273:118274(1) ack 1 win 4096
00:56:53.52  okeeffe.1064 > yak.ftp-data: . ack 118273 win 0
00:57:25.48  yak.ftp-data > okeeffe.1064: . 118273:118274(1) ack 1 win 4096
00:57:25.52  okeeffe.1064 > yak.ftp-data: . ack 118273 win 0
00:58:29.48  yak.ftp-data > okeeffe.1064: . 118273:118274(1) ack 1 win 4096
00:58:29.52  okeeffe.1064 > yak.ftp-data: . ack 118273 win 0