Re: [tcpm] Definition of SMSS/RMSS in RFC5681 are inaccurate?!

[Yuchung Cheng <[e-mail]>]

How about rename "Sender Maximum Segment Size" to "Sender Maximum
Payload Size"? It's headache to me and perhaps other developers that
SMSS and RMSS include different parts of the segment.  In addition,
if RFC1122's definition of TCP segment includes fixed headers and
options, shouldn't "maximum segment size" literally include both as
well?

Yuchung


On Mon, Jul 26, 2010 at 8:15 PM, Alexander Zimmermann
<[e-mail]> wrote:
> Hi Joe,
>
> maybe a stupid question but why do we write in both cases (SMSS/RMSS) "is the size of the
> largest segment"? According RFC1122 (page 19), a TCP segment is data structure that
> include the TCP header. And than later on in the definition "The size does not include the
> header". These gives IMO really room for interpretation...
>
> Why do we not write in both cases something like "is the size of the
> largest TCP payload".
>
> Alex
>
>
> Am 26.07.2010 um 19:45 schrieb Joe Touch:
>
>> Hi, all,
>>
>> On 7/26/2010 10:06 AM, Ethan Blanton wrote:
>>> Alexander Zimmermann spake unto us the following wisdom:
>>>>> Yes, RFC5681 is correct,
>>>>
>>>> Sorry, but I disagree. I cite the sentence in question again:
>>>>
>>>> "The size does not include the TCP/IP headers and options."
>>>>
>>>> The "and" in the sentence is IMO wrong or at least very very misleading.
>>>> Either we write: "The size does include ONLY the fixed TCP/IP headers."
>>>> or we write "The size does not include the TCP/IP options"
>>>
>>> I believe (as one of the authors) that 5681 is correct.  Neither the
>>> fixed TCP header size nor the option space are included in this
>>> calculation for the purposes of 5681.
>>
>> draft-ietf-tcpm-tcpmss states that the MSS option includes the fixed TCP and IP headers and NOT the options.
>>
>> I think Alex did find a bug here (I had commented on his misquoted earlier post), as per below... it's not in BOTH descriptions, though.
>>
>> In 5681, RMSS is in error as follows:
>>
>>   RECEIVER MAXIMUM SEGMENT SIZE (RMSS): The RMSS is the size of the
>>      largest segment the receiver is willing to accept.  This is the
>>      value specified in the MSS option sent by the receiver during
>>      connection startup.  Or, if the MSS option is not used, it is 536
>>      bytes [RFC1122].  The size does not include the TCP/IP headers and
>>      options.
>>
>> If RMSS is ever the value in the MSS option, it would include the fixed headers but not the options.
>>
>> > It is concerned only with data
>>> bytes sent in-band.  If SMSS is used differently elsewhere, that is
>>> unfortunate, but it does not affect the definition within 5681.
>>
>> Only RMSS is in error; as you note, SMSS is correct.
>> 5681 says SMSS is based on RMSS (where "based on" isn't explained):
>>
>>   SENDER MAXIMUM SEGMENT SIZE (SMSS): The SMSS is the size of the
>>      largest segment that the sender can transmit.  This value can be
>>      based on the maximum transmission unit of the network, the path
>>      MTU discovery [RFC1191, RFC4821] algorithm, RMSS (see next item),
>>      or other factors.  The size does not include the TCP/IP headers
>>      and options.
>>
>> SMSS clearly must omit all TCP and IP headers, because it is the value that updates cwnd.
>>
>> So, IMO, yes, there's a bug, but it's in RMSS's description. There may be a useful clarification that defines SMSS in terms of RMSS explicitly as well.
>>
>> Joe
>>
>>
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>
>