[Lwip] Martin Duke's No Objection on draft-ietf-lwig-tcp-constrained-node-networks-13: (with COMMENT)

[Martin Duke via Datatracker]

Martin Duke has entered the following ballot position for
draft-ietf-lwig-tcp-constrained-node-networks-13: 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:
--

Thanks for addressing my DISCUSS.

Original comments, since resolved:

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



___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] [IPsec] Comments on draft-ietf-lwig-minimal-esp-00

[Tero Kivinen]

Daniel Migault writes:
> The security consideration has been updated as follows:
> 
> """
>   The security of a communication provided by ESP is closely related to
>    the security associated to the management of that key.  This usually
>    include mechanisms to prevent a nonce to repeat for example.  When a
>    node is provisioned with a session key that is used across reboot,
>    the implementer MUST ensure that the mechanisms put in place remain
>    valid across reboot as well.
> 
>    It is RECOMMENDED to use ESP in conjunction of key management
>    protocols such as for example IKEv2 [RFC7296] or minimal IKEv2
>    [RFC7815].  Such mechanisms are responsible to negotiate fresh
>    session keys as well as prevent a session key being use beyond its
>    life time.  When such mechanisms cannot be implemented and the
>    session key is, for example, provisioned, the nodes SHOULD ensure
>    that keys are not used beyond their life time and that the
>    appropriated use of the key remains across reboots.

Why the last sentence has SHOULD and not MUST? If device reuses the
key across reboots and the algorithm is counter mode based, this will
cause serious security issues. Also same thing happens if the counters
are allowed to roll over. I would suggest changing that "MUST ensure".

> The use of fix SPI MUST NOT be considered as a way to avoid strong random
> generators.  Such generator will be required in order to provide strong
> cryptographic protection”; actually, if the IPsec implementation doesn’t
> actually generate its own keys (that is, it relies on an external service
> to provide them), and the transform itself doesn’t require random data
> (CBC can be implemented securely without one), then the IPsec
> implementation doesn’t actually need an CSPRNG.
>
> 
> The current text presented it in another way. The former text seems to explain
> that random was necessary for the generation of SPI. The current text has been
> updated to explain that we may have nodes without random generators. 
> 
> I am wondering how the IV is generated with CBC without random generator. 

Normally you use just counter, and encrypt it with secret key. The IV
in CBC does not be random, it needs to be unpredictable and it should
not be direct counter or other source with low Hamming distance
between successive IVs.

Actually the problem with old way of CBC mode was that the IV was
random, but predictable as implementations used last block of previous
packet. If attacker does not know the key you are using to encrypt the
counter to generate IVs, the IVs will be unpredictable and random.
-- 
kivi...@iki.fi

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Barry Leiba's No Objection on draft-ietf-lwig-tcp-constrained-node-networks-11: (with COMMENT)

[Barry Leiba]

Thanks, Carles; I appreciate your addressing my comments.

Barry

On Fri, Oct 30, 2020 at 4:57 AM Carles Gomez Montenegro
 wrote:
>
> Hi Barry,
>
> Thank you very much for your review!
>
> We just submitted revisions -12 and -13, which aim at addressing the
> comments received from the IESG and related reviewers:
> https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-13
>
> Please find below our inline responses:
>
>
> > Barry Leiba 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:
> > --
> >
> > Thanks for a useful document.  I just have a few editorial things here:
> >
> > — Section 1 —
> >
> >However, TCP has been
> >criticized (often, unfairly) as a protocol for the IoT.  In fact,
> >some TCP features are not optimal for IoT scenarios, such as
> >relatively long header size, unsuitability for multicast, and always-
> >confirmed data delivery.  However, …
> >
> > Both of these sentences have nit-level problems that make them a bit off.
> > The
> > first sounds like the criticism is that TCP is a protocol for IoT (rather
> > than
> > that it’s not suitable for that usage).  The second has the examples
> > misplaced,
> > so it look as though they’re examples of IoT scenarios (rather than
> > examples of
> > TCP features).  And “in fact” has the wrong feel here: it would
> > normally be
> > used to contradict the previous sentence, not to explain it.  (And two
> > “however”s in close proximity also feels awkward)  I suggest this fix:
> >
> > NEW
> >TCP has been
> >criticized, often unfairly, as a protocol that’s unsuitable for the
> >IoT.  It is true that some TCP features, such as its relatively long
> >header size, unsuitability for multicast, and always-confirmed data
> >delivery, are not optimal for IoT scenarios.  However, …
>
> Thanks for your detailed explanation, and thanks also for your proposed
> new text, which definitely reads much better. We have incorporated your
> new text in the latest draft update.
>
> > END
> >
> >TCP is also used by non-IETF application-
> >layer protocols in the IoT space such as the Message Queue Telemetry
> >Transport (MQTT) and its lightweight variants.
> >
> > It’s “Message Queuing Telemetry Transport”, and an informative
> > reference to
> > ISO/IEC 20922  wouldn’t be a
> > bad thing.
>
> Thank you as well. We have made the text change, and we have also added an
> informational reference to the MQTT specification, as suggested.
>
> Thanks,
>
> Carles (on behalf of the authors)
>

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] [Int-dir] Int Dir telechat review of draft-ietf-lwig-tcp-constrained-node-networks-11

[Bernie Volz (volz)]

RFC editor will fix remaining typos so no need to worry about those.

- Bernie

> On Oct 30, 2020, at 4:03 AM, Carles Gomez Montenegro  
> wrote:
> 
> Hi Bernie,
> 
> 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, including yours:
> https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-12
> 
> Please find below our inline responses:
> 
>> Hi:
>> 
>> I am an assigned INT directorate reviewer for
>> draft-ietf-lwig-tcp-constrained-node-networks (-11). These comments were
>> written primarily for the benefit of the Internet Area Directors. Document
>> editors and shepherd(s) should treat these comments just like they would
>> treat comments from any other IETF contributors and resolve them along
>> with any other Last Call comments that have been received. For more
>> details on the INT Directorate, see
>> https://datatracker.ietf.org/group/intdir/about/.
>> 
>> Reviewer: Bernie Volz
>> Review result: Ready (with minor nits)
>> 
>> Minor nits:
>> 
>> Section 2 should probably be updated to use the newer keyword boilerplate
>> (to reference RFC8174, etc.)?
> 
> Actually, since the document does not use normative language, and
> according to the suggestions by some reviewers, we decided to remove
> Section 2.
> 
>> In Section 4.1.2 RTO is used (and also later) but this isn't defined until
>> section 4.2.4. Perhaps this is better defined when first used?
> 
> Agreed.
> 
>> In section 4.2.2, the following paragraph is a bit odd:
>> 
>> 
>>   One potentially relevant TCP option in the context of CNNs is TCP
>> 
>>   Fast Open (TFO) [RFC7413].  As
>> described in Section
>> 5.3,
>> TFO can be
>> 
>>   used to address the problem of traversing middleboxes that perform
>> 
>>   early filter state record deletion.
>> 
>> Fast open isn't really used to address this issue. Section 5.3 is about
>> "TCP connection lifetime" and TFO is discussed there in the context of
>> reducing the (initial) messages and latency. Perhaps this paragraph needs
>> to be reworked a bit? If the point is about TFO, then you should indicate
>> what it is for (about optimizing short lived connections)?
> 
> Yes, the paragraph was not in a very good shape, and perhaps TFO is not so
> specifically relevant to single-MSS stacks. Since TFO was better covered
> in Section 5.3 (now, Section 4.3) we decided to actually remove the
> paragraph.
> 
>> General: While RFC-editor will do, s/subsection/section is probably a good
>> idea as subsection isn't generally used in IETF documents when doing
>> references.
> 
> Done.
> 
>> For section 8, it is too bad that some version/release information about
>> the particular "code" analyzed wasn't included. It says "be aware that
>> this Annex is based on information available as of the writing". But will
>> that still be valid when the RFC finally becomes available? Work started
>> on the document in Oct 2016 and I didn't go back to see when the various
>> sections were added. On the other hand, perhaps these implementations
>> don't evolve as rapidly as general software? It does seem to be a nice
>> survey of the available implementations.
> 
> We understand that the information in section 8 is currently valid. We did
> our best to provide references (or version numbers) whenever possible.
> However, information sources are quite heterogeneous, and in a couple of
> cases (FreeRTOS, uC/OS) we were not able to find a specific release number
> related to the information provided.
> 
>> And, there are at least the following typos:
>> 
>> characterstic
>> codesize (perhaps code size)
>> bandwitdh
>> practise
>> differrent
>> communcation
> 
> We made the corresponding corrections in our working copy, but I just
> realized that there is still one instance of "characterstic" and
> "codesize" in -12... The rest of typos have been corrected. Sorry for
> that. We will definitely address those in the next revision. :(
> 
>> 
>>  *   Bernie
> 
> Thanks,
> 
> Carles (on behalf of the authors)
> 
> 
> 
>> 
>> 
>> 
>> 
>> ___
>> Lwip mailing list
>> Lwip@ietf.org
>> https://www.ietf.org/mailman/listinfo/lwip
>> 
> 
> 
> ___
> Int-dir mailing list
> int-...@ietf.org
> https://www.ietf.org/mailman/listinfo/int-dir
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

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

[Bernie Volz (volz)]

Thanks. Looks good.

- Bernie

> On Oct 30, 2020, at 4:18 AM, Carles Gomez Montenegro  
> wrote:
> 
> Hi Éric,
> 
> 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:
> 
> 
>> Ã?ric Vyncke 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:
>> --
>> 
>> Thank you for the work put into this document. It is an important topic
>> and the
>> document is both easy to ready and detailed.
> 
> Thank you for your kind words.
> 
>> Please find below one trivial DISCUSS point and a couple of non-blocking
>> COMMENT points but please also check: - Ines Robles IoT directorate
>> review:
>>
>> https://datatracker.ietf.org/doc/review-ietf-lwig-tcp-constrained-node-networks-11-iotdir-telechat-robles-2020-10-20/
>> - Bernie Volz Internet directorate review:
>>
>> https://datatracker.ietf.org/doc/review-ietf-lwig-tcp-constrained-node-networks-11-intdir-telechat-volz-2020-10-20/
> 
> Yes, the latest revision is intended to address the comments received on
> -11, including those by Inés and Bernie.
> 
>> I hope that this helps to improve the document,
> 
> It did help, thank you.
> 
>> Regards,
>> 
>> -éric
>> 
>> == DISCUSS ==
>> 
>> Please replace all RFC 2460 references to RFC 8200. Trivial to fix ;-)
> 
> Done. ;-)
> 
>> --
>> COMMENT:
>> --
>> 
>> == COMMENTS ==
>> 
>> Should a reference to RFC 8900 be added in the MTU discussion in section
>> 4.1 ?
> 
> A reference to RFC 8900 has been added accordingly.
> 
>> -- Section 2 --
>> As noted by many, the BCP 14 boiler plate is the old one and the normative
>> terminology is not used in this informational document. => remove it ?
> 
> Agreed. We removed Section 2.
> 
> Thanks,
> 
> Carles (on behalf of the authors)
> 
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] [Tsv-art] Tsvart telechat review of draft-ietf-lwig-tcp-constrained-node-networks-11

[Mirja Kuehlewind]

Hi Carles,

Thanks for you edits. Looks all good to me!

Mirja


> On 30. Oct 2020, at 08:26, Carles Gomez Montenegro  
> wrote:
> 
> Hi Mirja,
> 
> 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, including yours:
> https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-12
> 
> Please find below our inline responses:
> 
>> Reviewer: Mirja Kühlewind
>> Review result: Ready
>> 
>> This document has been reviewed as part of the transport area review
>> team's
>> ongoing effort to review key IETF documents. These comments were written
>> primarily for the transport area directors, but are copied to the
>> document's
>> authors and WG to allow them to address any issues raised and also to the
>> IETF
>> discussion list for information.
>> 
>> When done at the time of IETF Last Call, the authors should consider this
>> review as part of the last-call comments they receive. Please always CC
>> tsv-...@ietf.org if you reply to or forward this review.
>> 
>> Thanks for the well-written document! This is good to go, I only have some
>> optional suggestions below:
> 
> Thanks for your kind words and for your constructive review.
> 
>> In section 4.1.2. you could potentially also mention
>> draft-ietf-tcpm-generalized-ecn as connections with small windows might
>> especially benefit when the ACK is also ECN-capable.
> 
> Agreed. We added the following before the last sentence of former 4.1.2
> (now 3.1.2):
> 
> NEW:
>   As of the writing, there is on-going work to extend the types of TCP
>   packets that are ECN-capable, including pure ACKs [draft-ietf-tcpm-
>   generalized-ecn]. Such a feature may further increase the benefits of
>   ECN in CNN environments.
> 
>> In section 4.2.1: "In that case, both congestion and flow control
>> implementation are quite simple." I guess this is even an understatement.
>> Basically this would be a static configuration and there is nothing left
>> to
>> "control".
> 
> We see your point, but we understand that at least some sort of flow
> control is still possible for a very simple TCP/IP stack. For instance, a
> TCP receiver can still send segments with zero receive window (RWND=0).
> Regarding congestion control, the RTO backoff applies, which is some basic
> form of congestion control. The wording "quite simple" in the document
> aims to capture that. However, please let us know if you have a different
> opinion.
> 
>> In section 4.2.3: "Disabling Delayed ACKs at the sender allows an
>> immediate ACK
>> for the data segment carrying the response." I guess you can in addition,
>> however, explain that keeping the delayed ACK could help to piggy-back the
>> ACK
>> with maybe some additional data to send instead of sending the ACK in a
>> separate TCP packet (of course depending on the traffic pattern of the
>> application). I think this is roughly mentioned later again but seems to
>> belong
>> her as well.
> 
> If we understand it correctly, your suggested addition is already present
> in the sentence right before the one that you focused on in this comment.
> If we misunderstood your comment, please let us know.
> 
>> Section 4.3.1.1: is this sentence correct? It least it did confuse me a
>> bit
>> when reading first: “A receiver supporting SACK will need to keep track
>> of the
>> SACK blocks that need to be received.” Maybe “A receiver supporting
>> SACK will
>> need to keep track of the data blocks that need to be received.” ?
> 
> Agreed.
> 
>> Section 4.3.2: Maybe s/it may make sense to use a small timeout/it may
>> make
>> sense to use a smaller timeout/ or s/it may make sense to use a small
>> timeout/it may make sense to use a very small timeout/ ?
> 
> Agreed (we used the first proposal).
> 
>> Section 4.3.3: “with an IW setting of 10 MSS, there is significant
>> buffer
>> overflow risk” I think it would be good to explain slightly better which
>> buffer
>> you mean. Is there an assumption that network buffer sizes are known in
>> CNNs as
>> managed by the same entity than the constraint devices? Maybe the
>> recommendation should be to make this parameter configurable? I guess most
>> stacks provide an option for this but not sure if all do…
> 
> In the highlighted text, “buffer” may actually refer to a buffer at any
> layer (e.g. a “radio buffer”, or an upper layer buffer), depending on the
> specific context. For example, some constrained device hardware platforms
> support a send buffer of at most one MSS of data.  We hope that the
> following update can help clarify the intent:
> 
> OLD:
>with an IW setting of 10 MSS, there is significant buffer overflow risk,
> 
> NEW:
>with an IW setting of 10 MSS, there is significant buffer overflow risk,
>since many CNN devices support network or radio buffers of a size
>smaller than 10 MSS.
> 
>> Section 6: maybe provide a reference to RFC8446 TLS1.3..?
> 
> Agreed.

Re: [Lwip] Robert Wilton's No Objection on draft-ietf-lwig-tcp-constrained-node-networks-11: (with COMMENT)

[Rob Wilton (rwilton)]

Hi Carles,

Thanks for confirming.

Regards,
Rob


> -Original Message-
> From: Carles Gomez Montenegro 
> Sent: 30 October 2020 07:50
> To: Rob Wilton (rwilton) 
> Cc: The IESG ; draft-ietf-lwig-tcp-constrained-node-
> netwo...@ietf.org; lwig-cha...@ietf.org; lwip@ietf.org; Zhen Cao
> 
> Subject: Re: Robert Wilton's No Objection on draft-ietf-lwig-tcp-
> constrained-node-networks-11: (with COMMENT)
> 
> Hi Robert,
> 
> 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:
> 
> > Robert Wilton 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:
> > --
> >
> > Hi,
> >
> > Thank you for this document.  It is somewhat outside my area of
> expertise,
> > but
> > I do not see any network management related issues.
> >
> > One minor comment:
> >
> > 3.2.  Usage scenarios
> >
> >There are different deployment and usage scenarios for CNNs.
> Some
> >CNNs follow the star topology, whereby one or several hosts are
> >linked to a central device that acts as a router connecting the
> CNN
> >to the Internet.  CNNs may also follow the multihop topology
> >[RFC6606].
> >
> > Perhaps: "Alternatively, CNNs may also follow ... ", otherwise it feels
> > like
> > this paragraph stops quite abruptly, whereas from the first couple of
> > sentences
> > I was expecting it to say a bit more about the different deployment
> > scenarios.
> 
> We applied your suggested change.
> 
> Thanks,
> 
> Carles (on behalf of the authors)
> 
> 
> > Regards,
> > Rob
> >
> >
> >
> >
> 

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

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

[Eric Vyncke (evyncke)]

Thank you Carle for addressing my DISCUSS point (which was trivial to fix ;) )

I have cleared my DISCUSS position on the data tracker

Regards and thanks again for the work done by the authors and the WG

-éric

-Original Message-
From: Carles Gomez Montenegro 
Date: Friday, 30 October 2020 at 09:18
To: Eric Vyncke 
Cc: The IESG , "Bernie Volz (volz)" , 
"lwip@ietf.org" , "mariainesrob...@googlemail.com" 
, 
"draft-ietf-lwig-tcp-constrained-node-netwo...@ietf.org" 
, 
"lwig-cha...@ietf.org" 
Subject: Re: [Lwip] Éric Vyncke's Discuss on 
draft-ietf-lwig-tcp-constrained-node-networks-11: (with DISCUSS and COMMENT)

Hi Éric,

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:


> Éric Vyncke 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:
> --
>
> Thank you for the work put into this document. It is an important topic
> and the
> document is both easy to ready and detailed.

Thank you for your kind words.

> Please find below one trivial DISCUSS point and a couple of non-blocking
> COMMENT points but please also check: - Ines Robles IoT directorate
> review:
> 
https://datatracker.ietf.org/doc/review-ietf-lwig-tcp-constrained-node-networks-11-iotdir-telechat-robles-2020-10-20/
> - Bernie Volz Internet directorate review:
> 
https://datatracker.ietf.org/doc/review-ietf-lwig-tcp-constrained-node-networks-11-intdir-telechat-volz-2020-10-20/

Yes, the latest revision is intended to address the comments received on
-11, including those by Inés and Bernie.

> I hope that this helps to improve the document,

It did help, thank you.

> Regards,
>
> -éric
>
> == DISCUSS ==
>
> Please replace all RFC 2460 references to RFC 8200. Trivial to fix ;-)

Done. ;-)

> --
> COMMENT:
> --
>
> == COMMENTS ==
>
> Should a reference to RFC 8900 be added in the MTU discussion in section
> 4.1 ?

A reference to RFC 8900 has been added accordingly.

> -- Section 2 --
> As noted by many, the BCP 14 boiler plate is the old one and the normative
> terminology is not used in this informational document. => remove it ?

Agreed. We removed Section 2.

Thanks,

Carles (on behalf of the authors)


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Éric Vyncke's No Objection on draft-ietf-lwig-tcp-constrained-node-networks-13: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-lwig-tcp-constrained-node-networks-13: 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:
--

Updated position as the previous DISCUSS point below (kept for archives) and
COMMENTs have been addressed

-éric

Thank you for the work put into this document. It is an important topic and the
document is both easy to ready and detailed.

Please find below one trivial DISCUSS point and a couple of non-blocking
COMMENT points but please also check: - Ines Robles IoT directorate review:

https://datatracker.ietf.org/doc/review-ietf-lwig-tcp-constrained-node-networks-11-iotdir-telechat-robles-2020-10-20/
- Bernie Volz Internet directorate review:

https://datatracker.ietf.org/doc/review-ietf-lwig-tcp-constrained-node-networks-11-intdir-telechat-volz-2020-10-20/

I hope that this helps to improve the document,

Regards,

== COMMENTS ==

Should a reference to RFC 8900 be added in the MTU discussion in section 4.1 ?

-- Section 2 --
As noted by many, the BCP 14 boiler plate is the old one and the normative
terminology is not used in this informational document. => remove it ?



___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Int Dir telechat review of draft-ietf-lwig-tcp-constrained-node-networks-11

[Carles Gomez Montenegro]

Hi again, Bernie,

> We made the corresponding corrections in our working copy, but I just
> realized that there is still one instance of "characterstic" and
> "codesize" in -12... The rest of typos have been corrected. Sorry for
> that. We will definitely address those in the next revision. :(

We just submitted -13, where those typos are now fixed:
https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-13

Thanks,

Carles (on behalf of the authors)

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Barry Leiba's No Objection on draft-ietf-lwig-tcp-constrained-node-networks-11: (with COMMENT)

[Carles Gomez Montenegro]

Hi Barry,

Thank you very much for your review!

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

Please find below our inline responses:


> Barry Leiba 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:
> --
>
> Thanks for a useful document.  I just have a few editorial things here:
>
> — Section 1 —
>
>However, TCP has been
>criticized (often, unfairly) as a protocol for the IoT.  In fact,
>some TCP features are not optimal for IoT scenarios, such as
>relatively long header size, unsuitability for multicast, and always-
>confirmed data delivery.  However, …
>
> Both of these sentences have nit-level problems that make them a bit off.
> The
> first sounds like the criticism is that TCP is a protocol for IoT (rather
> than
> that it’s not suitable for that usage).  The second has the examples
> misplaced,
> so it look as though they’re examples of IoT scenarios (rather than
> examples of
> TCP features).  And “in fact” has the wrong feel here: it would
> normally be
> used to contradict the previous sentence, not to explain it.  (And two
> “however”s in close proximity also feels awkward)  I suggest this fix:
>
> NEW
>TCP has been
>criticized, often unfairly, as a protocol that’s unsuitable for the
>IoT.  It is true that some TCP features, such as its relatively long
>header size, unsuitability for multicast, and always-confirmed data
>delivery, are not optimal for IoT scenarios.  However, …

Thanks for your detailed explanation, and thanks also for your proposed
new text, which definitely reads much better. We have incorporated your
new text in the latest draft update.

> END
>
>TCP is also used by non-IETF application-
>layer protocols in the IoT space such as the Message Queue Telemetry
>Transport (MQTT) and its lightweight variants.
>
> It’s “Message Queuing Telemetry Transport”, and an informative
> reference to
> ISO/IEC 20922  wouldn’t be a
> bad thing.

Thank you as well. We have made the text change, and we have also added an
informational reference to the MQTT specification, as suggested.

Thanks,

Carles (on behalf of the authors)

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-13.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Light-Weight Implementation Guidance WG of the 
IETF.

Title   : TCP Usage Guidance in the Internet of Things (IoT)
Authors : Carles Gomez
  Jon Crowcroft
  Michael Scharf
Filename: draft-ietf-lwig-tcp-constrained-node-networks-13.txt
Pages   : 30
Date: 2020-10-30

Abstract:
   This document provides guidance on how to implement and use the
   Transmission Control Protocol (TCP) in Constrained-Node Networks
   (CNNs), which are a characteristic of the Internet of Things (IoT).
   Such environments require a lightweight TCP implementation and may
   not make use of optional functionality.  This document explains a
   number of known and deployed techniques to simplify a TCP stack as
   well as corresponding tradeoffs.  The objective is to help embedded
   developers with decisions on which TCP features to use.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-13
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-networks-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-tcp-constrained-node-networks-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Benjamin Kaduk's No Objection on draft-ietf-lwig-tcp-constrained-node-networks-11: (with COMMENT)

[Carles Gomez Montenegro]

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 

Re: [Lwip] [Gen-art] Genart last call review of draft-ietf-lwig-tcp-constrained-node-networks-10

[Carles Gomez Montenegro]

Hi Alissa, and Linda,

Thank you very much for your reviews!

Based on Alissa's message, we understand that no update is required
regarding Linda's comments.

Thanks,

Carles (on behalf of the authors)


> Linda, thanks for your review. I think on both points you raise what the
> document proposes is well supported given the use case. I entered a No
> Objection ballot.
>
> Alissa
>
>> On Sep 24, 2020, at 1:34 PM, Linda Dunbar via Datatracker
>>  wrote:
>>
>> Reviewer: Linda Dunbar
>> Review result: Almost Ready
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>>
>> .
>>
>> Document: draft-ietf-lwig-tcp-constrained-node-networks-10
>> Reviewer: Linda Dunbar
>> Review Date: 2020-09-24
>> IETF LC End Date: 2020-09-30
>> IESG Telechat date: Not scheduled for a telechat
>>
>> Summary:
>> This document describes the guidance on how to configure TCP parameters
>> in the
>> Constrained-Node-Networks.
>>
>> Major issues:
>> 4.1.2. recommends ECN to be used  in the Constrained Node networks. In
>> any
>> network, especially when many IoT devices are attached , the congestion
>> can be
>> very short lived. Having Constrained node supporting ECN can cause
>> traffic
>> oscillation.  In addition, not many deployed internet supports ECN, it
>> can be
>> waste of processing of the CNN nodes.
>>
>> Section 4.1.1 recommend packet size to be 1280 for IPv6 to avoid the
>> need to
>> support Path MTU Discovery. it is problematic.  There are many layers of
>> tunneling and encapsulation in today's network, (let's not even assume
>> SR), the
>> actual packet size can be much larger.  Supporting Path MTU Discovery is
>> far
>> less processing intensive than supporting ECN.
>>
>> Minor issues:
>>
>> Nits/editorial comments:
>>
>> Cheers,
>>
>> Linda Dunbar
>>
>>
>> ___
>> Gen-art mailing list
>> gen-...@ietf.org
>> https://www.ietf.org/mailman/listinfo/gen-art
>
> ___
> Lwip mailing list
> Lwip@ietf.org
> https://www.ietf.org/mailman/listinfo/lwip
>


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

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

[Carles Gomez Montenegro]

Hi Éric,

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:


> Éric Vyncke 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:
> --
>
> Thank you for the work put into this document. It is an important topic
> and the
> document is both easy to ready and detailed.

Thank you for your kind words.

> Please find below one trivial DISCUSS point and a couple of non-blocking
> COMMENT points but please also check: - Ines Robles IoT directorate
> review:
> 
> https://datatracker.ietf.org/doc/review-ietf-lwig-tcp-constrained-node-networks-11-iotdir-telechat-robles-2020-10-20/
> - Bernie Volz Internet directorate review:
> 
> https://datatracker.ietf.org/doc/review-ietf-lwig-tcp-constrained-node-networks-11-intdir-telechat-volz-2020-10-20/

Yes, the latest revision is intended to address the comments received on
-11, including those by Inés and Bernie.

> I hope that this helps to improve the document,

It did help, thank you.

> Regards,
>
> -éric
>
> == DISCUSS ==
>
> Please replace all RFC 2460 references to RFC 8200. Trivial to fix ;-)

Done. ;-)

> --
> COMMENT:
> --
>
> == COMMENTS ==
>
> Should a reference to RFC 8900 be added in the MTU discussion in section
> 4.1 ?

A reference to RFC 8900 has been added accordingly.

> -- Section 2 --
> As noted by many, the BCP 14 boiler plate is the old one and the normative
> terminology is not used in this informational document. => remove it ?

Agreed. We removed Section 2.

Thanks,

Carles (on behalf of the authors)

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Murray Kucherawy's No Objection on draft-ietf-lwig-tcp-constrained-node-networks-11: (with COMMENT)

[Carles Gomez Montenegro]

Hi Murray,

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:


> Murray Kucherawy 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:
> --
>
> Piling on: You don't appear to need Section 2.

Agreed. We removed Section 2.

> Is Section 8 meant to be removed before publication, a la RFC 7942?

We would like to keep former Section 8 (now, Section 7), entitled "Annex.
TCP implementations for constrained devices".

Just for clarity, the next section ("Changes compared to previous
versions") is intended to be removed be removed before publication.

Thanks,

Carles (on behalf of all authors)

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Int Dir telechat review of draft-ietf-lwig-tcp-constrained-node-networks-11

[Carles Gomez Montenegro]

Hi Bernie,

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, including yours:
https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-12

Please find below our inline responses:

> Hi:
>
> I am an assigned INT directorate reviewer for
> draft-ietf-lwig-tcp-constrained-node-networks (-11). These comments were
> written primarily for the benefit of the Internet Area Directors. Document
> editors and shepherd(s) should treat these comments just like they would
> treat comments from any other IETF contributors and resolve them along
> with any other Last Call comments that have been received. For more
> details on the INT Directorate, see
> https://datatracker.ietf.org/group/intdir/about/.
>
> Reviewer: Bernie Volz
> Review result: Ready (with minor nits)
>
> Minor nits:
>
> Section 2 should probably be updated to use the newer keyword boilerplate
> (to reference RFC8174, etc.)?

Actually, since the document does not use normative language, and
according to the suggestions by some reviewers, we decided to remove
Section 2.

> In Section 4.1.2 RTO is used (and also later) but this isn't defined until
> section 4.2.4. Perhaps this is better defined when first used?

Agreed.

> In section 4.2.2, the following paragraph is a bit odd:
>
>
>One potentially relevant TCP option in the context of CNNs is TCP
>
>Fast Open (TFO) [RFC7413].  As
> described in Section
> 5.3,
> TFO can be
>
>used to address the problem of traversing middleboxes that perform
>
>early filter state record deletion.
>
> Fast open isn't really used to address this issue. Section 5.3 is about
> "TCP connection lifetime" and TFO is discussed there in the context of
> reducing the (initial) messages and latency. Perhaps this paragraph needs
> to be reworked a bit? If the point is about TFO, then you should indicate
> what it is for (about optimizing short lived connections)?

Yes, the paragraph was not in a very good shape, and perhaps TFO is not so
specifically relevant to single-MSS stacks. Since TFO was better covered
in Section 5.3 (now, Section 4.3) we decided to actually remove the
paragraph.

> General: While RFC-editor will do, s/subsection/section is probably a good
> idea as subsection isn't generally used in IETF documents when doing
> references.

Done.

> For section 8, it is too bad that some version/release information about
> the particular "code" analyzed wasn't included. It says "be aware that
> this Annex is based on information available as of the writing". But will
> that still be valid when the RFC finally becomes available? Work started
> on the document in Oct 2016 and I didn't go back to see when the various
> sections were added. On the other hand, perhaps these implementations
> don't evolve as rapidly as general software? It does seem to be a nice
> survey of the available implementations.

We understand that the information in section 8 is currently valid. We did
our best to provide references (or version numbers) whenever possible.
However, information sources are quite heterogeneous, and in a couple of
cases (FreeRTOS, uC/OS) we were not able to find a specific release number
related to the information provided.

> And, there are at least the following typos:
>
> characterstic
> codesize (perhaps code size)
> bandwitdh
> practise
> differrent
> communcation

We made the corresponding corrections in our working copy, but I just
realized that there is still one instance of "characterstic" and
"codesize" in -12... The rest of typos have been corrected. Sorry for
that. We will definitely address those in the next revision. :(

>
>   *   Bernie

Thanks,

Carles (on behalf of the authors)



>
>
>
>
> ___
> Lwip mailing list
> Lwip@ietf.org
> https://www.ietf.org/mailman/listinfo/lwip
>


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Robert Wilton's No Objection on draft-ietf-lwig-tcp-constrained-node-networks-11: (with COMMENT)

[Carles Gomez Montenegro]

Hi Robert,

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:

> Robert Wilton 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:
> --
>
> Hi,
>
> Thank you for this document.  It is somewhat outside my area of expertise,
> but
> I do not see any network management related issues.
>
> One minor comment:
>
> 3.2.  Usage scenarios
>
>There are different deployment and usage scenarios for CNNs.  Some
>CNNs follow the star topology, whereby one or several hosts are
>linked to a central device that acts as a router connecting the CNN
>to the Internet.  CNNs may also follow the multihop topology
>[RFC6606].
>
> Perhaps: "Alternatively, CNNs may also follow ... ", otherwise it feels
> like
> this paragraph stops quite abruptly, whereas from the first couple of
> sentences
> I was expecting it to say a bit more about the different deployment
> scenarios.

We applied your suggested change.

Thanks,

Carles (on behalf of the authors)


> Regards,
> Rob
>
>
>
>


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

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

[Carles Gomez Montenegro]

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)

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Tsvart telechat review of draft-ietf-lwig-tcp-constrained-node-networks-11

[Carles Gomez Montenegro]

Hi Mirja,

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, including yours:
https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-12

Please find below our inline responses:

> Reviewer: Mirja Kühlewind
> Review result: Ready
>
> This document has been reviewed as part of the transport area review
> team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the
> document's
> authors and WG to allow them to address any issues raised and also to the
> IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-...@ietf.org if you reply to or forward this review.
>
> Thanks for the well-written document! This is good to go, I only have some
> optional suggestions below:

Thanks for your kind words and for your constructive review.

> In section 4.1.2. you could potentially also mention
> draft-ietf-tcpm-generalized-ecn as connections with small windows might
> especially benefit when the ACK is also ECN-capable.

Agreed. We added the following before the last sentence of former 4.1.2
(now 3.1.2):

NEW:
   As of the writing, there is on-going work to extend the types of TCP
   packets that are ECN-capable, including pure ACKs [draft-ietf-tcpm-
   generalized-ecn]. Such a feature may further increase the benefits of
   ECN in CNN environments.

> In section 4.2.1: "In that case, both congestion and flow control
> implementation are quite simple." I guess this is even an understatement.
> Basically this would be a static configuration and there is nothing left
> to
> "control".

We see your point, but we understand that at least some sort of flow
control is still possible for a very simple TCP/IP stack. For instance, a
TCP receiver can still send segments with zero receive window (RWND=0).
Regarding congestion control, the RTO backoff applies, which is some basic
form of congestion control. The wording "quite simple" in the document
aims to capture that. However, please let us know if you have a different
opinion.

> In section 4.2.3: "Disabling Delayed ACKs at the sender allows an
> immediate ACK
> for the data segment carrying the response." I guess you can in addition,
> however, explain that keeping the delayed ACK could help to piggy-back the
> ACK
> with maybe some additional data to send instead of sending the ACK in a
> separate TCP packet (of course depending on the traffic pattern of the
> application). I think this is roughly mentioned later again but seems to
> belong
> her as well.

If we understand it correctly, your suggested addition is already present
in the sentence right before the one that you focused on in this comment.
If we misunderstood your comment, please let us know.

> Section 4.3.1.1: is this sentence correct? It least it did confuse me a
> bit
> when reading first: “A receiver supporting SACK will need to keep track
> of the
> SACK blocks that need to be received.” Maybe “A receiver supporting
> SACK will
> need to keep track of the data blocks that need to be received.” ?

Agreed.

> Section 4.3.2: Maybe s/it may make sense to use a small timeout/it may
> make
> sense to use a smaller timeout/ or s/it may make sense to use a small
> timeout/it may make sense to use a very small timeout/ ?

Agreed (we used the first proposal).

> Section 4.3.3: “with an IW setting of 10 MSS, there is significant
> buffer
> overflow risk” I think it would be good to explain slightly better which
> buffer
> you mean. Is there an assumption that network buffer sizes are known in
> CNNs as
> managed by the same entity than the constraint devices? Maybe the
> recommendation should be to make this parameter configurable? I guess most
> stacks provide an option for this but not sure if all do…

In the highlighted text, “buffer” may actually refer to a buffer at any
layer (e.g. a “radio buffer”, or an upper layer buffer), depending on the
specific context. For example, some constrained device hardware platforms
support a send buffer of at most one MSS of data.  We hope that the
following update can help clarify the intent:

OLD:
with an IW setting of 10 MSS, there is significant buffer overflow risk,

NEW:
with an IW setting of 10 MSS, there is significant buffer overflow risk,
since many CNN devices support network or radio buffers of a size
smaller than 10 MSS.

> Section 6: maybe provide a reference to RFC8446 TLS1.3..?

Agreed.

> Also section 6: You mention TCP-OA but you don’t give a really
> recommendation
> if or when it should be used or not.

We now aim at highlighting the benefits of TCP-AO, along with the
trade-off that needs to be assessed by the implementer. We updated the
first two paragraphs in Section 5 

[Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-12.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Light-Weight Implementation Guidance WG of the 
IETF.

Title   : TCP Usage Guidance in the Internet of Things (IoT)
Authors : Carles Gomez
  Jon Crowcroft
  Michael Scharf
Filename: draft-ietf-lwig-tcp-constrained-node-networks-12.txt
Pages   : 30
Date: 2020-10-30

Abstract:
   This document provides guidance on how to implement and use the
   Transmission Control Protocol (TCP) in Constrained-Node Networks
   (CNNs), which are a characterstic of the Internet of Things (IoT).
   Such environments require a lightweight TCP implementation and may
   not make use of optional functionality.  This document explains a
   number of known and deployed techniques to simplify a TCP stack as
   well as corresponding tradeoffs.  The objective is to help embedded
   developers with decisions on which TCP features to use.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-12
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-networks-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-tcp-constrained-node-networks-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip