Subject: [tcpm] 793bis: add SHOULD on other common options

From: Wesley Eddy <[email-masked]>
Date: Wed, 9 Dec 2020 22:44:46 -0500

There's been a suggestion that we make a stronger statement on support 
for the common (but not required) options like SACK, Timestamp, and 
Window Scaling.

Current text just indicates that these are recommended:

         Other Common Options

         Additional RFCs define some other commonly used options that are
         recommended to implement.  These are the TCP Selective
         Acknowledgement (SACK) option [18  <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-19#ref-18>][21], TCP Timestamp (TS)
         option [43  <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-19#ref-43>], and TCP Window Scaling (WS) option [43  <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-19#ref-43>].

I don't have any issues with appending a stronger statement something like:

    TCP implementations SHOULD support these options.

Would that suffice?  Are there objections or other suggestions on what 
exactly to say?

---

From: Neal Cardwell <[email-masked]>
Date: Wed, 9 Dec 2020 23:12:12 -0500

On Wed, Dec 9, 2020 at 10:45 PM Wesley Eddy <[email-masked]> wrote:
>
> There's been a suggestion that we make a stronger statement on support for the common (but not required) options like SACK, Timestamp, and Window Scaling.
>
>         Acknowledgement (SACK) option [18][21], TCP Timestamp (TS)
>         option [43], and TCP Window Scaling (WS) option [43].
>
> Would that suffice?  Are there objections or other suggestions on what exactly to say?

All of those options are hugely valuable, so I would strongly support
listing these options with a "SHOULD" or "RECOMMENDED". My reading of
https://tools.ietf.org/html/rfc2119  is that "SHOULD" and
"RECOMMENDED" are synonyms, in which case the "recommended" in that
paragraph could perhaps just be changed to be an all-caps
"RECOMMENDED".

best,
neal

---

From: Ian Swett <[email-masked]>
Date: Thu, 10 Dec 2020 07:49:46 -0500

I agree with Neal that these should be RECOMMENDED.

On Wed, Dec 9, 2020 at 11:12 PM Neal Cardwell <ncardwell=
[email-masked]> wrote:

> for the common (but not required) options like SACK, Timestamp, and Window
> Scaling.
> >
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Joseph Touch <[email-masked]>
Date: Thu, 10 Dec 2020 08:00:00 -0800

First, can we please NOT open the floodgates to “let’s see how we can change TCP today”.

That wasn’t the point of this update.

Second, the doc (and all docs) should scrub all uses of SHOULD to ensure that conditions for exceptions are indicated. I.e., SHOULD except where…. Otherwise, we’re tilting the odds (vs MAY or MUST) in a way that becomes merely an opening for the loudest advocates, which doesn’t help anyone.

Finally, on this one in particular, NO.

Again, we aren’t opening the floodgates to reconsidering TCP’s design. If the case hasn’t already been made in a draft in detail, we should NOT be considering the change at this point.

Further, these only “shoot you in the foot”, i.e., if you don’t implement them, you basically only hurt your own connections. So there’s already incentive for capable endpoints to implement them.

Nevermind the fact that this would severely impact IOT and other such uses, which I am surprised has not been considered.

Joe

> On Dec 9, 2020, at 7:44 PM, Wesley Eddy <[email-masked]> wrote:
>

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 10 Dec 2020 08:23:04 -0800

I agree with Neal and Ian that these features are highly useful for
TCP (performance). But I also agree adding new SHOULD/MUST/MAY after
the extensive WG reviews in the last minute is not a good idea. If
this new RFC is about the minimal requirement to implement TCP
correctly (but not necessarily performant in various networks), then
my vote is to keep as-is.

---

From: Praveen Balasubramanian <[email-masked]>
Date: Thu, 10 Dec 2020 17:50:01 +0000

IOT is a good point. Since this was part of my review comments I am convinced that we do not need to make these a SHOULD requirement. MAY implement for performance will suffice. 

-----Original Message-----
From: tcpm <[email-masked]> On Behalf Of Yuchung Cheng
Sent: Thursday, December 10, 2020 8:23 AM
To: Joseph Touch <[email-masked]>
Cc: tcpm IETF list <[email-masked]>
Subject: [EXTERNAL] Re: [tcpm] 793bis: add SHOULD on other common options

I agree with Neal and Ian that these features are highly useful for TCP (performance). But I also agree adding new SHOULD/MUST/MAY after the extensive WG reviews in the last minute is not a good idea. If this new RFC is about the minimal requirement to implement TCP correctly (but not necessarily performant in various networks), then my vote is to keep as-is.

On Thu, Dec 10, 2020 at 8:00 AM Joseph Touch <[email-masked]> wrote:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=04%7C01%7Cpravb%40micros
> oft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd
> 011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;s
> data=dnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&amp;reserved=0
>
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=04%7C01%7Cpravb%40micros
> oft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd
> 011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;s
> data=dnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&amp;reserved=0

_______________________________________________
tcpm mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=04%7C01%7Cpravb%40microsoft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=dnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&amp;reserved=0

---

From: Neal Cardwell <[email-masked]>
Date: Thu, 10 Dec 2020 23:32:03 -0500

To help address the IOT case, along the lines of Joe's "conditions for
exceptions are indicated. I.e., SHOULD except where…." remarks, one
option would be to say that "These options are helpful for high
performance and SHOULD be implemented except where resource
constraints make this infeasible (e.g. constrained-node network
devices with CPU or memory limits)."

neal

---

From: Joseph Touch <[email-masked]>
Date: Thu, 10 Dec 2020 21:16:59 -0800

I agree that it’s useful to suggest them for high performance, but disagree with adding a new SHOULD.

Again, we’re not here to open new issues - and more to the point, these were updated in 2014 and no SHOULD was added at that time:

   Finally, we observe that most of the mechanisms defined in this
   document are important for LFNs and/or very high-speed networks.  For
   low-speed networks, it might be a performance optimization to NOT use
   these mechanisms.  A TCP vendor concerned about optimal performance
   over low-speed paths might consider turning these extensions off for
   low-speed paths, or allow a user or installation manager to disable
   them.

Joe

> On Dec 10, 2020, at 8:32 PM, Neal Cardwell <ncardwell=[email-masked]> wrote:
>

---

From: Ian Swett <[email-masked]>
Date: Fri, 11 Dec 2020 11:56:15 -0500

In my opinion, we already have an issue, because a non-normative
'recommended' is used.  A reasonable reading is this was intended as the
normative RECOMMENDED, but no one ever bothered to capitalize it, but it
seems there's some disagreement on whether that was the case.

If you're not going to make it normative, I'd suggest you choose a
different word than recommended or remove the last part of the sentence.

As stated before, I'd suggest you capitalize it and make it normative.

On Fri, Dec 11, 2020 at 12:17 AM Joseph Touch <[email-masked]> wrote:

> Again, we’re not here to open new issues - and more to the point, these
> were updated in 2014 and no SHOULD was added at that time:
>
> On Dec 10, 2020, at 8:32 PM, Neal Cardwell <
> ncardwell=[email-masked]> wrote:
>
> IOT is a good point. Since this was part of my review comments I am
> convinced that we do not need to make these a SHOULD requirement. MAY
> implement for performance will suffice.
>
> I agree with Neal and Ian that these features are highly useful for TCP
> (performance). But I also agree adding new SHOULD/MUST/MAY after the
> extensive WG reviews in the last minute is not a good idea. If this new RFC
> is about the minimal requirement to implement TCP correctly (but not
> necessarily performant in various networks), then my vote is to keep as-is.
>
>
> Second, the doc (and all docs) should scrub all uses of SHOULD to ensure
> that conditions for exceptions are indicated. I.e., SHOULD except where….
> Otherwise, we’re tilting the odds (vs MAY or MUST) in a way that becomes
> merely an opening for the loudest advocates, which doesn’t help anyone.
>
> Again, we aren’t opening the floodgates to reconsidering TCP’s design. If
> the case hasn’t already been made in a draft in detail, we should NOT be
> considering the change at this point.
>
> Further, these only “shoot you in the foot”, i.e., if you don’t implement
> them, you basically only hurt your own connections. So there’s already
> incentive for capable endpoints to implement them.
>
> Nevermind the fact that this would severely impact IOT and other such
> uses, which I am surprised has not been considered.
>
> Joe
>
> There's been a suggestion that we make a stronger statement on support for
> the common (but not required) options like SACK, Timestamp, and Window
> Scaling.
>

---

From: Joseph Touch <[email-masked]>
Date: Fri, 11 Dec 2020 09:51:50 -0800

> On Dec 11, 2020, at 8:56 AM, Ian Swett <ianswett=[email-masked]> wrote:
> 
> In my opinion, we already have an issue, because a non-normative 'recommended' is used.  A reasonable reading is this was intended as the normative RECOMMENDED, but no one ever bothered to capitalize it, but it seems there's some disagreement on whether that was the case.

Except that this RFC actually already includes the following *explicit* language:

   In this document, these words will appear with that interpretation
   only when in UPPER CASE.  Lower case uses of these words are not to
   be interpreted as carrying [RFC2119 <https://tools.ietf.org/html/rfc2119>] significance.

> If you're not going to make it normative, I'd suggest you choose a different word than recommended or remove the last part of the sentence.

Absolutely.

> As stated before, I'd suggest you capitalize it and make it normative.

Again, no, as per above.

Joe

> 
> On Fri, Dec 11, 2020 at 12:17 AM Joseph Touch <[email-masked] <mailto:[email-masked]>> wrote:
>> On Dec 10, 2020, at 8:32 PM, Neal Cardwell <ncardwell=[email-masked] <mailto:ncardwell=[email-masked]>> wrote:
>> 
>> <pravb=[email-masked] <mailto:pravb=[email-masked]>> wrote:
>>> 
>>> From: tcpm <[email-masked] <mailto:[email-masked]>> On Behalf Of Yuchung Cheng
>>> To: Joseph Touch <[email-masked] <mailto:[email-masked]>>
>>> Cc: tcpm IETF list <[email-masked] <mailto:[email-masked]>>
>>> On Thu, Dec 10, 2020 at 8:00 AM Joseph Touch <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> On Dec 9, 2020, at 7:44 PM, Wesley Eddy <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> [email-masked] <mailto:[email-masked]>
>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww>.
>>>> ietf.org <http://ietf.org/>%2Fmailman%2Flistinfo%2Ftcpm&amp;data=04%7C01%7Cpravb%40micros
>>>> oft.com <http://oft.com/>%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd
>>>> [email-masked] <mailto:[email-masked]>
>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww>.
>>>> ietf.org <http://ietf.org/>%2Fmailman%2Flistinfo%2Ftcpm&amp;data=04%7C01%7Cpravb%40micros
>>>> oft.com <http://oft.com/>%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd
>>> [email-masked] <mailto:[email-masked]>
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=04%7C01%7Cpravb%40microsoft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=dnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&amp;reserved=0 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=04%7C01%7Cpravb%40microsoft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=dnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&amp;reserved=0>
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>

---

From: Ian Swett <[email-masked]>
Date: Fri, 11 Dec 2020 14:25:09 -0500

On Fri, Dec 11, 2020 at 12:52 PM Joseph Touch <[email-masked]> wrote:

>
>
> On Dec 11, 2020, at 8:56 AM, Ian Swett <
> ianswett=[email-masked]> wrote:
>
Ok, well that's unusual.

> As stated before, I'd suggest you capitalize it and make it normative.

Fair

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 17 Dec 2020 08:08:56 -0500

On 12/11/2020 2:25 PM, Ian Swett wrote:
>
> On Fri, Dec 11, 2020 at 12:52 PM Joseph Touch <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>>     On Dec 11, 2020, at 8:56 AM, Ian Swett
>>     <ianswett=[email-masked]
>>     <mailto:ianswett=[email-masked]>> wrote:
>>
>>     'recommended' is used.  A reasonable reading is this was intended
>>     as the normative RECOMMENDED, but no one ever bothered to
>>     capitalize it, but it seems there's some disagreement on whether
>>     that was the case.
>

I don't know where you're seeing that text exactly.  The current 793bis 
draft has the BCP 14 boilerplate text, just like most other IETF documents.

---

From: Joseph Touch <[email-masked]>
Date: Thu, 17 Dec 2020 08:27:41 -0800

> On Dec 17, 2020, at 5:08 AM, Wesley Eddy <[email-masked]> wrote:
> 
>> On Fri, Dec 11, 2020 at 12:52 PM Joseph Touch <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>> On Dec 11, 2020, at 8:56 AM, Ian Swett <ianswett=[email-masked] <mailto:ianswett=[email-masked]>> wrote:
>>> 
> I don't know where you're seeing that text exactly.  The current 793bis draft has the BCP 14 boilerplate text, just like most other IETF documents.

Not 793bis.

We had been talking about the source of these common options - RFC7323.

That doc uses “recommended” but explicitly differentiates that from “RECOMMENDED”.

Joe