On Jun 19, 2006, at 2:16 PM, Kevin Lahey wrote:
On Fri, 16 Jun 2006 11:10:02 -0600
Danny McPherson <danny@xxxxxxx> wrote:
Is there a _definitive source for how the Eff.snd.MSS value should
be calculated when TCP Options are employed, and precisely what
should be contained in an advertised MSS wrt TCP Options?
It seems to me an ambiguity arises from the fact that some
deployed implementations subtract the size of the TCP options in
the MSS value they advertise, AND they implicitly expect the
senders to do the same (e.g., as specified in RFC 2385 and RFC
2581). Therefore they do NOT dynamically calculate the
Eff.snd.MSS to include options when sending a TCP segment.
Section 2.18 of RFC2525 discusses exactly this issue, not that I'd
call that a definitive answer.[*]
Yep, I think I cited this in an email in an earlier thread.
If we're to take TCP options into account when calculating the MSS
option, what do we do about negotiated options like timestamps?
we not take them into account when sending the first SYN, but take
into account when acknowledging a SYN (when we know that both sides
support them)? It seems that way lies madness.
I agree, hence my opinion is that options should NOT be included in
the advertised MSS and should always be calculated per-segment
when sending (Eff.snd.MSS), and both sending and receiving TCP
MUST be aware of this.
Perhaps an I-D specifying this behavior more explicitly is in order?
tcpm mailing list