Re: comments on draft-ietf-tcpsat-stand-mech-04.txt

Vern Paxson <vern@ee.lbl.gov> Sat, 20 June 1998 06:21 UTC

Message-Id: <199806200621.XAA03746@daffy.ee.lbl.gov>
To: Spencer Dawkins <Spencer.Dawkins.sdawkins@nt.com>
Cc: tcp-over-satellite@achtung.sp.trw.com
Subject: Re: comments on draft-ietf-tcpsat-stand-mech-04.txt
In-Reply-To: Your message of Thu, 18 Jun 1998 16:51:17 EDT.
Date: Fri, 19 Jun 1998 23:21:39 -0700
From: Vern Paxson <vern@ee.lbl.gov>
Sender: owner-tcp-over-satellite@achtung.sp.trw.com
Precedence: bulk
Status: RO
Content-Length: 1066
Lines: 24

> Sorry for lowering the signal-to-noise ratio unnecessarily.
> 
> I've been thinking in terms of increased initial congestion window
> proposals, so what I trying to say was "if the recommended initial cnwd is 2
> (or 3, or 4), we can ACK-per-packet in this window without doing
> ACK-per-packet in all situations". Sorry for not providing this context in
> my previous post.
> 
> I wasn't counting on the receiver knowing what initial cnwd the sender is
> using. I was just thinking that any increases in recommended initial cnwd
> could be used as a conservative approximation of how much additional ACKing
> we can do without causing problems.
> 
> At the very least, we could ACK the FIRST packet!

I strongly support this, and hope others agree that in this modest form,
ack-every-packet makes good sense.

Note: one of the arguments for cwnd=4 was that you then can retransmit
the via fast retransmission instead of timeout, if there's loss in the
initial window.  *This only works with ack-every-packet, which was assumed
when making this argument!*

		Vern