Re: [Lwip] draft-gomez-lwig-tcp-constrained-node-networks-03

[Carles Gomez Montenegro]

Hi Hannes,

First of all, sorry for the delay, and thanks a lot again for your
comprehensive review.

As you may have seen, we have published a revision of the draft (-01)
which, among others, aims to address your comments.

Please find below a set of inline responses:

> Hi Michael, Jon, Carles
>
> it is great that you have worked on this topic and, as stated during the
> Prague IETF meeting, I believe this document should become a WG item of
> the LWIG working group.
>
> I nevertheless have a couple of comments & questions.
>
> - Who do you think is the main audience for this draft? Is it primarily
> written for implementers of embedded TCP stacks or is it rather written
> for embedded developers who have to decide what stack and what features
> of TCP to use?
>
> If you ask me, I prefer it to be the latter. The reason is that there
> are very few implementers who write their own embedded TCP stack. There
> is, however, also an implication if you are aiming for the latter group,
> namely you cannot expect them to know all the details of TCP well. So,
> you need to present them with enough background so that they can make
> informed trade-off decisions.

[Carles] I think the draft should be useful for both types of audience.
I agree the second group may probably be larger. We have added a bit more
background in the document, but I’m rather inclined to avoid adding a
significant amount of background. IMHO, something in the style of RFC 3481
(which is quite concise) should work. Anyway, we have also added the
following at the end of Section 1:

   “This document assumes that the reader is familiar with TCP.  A
   comprehensive survey of the TCP standards can be found in [RFC7414].
   Similar guidance regarding the use of TCP in special environments has
   been published before, e.g., for cellular wireless networks
   [RFC3481].”

 If needed, more background may be added in further revisions of the draft.

> - The title of the document was probably the reason why I only noticed
> it recently. For some reason the term "Constrained Node Networks" does
> not stick well with me. I would have expect to see something like
> "Guidance for TCP Usage for Internet of Things".

[Carles] I think the most appropriate and better defined term is the one
in RFC 7228 (i.e. “Constrained-Node Networks”). However, we do agree that
“Internet of Things” is more widely recognizable and would increase
visibility of the document, and therefore we have modified the document
title as per your suggestion.

> I am also uncertain why
> you claim that the document defines a profile. It does not really define
> any profiles as far as I can tell.

[Carles] Agreed. This was written already in the -00 version, which
followed a quite different approach from the current version. We have
updated the Abstract and the Introduction accordingly in -01.

> - I would like to see some discussion about the communication patterns.
> For example, in the draft you talk about transactions (and I assume you
> mean request/response interactions). Are you focusing on those only or
> do you also consider cases of firmware updates into account? (In Section
> 4.8 you briefly mention firmware updates.) Have you looked at traffic
> patterns of some IoT applications?

[Carles] We have added a specific subsection (subsection 3.3) on traffic
patterns, which comprises unidirectional transfers, request-response
patterns and bulk data transfers.

> - Section 7 with the information about the protocol stacks is great. I
> hope you will complete the table some time in the near future and
> provide additional information about RAM requirements as well (in
> addition to the codesize).

[Carles] Thanks for the comment. We have now added a few more details (in
the TinyOS column). We will do our best to complete the table and the
details on RAM requirements. We also would like to request the WG to
please provide input, specially regarding information about RAM
requirements and code size.

> More detailed comments:
>
> You write:
>"In order to meet the requirements that
>stem from CNNs, the IETF has produced a suite of protocols
>specifically designed for such environments
>[I-D.ietf-lwig-energy-efficient]."
>
> The IETF approach on IoT in general has been to re-use as much as
> possible rather than to develop a whole new universe just for IoT. There
> are, however, a few new protocol developments but those are not really
> described well in [I-D.ietf-lwig-energy-efficient] since
> [I-D.ietf-lwig-energy-efficient] talks specifically about energy
> efficiency.

[Carles] Well, 6LoWPAN, RPL and CoAP may be considered as a set of new
protocols... We have added “new” as shown below:

   "In order to meet the requirements that
   stem from CNNs, the IETF has produced new protocols
 ^^^
   specifically designed for such environments, and has also reused
   existing ones."

[Carles] The reference focuses on energy efficiency, but 

Re: [Lwip] draft-gomez-lwig-tcp-constrained-node-networks-03

[Carles Gomez Montenegro]

Hi Hannes,

(If I may be the one who replies...)

First of all, thanks very much again for your thorough and useful review.

We have been working on updates to the document based on your comments. We
plan to submit a new version of the draft before the next I-D cutoff
(early enough so that the WG can react to the new draft version), and send
you a proper set of responses as well.

Cheers,

Carles



> Hi Michael,
>
> the document has in the meanwhile become a working group item and I was
> wondering whether you and your co-authors have had a chance to look at
> the comments in the meanwhile.
>
> Ciao
> Hannes
>
> On 08/11/2017 10:37 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>> Hi Hannes,
>>
>> Thanks a lot for this very valuable review, which will be addressed.
>> Please give us some time to come back with actual wording proposals.
>>
>> Thanks
>>
>> Michael
>>
>>
>>> -Original Message-
>>> From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
>>> Sent: Thursday, August 10, 2017 1:40 PM
>>> To: jon.crowcr...@cl.cam.ac.uk; Scharf, Michael (Nokia - DE/Stuttgart)
>>> ; Carles Gomez Montenegro
>>> ; lwip@ietf.org
>>> Subject: draft-gomez-lwig-tcp-constrained-node-networks-03
>>>
>>> Hi Michael, Jon, Carles
>>>
>>> it is great that you have worked on this topic and, as stated during
>>> the Prague
>>> IETF meeting, I believe this document should become a WG item of the
>>> LWIG
>>> working group.
>>>
>>> I nevertheless have a couple of comments & questions.
>>>
>>> - Who do you think is the main audience for this draft? Is it primarily
>>> written
>>> for implementers of embedded TCP stacks or is it rather written for
>>> embedded developers who have to decide what stack and what features of
>>> TCP to use?
>>>
>>> If you ask me, I prefer it to be the latter. The reason is that there
>>> are very
>>> few implementers who write their own embedded TCP stack. There is,
>>> however, also an implication if you are aiming for the latter group,
>>> namely
>>> you cannot expect them to know all the details of TCP well. So, you
>>> need to
>>> present them with enough background so that they can make informed
>>> trade-off decisions.
>>>
>>> - The title of the document was probably the reason why I only noticed
>>> it
>>> recently. For some reason the term "Constrained Node Networks" does not
>>> stick well with me. I would have expect to see something like "Guidance
>>> for
>>> TCP Usage for Internet of Things". I am also uncertain why you claim
>>> that the
>>> document defines a profile. It does not really define any profiles as
>>> far as I
>>> can tell.
>>>
>>> - I would like to see some discussion about the communication patterns.
>>> For example, in the draft you talk about transactions (and I assume you
>>> mean
>>> request/response interactions). Are you focusing on those only or do
>>> you
>>> also consider cases of firmware updates into account? (In Section
>>> 4.8 you briefly mention firmware updates.) Have you looked at traffic
>>> patterns of some IoT applications?
>>>
>>> - Section 7 with the information about the protocol stacks is great. I
>>> hope you
>>> will complete the table some time in the near future and provide
>>> additional
>>> information about RAM requirements as well (in addition to the
>>> codesize).
>>>
>>> More detailed comments:
>>>
>>> You write:
>>>"In order to meet the requirements that
>>>stem from CNNs, the IETF has produced a suite of protocols
>>>specifically designed for such environments
>>>[I-D.ietf-lwig-energy-efficient]."
>>>
>>> The IETF approach on IoT in general has been to re-use as much as
>>> possible
>>> rather than to develop a whole new universe just for IoT. There are,
>>> however, a few new protocol developments but those are not really
>>> described well in [I-D.ietf-lwig-energy-efficient] since
>>> [I-D.ietf-lwig-energy-
>>> efficient] talks specifically about energy efficiency.
>>>
>>> [I-D.tschofenig-core-coap-tcp-tls] has been replaced by
>>> [I-D.ietf-core-coap-
>>> tcp-tls].
>>>
>>> You write:
>>>
>>>"On the other hand, other application layer protocols not
>>> specifically
>>>designed for CNNs are also being considered for the IoT space.  Some
>>>examples include HTTP/2 and even HTTP/1.1, both of which run over
>>> TCP
>>>by default [RFC7540][RFC2616], and the Extensible Messaging and
>>>Presence Protocol (XMPP) [RFC 6120].  TCP is also used by non-IETF
>>>application-layer protocols in the IoT space such as MQTT and its
>>>lightweight variants [MQTTS]."
>>>
>>> I don't think the reference to [MQTTS] is appropriate. The other
>>> variant of
>>> MQTT, which exists as a standardized protocol is MQTT-SN and it uses
>>> UDP (if
>>> I recall correctly). As such, it does not fit into the argument you are
>>> making
>>> about TCP usage.
>>>
>>> XMPP is also not a good example since it is mostly used on gateways
>>> rather
>>> than low end IoT 

