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

[Mirja Kuehlewind <[e-mail]>]

Hi Carles,

Thanks for you edits. Looks all good to me!

Mirja


> On 30. Oct 2020, at 08:26, Carles Gomez Montenegro <[e-mail]> 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
>> [e-mail] 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 (formerly, Section 6), as follows:
> 
> NEW:
>   Best current practice for securing TCP and TCP-based communication
>   also applies to CNN.  As example, use of Transport Layer Security
>   (TLS) [RFC 8446] is strongly recommended if it is applicable. However,
>   note that TLS protects only the contents of the data segments.
> 
>   There are TCP options which can actually protect the transport layer.
>   One example is the TCP Authentication Option (TCP-AO) [RFC5925]. However,
>   this option adds overhead and complexity.  TCP-AO typically has a size of
>   16-20 bytes. An implementer needs to asses the trade-off between security
>   and performance when using TCP-AO, considering the characteristics (in
>   terms of energy, bandwidth and computational power) of the environment
>   where TCP will be used.
> 
>> I assume section 8 is intended to be kept for publication. I support that
>> as
>> it’s interesting information.
> 
> Thanks for your support!
> 
> Yes, we (the authors) would like to keep that former section 8 (now,
> section 7) for publication.
> 
> Greetings,
> 
> Carles (on behalf of the authors)
> 
> _______________________________________________
> Tsv-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tsv-art
>