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

["Spencer Dawkins" <[e-mail]>]

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!

Spencer

> -----Original Message-----
> From:	Eric Travis [SMTP:[e-mail]]
> Sent:	Thursday, June 18, 1998 2:57 PM
> To:	Dawkins, Spencer [RICH1:2011-I:EXCH]
> Cc:	[e-mail]
> Subject:	RE: comments on draft-ietf-tcpsat-stand-mech-04.txt
> 
> 
> > I am, of course, Easily Confused, but I thought we were talking about
> > turning off delayed ACKs ONLY during slow-start.
> > 
> > Once you've achieved steady-state, there's no performance advantage to
> > ACKing every packet. Is there?
> 
> How does the fellow doing the acking know that slow-start has finished?
> :o)
> 
> We've thought about ways of infering this and of adding reliable
> out-of-band signaling for this - but the former complicates the otherwise
> simple receiver, and the latter requires machinery that doesn't already
> exist (options are not sent reliably).
> 
> Actually, if you prematurely leave slow-start (more common than not),
> growing your cwnd more aggressively in congestion-avoidance can provide
> a substantial performance gain (if it doesn't otherwise get you into
> trouble);
> 
> Eric