Subject: Re: Last Call for TCP Congestion Control I-D

From: Vern Paxson <[email-masked]>
Date: Tue, 10 Nov 1998 12:52:34 PST

> 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.

Note that the current definition is for the *upper bound* on how often
a TCP acks.  A TCP can certainly ack more often, and in particular if
it has a different notion of the sender's MSS, that's fine, as long as
it's less than the original MSS it told the sender.  We're not trying to
*change* how (most) current TCPs ack, just clarify the requirement in
the spec.

> 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?

They will be dumping the same number of packets.  The packets may be
larger or smaller, depending on the path MTU.  We hope that they are
larger.  This is overall a Good Thing, we want to encourage use of
the largest non-fragmenting segment size.

> I guess implementations are free to send more frequent ACKs to 
> avoid this ...

Right, per the above.

> 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)?

MSS for the sender means the maximum segment size it's using to send,
and includes whatever modifications it's made to its original size
based on PMTU discovery.

Hmmmm, it looks like this is the key point that you're stressing.
We need to add this to the definition of MSS.

		Vern

---

From: "Kevin M. Lahey" <[email-masked]>
Date: Tue, 10 Nov 1998 13:52:34 -0800

In message <[email-masked]>Vern Paxson writes
>the largest non-fragmenting segment size.

My worry here is that we could see a sender that does path MTU
discovery and a naive receiver that does not.  Say the MSS is four
times the PMTU.  The receiver will ACK after receiving 2 * MSS bytes,
but this'll have been perhaps 8 segments.

The sender will get the ACK, and increase the congestion window by MSS,
resulting in 4 new segments, plus the 8 segments acknowledged, for a
total of 12 new segments.  Ouch!

OTOH, if the sender only increases the congestion window by the PMTU
value (rather than MSS), then its slow-start would be really slow when
coupled with the reduced number of ACKs...

>We're not trying to *change* how (most) current TCPs ack, just clarify
>the requirement in the spec.

Ouch, that's where I'm obviously slipping up.  I'd sure like to see
these standards updated a bit to take PMTU and other advances into
account, but I guess we're pretty much just trying to get folks to get
the original stuff right...

Naively,

Kevin 
[email-masked]