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

From: Alexander Zimmermann <[email-masked]>
Date: Mon, 26 Jul 2010 14:33:26 +0200

Dear WG,

while writing some definitions for my thesis, I stumble on the definition
of SMSS/RMSS in RFC5681:

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.

The size does not include the TCP/IP headers and options. This is wrong!
The options are the TCP/IP headers.

BTW: "to include" is in this context very misleading!

David you can update RFC5681 with your darft draft-ietf-tcpm-tcpmss too :-)

Alex

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Mon, 26 Jul 2010 17:43:49 +0200

> The options are the TCP/IP headers.

Strange that nobody spotted this. "The options are the TCP/IP headers",
what does this mean? draft-ietf-tcpm-tcpmss-03 should be mentioned instead:

   The MSS value to be sent in an MSS option should be equal to the
   effective MTU minus the fixed IP and TCP headers.

Hagen

---

From: Alexander Zimmermann <[email-masked]>
Date: Mon, 26 Jul 2010 17:55:34 +0200

Hi Hagen,

Am 26.07.2010 um 17:43 schrieb Hagen Paul Pfeifer:

> what does this mean?

Nothing :-)

I was too quick. Copy & Paste inattention.
I wanted to write: The size does not include the TCP/IP options.

Alex

> draft-ietf-tcpm-tcpmss-03 should be mentioned instead:
> 
> 
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Jul 2010 08:58:09 -0700

Hi, all,

>     effective MTU minus the fixed IP and TCP headers.

Some of us just spotted this, and you just typed faster than we did ;-)

Yes, RFC5681 is correct, and draft-ietf-tcpm-tcpmss intends to update 
RFC879 and RFC2385.

Note that RFC2385 is already obsoleted by RFC5925, which states:

    Please note that the use of TCP-AO does not affect TCP's advertised
    maximum segment size (MSS), as is the case for all TCP options
    [Bo09].

This statement is consistent with draft-ietf-tcpm-tcpmss, FWIW.

(Dave - does this mean that draft-ietf-tcpm-tcpmssSec 3.2 might include 
a note that it updates 2385 even though 2385 is obsoleted...?)

Joe

---

From: Alexander Zimmermann <[email-masked]>
Date: Mon, 26 Jul 2010 18:36:09 +0200

Hi Joe,

Am 26.07.2010 um 17:58 schrieb Joe Touch:

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

Alex

> and draft-ietf-tcpm-tcpmss intends to update RFC879 and RFC2385.
> 
> (Dave - does this mean that draft-ietf-tcpm-tcpmssSec 3.2 might include a note that it updates 2385 even though 2385 is obsoleted...?)
> 
> Joe

---

From: Ethan Blanton <[email-masked]>
Date: Mon, 26 Jul 2010 13:06:46 -0400

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

Perhaps "The size does not include the TCP/IP headers, including
options" or "The size does not include the fixed TCP/IP headers or
options" would be better wordings, but I do not believe the wording as
published is incorrect or unduly misleading.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Jul 2010 10:45:20 -0700

Hi, all,

On 7/26/2010 10:06 AM, Ethan Blanton wrote:
> 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

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

---

From: Alexander Zimmermann <[email-masked]>
Date: Mon, 26 Jul 2010 20:15:49 +0200

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:

> 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.
> 
> If RMSS is ever the value in the MSS option, it would include the fixed headers but not the 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
> 
>

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 26 Jul 2010 23:53:06 +0200

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
<[email-masked]> wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>
>

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Tue, 27 Jul 2010 00:11:25 +0200

>options, shouldn't "maximum segment size" literally include both as

Well, for me the term Maximum Segment Size provides more then the actual
"Maximum Payload Size". Every time I read "MSS" it provides for me an context,
I instantly know the TCP context and so on. "Sender Maximum Payload Size" is
similar error prone: depending on what layer you are working on, you will
interpret "payload" differently.

If the term "Maximum Segment Size" is formal defined everything is fine.

Hagen

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Jul 2010 01:10:15 -0700

Hi, Yuchung,

On 7/26/2010 2:53 PM, Yuchung Cheng wrote:
> 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

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Jul 2010 01:13:31 -0700

Hi, Alex,

> header". These gives IMO really room for interpretation...

That's the purpose of Dave Borman's I-D, FWIW - to remove that room ;-)

> Why do we not write in both cases something like "is the size of the

TCP terminology has been around for a long time. Changing any one name 
causes a ripple effect that requires updating a large number of 
documents. It ought to cause less confusion at this point to just 
explain what each of these sizes means and how they are related to each 
other.

Joe

---

From: Alexander Zimmermann <[email-masked]>
Date: Tue, 27 Jul 2010 10:53:46 +0200

Hi Joe,

Am 27.07.2010 um 10:13 schrieb Joe Touch:

> TCP terminology has been around for a long time. Changing any one name causes a ripple effect that requires updating a large number of documents. It ought to cause less confusion at this point to just explain what each of these sizes means and how they are related to each other.
> 

I don't want to change the term (as Yuchung suggests), my intention was to change
the explanation of the term. What's about the following:

  SENDER MAXIMUM SEGMENT SIZE (SMSS): The SMSS is the largest amount
     of data, specified in bytes, that a TCP sender is willing to
     send in a single segment.  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.

After one night to have time to thing about it, I think one root of my
confusion is the verb "include" in the definition. If we take RFC5681
as a standalone document, then, maybe, the definition of SMSS is OK. But
if I take RFC5681 and Daves I-D side by side, the confusion (at least
mine) grows...

In Daves I-D it says on page 4:

"It follows then, that since the sender will be adjusting the TCP data
length when sending IP and TCP options, there is no need to include the
IP and TCP option lengths in the MSS value."

According to my understanding the I-D said implicitly that on the other
hand the fixed header parts are included. Right? To my understanding the
verb "include" refers here to the calculation of the value and not to the
value itself. In RFC5681 the verb refers then to the final value.

Maybe RFC5681 is fine and the wording in the I-D is misleading...

Alex