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

[Carles Gomez Montenegro <[e-mail]>]

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

Please find below our inline responses:

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

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.


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Please address the tsv review comments.

Revision -12 intends to 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

Done.

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

We added text as per your comment above.

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

Done.

Thanks,

Carles (on behalf of the authors)