Re: [Lwip] Benjamin Kaduk's No Objection on draft-ietf-lwig-tcp-constrained-node-networks-11: (with COMMENT)
Hi Carles, Thank you for the updates; they look good and I have no further comments. -Ben On Fri, Oct 30, 2020 at 09:38:38AM +0100, Carles Gomez Montenegro wrote: > Hi Benjamin, > > Thank you very much for your review! > > 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: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-lwig-tcp-constrained-node-networks-11: No Objection > > > > 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/ > > > > > > > > -- > > COMMENT: > > -- > > > > Mostly just editorial nits, but please see the comment on Section 5.3. > > > > Section 2 > > > > (I believe the existence of the RFC 8174 version of the BCP 14 > > boilerplate has already been noted.) > > Thanks. In fact, since the document does not use normative language, we > removed Section 2 in the last document revision. > > > Section 3.2 > > > >or devices with a pool of multiple send/receive buffers. In the > >latter case, it is possible that buffers also be shared for other > >protocols. > > > > nit: s/be/are/ (or any number of other minor tweaks) > > Done. > > >One key use case for the use of TCP in CNNs is a model where > > > > nit: "use case for the use" is probably redundant: "use case for TCP in > > CNNs" seems like it would work okay. > > Done, thanks. > > >middlebox (e.g. a firewall, NAT, etc.). Figure 1 illustrates such > >scenario. Note that the scenario is asymmetric, as the unconstrained > > > > nit: "such a scenario". > > Done. > > > Section 3.3 > > > >o Unidirectional transfers: An IoT device (e.g. a sensor) can send > > (repeatedly) updates to the other endpoint. Not in every case > > there is a need for an application response back to the IoT > > device. > > > > (editorial) I suggest "There is not always a need for an application > > response back to the IoT device". > > Done. > > > Section 4.1.1 > > > >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 > > > > [my reading of RFC 6691 is that it was required to consume payload > > space, but only recommended to account for this behavior when > > advertising MSS. I guess Erik covered this in his Discuss point already, > > though.] > > As per a subsequent discussion on the tcpm mailing list, we updated the > second paragraph of current Section 3.1.1 is as follows: > > 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. > > > Section 5.3 > > > >The message and latency overhead that stems from using a sequence of > >short-lived connections could be reduced by TCP Fast Open (TFO) > >[RFC7413], which is an experimental TCP extension, at the expense of > >increased implementation complexity and increased TCP Control Block > >(TCB) size. TFO allows data to be carried in SYN (and SYN-ACK) > > > > We should probably make at least a passing mention of the TFO security > > considerations here, possibly with some discussion of why they are less > > consequential for certain CNNs than in general. (Note that the security > > considerations for TFO are not limited to just the risk of replay, and > > that there are privacy considerations for the TFO cookie being used to > > link together multiple TCP connections between the same endpoints.) > > We made the following change: > > OLD: >The cookie needs to be refreshed (and obtained by the client) after a >certain amount of time. Nevertheless, TFO is more efficient than >frequently opening new TCP connections with the traditional three-way >handshake, as long as the cookie can be reused in
Re: [Lwip] Benjamin Kaduk's No Objection on draft-ietf-lwig-tcp-constrained-node-networks-11: (with COMMENT)
Hi Benjamin, Thank you very much for your review! 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: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-lwig-tcp-constrained-node-networks-11: No Objection > > 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/ > > > > -- > COMMENT: > -- > > Mostly just editorial nits, but please see the comment on Section 5.3. > > Section 2 > > (I believe the existence of the RFC 8174 version of the BCP 14 > boilerplate has already been noted.) Thanks. In fact, since the document does not use normative language, we removed Section 2 in the last document revision. > Section 3.2 > >or devices with a pool of multiple send/receive buffers. In the >latter case, it is possible that buffers also be shared for other >protocols. > > nit: s/be/are/ (or any number of other minor tweaks) Done. >One key use case for the use of TCP in CNNs is a model where > > nit: "use case for the use" is probably redundant: "use case for TCP in > CNNs" seems like it would work okay. Done, thanks. >middlebox (e.g. a firewall, NAT, etc.). Figure 1 illustrates such >scenario. Note that the scenario is asymmetric, as the unconstrained > > nit: "such a scenario". Done. > Section 3.3 > >o Unidirectional transfers: An IoT device (e.g. a sensor) can send > (repeatedly) updates to the other endpoint. Not in every case > there is a need for an application response back to the IoT > device. > > (editorial) I suggest "There is not always a need for an application > response back to the IoT device". Done. > Section 4.1.1 > >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 > > [my reading of RFC 6691 is that it was required to consume payload > space, but only recommended to account for this behavior when > advertising MSS. I guess Erik covered this in his Discuss point already, > though.] As per a subsequent discussion on the tcpm mailing list, we updated the second paragraph of current Section 3.1.1 is as follows: 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. > Section 5.3 > >The message and latency overhead that stems from using a sequence of >short-lived connections could be reduced by TCP Fast Open (TFO) >[RFC7413], which is an experimental TCP extension, at the expense of >increased implementation complexity and increased TCP Control Block >(TCB) size. TFO allows data to be carried in SYN (and SYN-ACK) > > We should probably make at least a passing mention of the TFO security > considerations here, possibly with some discussion of why they are less > consequential for certain CNNs than in general. (Note that the security > considerations for TFO are not limited to just the risk of replay, and > that there are privacy considerations for the TFO cookie being used to > link together multiple TCP connections between the same endpoints.) We made the following change: OLD: The cookie needs to be refreshed (and obtained by the client) after a certain amount of time. Nevertheless, TFO is more efficient than frequently opening new TCP connections with the traditional three-way handshake, as long as the cookie can be reused in subsequent connections. NEW: The cookie needs to be refreshed (and obtained by the client) after a certain amount of time. While a given cookie is used for multiple connections between the same two endpoints, the latter may become vulnerable to privacy threats. In addition, a valid cookie may be stolen from a compromised host and may be used to perform SYN flood attacks, as well as
[Lwip] Benjamin Kaduk's No Objection on draft-ietf-lwig-tcp-constrained-node-networks-11: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-lwig-tcp-constrained-node-networks-11: No Objection 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/ -- COMMENT: -- Mostly just editorial nits, but please see the comment on Section 5.3. Section 2 (I believe the existence of the RFC 8174 version of the BCP 14 boilerplate has already been noted.) Section 3.2 or devices with a pool of multiple send/receive buffers. In the latter case, it is possible that buffers also be shared for other protocols. nit: s/be/are/ (or any number of other minor tweaks) One key use case for the use of TCP in CNNs is a model where nit: "use case for the use" is probably redundant: "use case for TCP in CNNs" seems like it would work okay. middlebox (e.g. a firewall, NAT, etc.). Figure 1 illustrates such scenario. Note that the scenario is asymmetric, as the unconstrained nit: "such a scenario". Section 3.3 o Unidirectional transfers: An IoT device (e.g. a sensor) can send (repeatedly) updates to the other endpoint. Not in every case there is a need for an application response back to the IoT device. (editorial) I suggest "There is not always a need for an application response back to the IoT device". Section 4.1.1 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 [my reading of RFC 6691 is that it was required to consume payload space, but only recommended to account for this behavior when advertising MSS. I guess Erik covered this in his Discuss point already, though.] Section 5.3 The message and latency overhead that stems from using a sequence of short-lived connections could be reduced by TCP Fast Open (TFO) [RFC7413], which is an experimental TCP extension, at the expense of increased implementation complexity and increased TCP Control Block (TCB) size. TFO allows data to be carried in SYN (and SYN-ACK) We should probably make at least a passing mention of the TFO security considerations here, possibly with some discussion of why they are less consequential for certain CNNs than in general. (Note that the security considerations for TFO are not limited to just the risk of replay, and that there are privacy considerations for the TFO cookie being used to link together multiple TCP connections between the same endpoints.) Section 10.1 RFC 3819 may not need to be listed as normative, given the nature of the one place in which it is referenced. Similarly, we don't say much about TCP-AP other than it exists, so RFC 5925 may not need to be normative either. Section 10.2 RFC 6092 appears to not be referenced from anywhere? idnits notes a couple other reference-related issues. ___ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
