Hi Carles, Thanks for you edits. Looks all good to me!
Mirja > On 30. Oct 2020, at 08:26, Carles Gomez Montenegro <carle...@entel.upc.edu> > 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. > >> 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 > tsv-...@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art > _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
