Subject: Last Call for TCP Congestion Control I-D

From: Vern Paxson <[email-masked]>
Date: Tue, 10 Nov 1998 10:27:23 PST

The -01 version of the TCP Congestion Control I-D has now come out.
Mark & I feel it's ready for publication as Proposed Standard, so we're
holding a two-week last call for final comments, with the last call ending
on Nov 24.

The main differences between this version and the -00 version are:

	- Changed acking-at-least-every-second-segment from a MUST to
	  a SHOULD.  This reflects the recent discussion on the mailing
	  list that presented arguments why it might indeed sometimes
	  make sense to generate ACKs at a lower rate.  Added a strong
	  caution that this should not be done lightly.

	- Clarified that the receiver doesn't know the true MSS and
	  so the ack-at-least-every-second-full-MSS-segment requirement
	  means in terms of its offered MSS.

	- Added that a TCP receiver SHOULD generate an immediate ACK
	  when an incoming segment fills a gap in the sequence space.
	  This reflects the recent discussion of how failure to do so
	  can lead to miserable performance.

	- Added discussion of "FlightSize", the amount of outstanding
	  data at the time of a loss.  On loss, ssthresh is set to
	  FlightSize/2 (or 2*MSS, whichever's larger).  This used
	  to be "min(cwnd,rwnd)" but it was pointed out that you might
	  have less data in flight than either of those.

	- Removed proposed algorithm for recovering from multiple losses
	  in a single flight, and replaced it with a general discussion
	  of congestion control requirements for loss recovery mechanisms.

	- Added a pointer to draft-ietf-tcpimpl-newreno-00.txt as one
	  example of Reno modifications for dealing with recovering from
	  multiple losses.  This I-D has been sent to the Internet Drafts
	  editor and should be posted shortly.

The next message are context diffs between -00 and -01.

		Vern

ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpimpl-cong-control-01.txt

---

From: "Kevin M. Lahey" <[email-masked]>
Date: Tue, 10 Nov 1998 11:31:05 -0800

In message <[email-masked]>Vern Paxson writes

>	  means in terms of its offered MSS.

Is there any way that we can tweak MSS to take path MTU discovery into
account?  It seems like the current definition would result in an
unnaturally small number of ACKs on a path with a smaller discovered
MTU.  For instance, if two ATM-equipped hosts wind up communicating
across an Ethernet, won't we wind up with only a quarter as many ACKs
as we'd get without PMTU?

Since increases in slow-start are defined in terms of MSS rather than
the number of segments, I guess the PMTU-equipped stacks wouldn't
pay a penalty versus non-PMTU-equipped stacks, but wouldn't they
be dumping large numbers of packets into the network?  Wouldn't
it be smoother to have more frequent ACKs?

I guess implementations are free to send more frequent ACKs to 
avoid this, and PMTU-equipped stacks could just be smarter about it.
Could this result in an unnaturally fast increase in the congestion
window when the receiver ACKed every two packets (not every two 
MSS-sized packets) and the sender always increased by MSS (not
the appropriate PMTU)?

Thanks,

Kevin
[email-masked]