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

[Joe Touch <[e-mail]>]

Hi, Yuchung,

On 7/26/2010 2:53 PM, Yuchung Cheng wrote:
> How about rename "Sender Maximum Segment Size" to "Sender Maximum
> Payload Size"?

Some of these names have been around a while, and such a change would 
require updating a large number of documents.

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

Largely because options vary during a connection, and so it's not a 
stable value to refer to.

It's probably sufficient just to be clear about what these terms mean 
and how they're related.

Joe

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