|
|
Danny McPherson wrote:
>
> On Jun 21, 2006, at 8:28 AM, David Borman wrote:
>>
>> Huh? Section 4.2.2.6 of RFC 1122 is very explicit about how to calculate
>> Eff.snd.MSS, there is no ambiguity there. You adjust down to account for
>> any IP and TCP options.
>>
>> The value to put into the TCP MSS option is:
>> MMS_R - 20 (section 4.2.2.6)
>> MMS_R = EMTU_R - 20 (section 3.3.2)
>> So, that's EMTU_R - 40; 20 bytes for the fixed TCP header, 20 bytes for
>> the fixed IP header.
>
> I feel like we're going in circles here, perhaps my wording was a
> bit loose. What I meant was that the confusion surrounding this
> whole issue is simply because:
>
> o there are implementations that calculate options into
> the advertised MSS (because of inconsistencies that
> documents like RFC 2385 introduce)
This was addressed in RFC2525 - which came 8 months later. 2385 is
already somewhat in flux; we can address than in one of the updates
(i.e., correct the erroneous text).
The rest seems to be based solely on 2385. Let's just fix that (which we
have three proposals for anyway)...
> o and implicitly, as a result, implementations that expect the
> remote host to include options in the MSS it advertised
>
> o and therefore, said implementation does not comply with
> RFC 1122s Eff.snd.MSS algorithm by factoring options on
> a per-segment basis when sending
>
> o and if the two TCPs don't agree on this (which is what we're
> experiencing) then there's some probability you run into
> brokenness.
Joe
_______________________________________________
tcpm mailing list
tcpm@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/tcpm
|
|