Re: [Lwip] draft-gomez-lwig-tcp-constrained-node-networks-03

[Scharf, Michael (Nokia - DE/Stuttgart)]

Hi Hannes,

Thanks a lot for this very valuable review, which will be addressed. Please 
give us some time to come back with actual wording proposals.

Thanks

Michael


> -Original Message-
> From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
> Sent: Thursday, August 10, 2017 1:40 PM
> To: jon.crowcr...@cl.cam.ac.uk; Scharf, Michael (Nokia - DE/Stuttgart)
> ; Carles Gomez Montenegro
> ; lwip@ietf.org
> Subject: draft-gomez-lwig-tcp-constrained-node-networks-03
> 
> Hi Michael, Jon, Carles
> 
> it is great that you have worked on this topic and, as stated during the 
> Prague
> IETF meeting, I believe this document should become a WG item of the LWIG
> working group.
> 
> I nevertheless have a couple of comments & questions.
> 
> - Who do you think is the main audience for this draft? Is it primarily 
> written
> for implementers of embedded TCP stacks or is it rather written for
> embedded developers who have to decide what stack and what features of
> TCP to use?
> 
> If you ask me, I prefer it to be the latter. The reason is that there are very
> few implementers who write their own embedded TCP stack. There is,
> however, also an implication if you are aiming for the latter group, namely
> you cannot expect them to know all the details of TCP well. So, you need to
> present them with enough background so that they can make informed
> trade-off decisions.
> 
> - The title of the document was probably the reason why I only noticed it
> recently. For some reason the term "Constrained Node Networks" does not
> stick well with me. I would have expect to see something like "Guidance for
> TCP Usage for Internet of Things". I am also uncertain why you claim that the
> document defines a profile. It does not really define any profiles as far as I
> can tell.
> 
> - I would like to see some discussion about the communication patterns.
> For example, in the draft you talk about transactions (and I assume you mean
> request/response interactions). Are you focusing on those only or do you
> also consider cases of firmware updates into account? (In Section
> 4.8 you briefly mention firmware updates.) Have you looked at traffic
> patterns of some IoT applications?
> 
> - Section 7 with the information about the protocol stacks is great. I hope 
> you
> will complete the table some time in the near future and provide additional
> information about RAM requirements as well (in addition to the codesize).
> 
> More detailed comments:
> 
> You write:
>"In order to meet the requirements that
>stem from CNNs, the IETF has produced a suite of protocols
>specifically designed for such environments
>[I-D.ietf-lwig-energy-efficient]."
> 
> The IETF approach on IoT in general has been to re-use as much as possible
> rather than to develop a whole new universe just for IoT. There are,
> however, a few new protocol developments but those are not really
> described well in [I-D.ietf-lwig-energy-efficient] since 
> [I-D.ietf-lwig-energy-
> efficient] talks specifically about energy efficiency.
> 
> [I-D.tschofenig-core-coap-tcp-tls] has been replaced by [I-D.ietf-core-coap-
> tcp-tls].
> 
> You write:
> 
>"On the other hand, other application layer protocols not specifically
>designed for CNNs are also being considered for the IoT space.  Some
>examples include HTTP/2 and even HTTP/1.1, both of which run over TCP
>by default [RFC7540][RFC2616], and the Extensible Messaging and
>Presence Protocol (XMPP) [RFC 6120].  TCP is also used by non-IETF
>application-layer protocols in the IoT space such as MQTT and its
>lightweight variants [MQTTS]."
> 
> I don't think the reference to [MQTTS] is appropriate. The other variant of
> MQTT, which exists as a standardized protocol is MQTT-SN and it uses UDP (if
> I recall correctly). As such, it does not fit into the argument you are making
> about TCP usage.
> 
> XMPP is also not a good example since it is mostly used on gateways rather
> than low end IoT devices. It is just a very verbose protocol.
> 
> Section 2 about "Characteristics of CNNs relevant for TCP" somehow feels a
> bit misplaced. I am wondering whether there is any loss in value of the
> document if you delete this entire section. RFC 7228, which you reference
> already in the abstract, talks about the constraints of IoT devices and there 
> is
> probably no need to repeat them again (and if you think so then maybe it fits
> better into the introduction).
> 
> Section 3 talks about the scenario and speaks about a model where
> constrained devices connect to unconstrained servers (cloud). What about
> cases where the TCP server itself is running on an IoT device? It appears that
> you consider such a scenario out of scope. Also the text in Section 4.1 gives
> me that impression.
> 
> Section 4 is where the meat of the document is. I personally would have
> structured the document a bit differently. It seems to me that