Subject: [Lwip] Martin Duke's Discuss on draft-ietf-lwig-tcp-constrained-node-networks-11: (with DISCUSS and COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Mon, 19 Oct 2020 14:52:06 -0700

Martin Duke has entered the following ballot position for
draft-ietf-lwig-tcp-constrained-node-networks-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

In Sec 4.1.1:

   An IPv6 datagram size exceeding 1280 bytes can be avoided by setting
   the TCP MSS not larger than 1220 bytes.  This assumes that the remote
   sender will use no TCP options, aside from possibly the MSS option,
   which is only used in the initial TCP SYN packet.

   In order to accommodate unrequested TCP options that may be used by
   some TCP implementations, a constrained device may advertise an MSS
   smaller than 1220 bytes (e.g. not larger than 1200 bytes).  Note that
   it is advised for TCP implementations to consume payload space
   instead of increasing datagram size when including IP or TCP options
   in an IP packet to be sent [RFC6691].  Therefore, the suggestion of
   advertising an MSS smaller than 1220 bytes is likely to be
   overcautious and its suitability should be considered carefully.

I would delete everything after the first sentence in this excerpt. While
RFC6691 is informational, it clarifies RFC1122, which is a standard, and
Sec 4.2.2.6 is quite clear that senders MUST consider TCP and IP option
length when sizing TCP payloads.

Absent any evidence that there are TCP endpoints or middleboxes that are
violating RFC1122, further reducing the MSS because someone might be
violating it is excessive.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please address the tsv review comments.

Sec 4.2.3
 s/Disabling Delayed ACKs at the
   sender allows an immediate ACK/Disabling Delayed ACKs at the
   request sender allows an immediate ACK

Sec 4.3.1
   When a multiple-segment window is used, the receiver will need to
   manage the reception of possible out-of-order received segments,
   requiring sufficient buffer space.

It's worth pointing out here that even a 1 MSS window should also manage
out-of-order arrival, as the sender may send multiple sub-MSS packets that fit
in the window. (On the other hand, the receiver is free to simply drop the
out-of-order segment, thus forcing a retransmission).

Sec 4.3.3.1
s/since with SACK recovery/since SACK recovery

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 30 Oct 2020 08:46:45 +0100

Hi Martin,

Thank you very much for your review and feedback!

We just submitted revision -12, which aims at addressing the comments
received from the IESG and related reviewers:
https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-12

> https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/

As per the subsequent discussion in tcpm, we replaced the above text by
the following:

NEW:
   An IPv6 datagram size exceeding 1280 bytes can be avoided by setting
   the TCP MSS not larger than 1220 bytes.  Note that it is already a
   requirement that TCP implementations consume payload space instead of
   increasing datagram size when including IP or TCP options in an IP packet
   to be sent [RFC6691].  Therefore, it is not required to advertise an MSS
   smaller than 1220 bytes in order to accommodate TCP options.

Revision -12 intends to address the tsv review comments.

>    request sender allows an immediate ACK

Done.

> out-of-order segment, thus forcing a retransmission).

We added text as per your comment above.

> s/since with SACK recovery/since SACK recovery

Done.

Thanks,

Carles (on behalf of the authors)