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

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 

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

[Carles Gomez Montenegro]

Hello Inés,

Thank you very much for your review, and for your kind words.

Regarding your two questions below, please find next our answers:

1.- Yes, we agree to remove section 2 (unless further discussion requires to
use normative language).

2.- Section 3.1.3 of RFC 8095 lists well-known TCP functionality. We
understand that the functionality that is relevant in the scope of our
document (i.e. guidance for TCP in IoT scenarios) is already covered.

We plan to apply our updates in the next revision (-12).

Kind regards,

Carles (on behalf of the authors)


> Reviewer: Ines Robles
> Review result: Ready
>
> Document: draft-ietf-lwig-tcp-constrained-node-networks-11
> Reviewer: Ines Robles
> Review Date: 2020-10-20
>
> Summary:
>
> 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).
>
> The document is clear to understand.
>
> Major Issues: None
>
> Minor Issues: None.
>
> Nits:
> 1- Should section 2 "Conventions used in this document" be removed? I have
> not
> found Normative language into the document 2- Questions: Following my
> understanding, the transport features provided by TCP [RFC 8095 - Section
> 3.1.3] are covered in this document, right? or there some of the mentioned
> features that does not apply to CNN?
>
> Thank you for this document,
>
> Ines
>
>
> ___
> 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] Last Call: (TCP Usage Guidance in the Internet of Things (IoT)) to Informational RFC

[Carles Gomez Montenegro]

Hi Ted,

We just submitted a new version of the draft (-11), which includes the
modified paragraph that we were talking about, slightly further modified
in the lines of your comments below:
https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/

Please find below an inline response to your last message:

> On Sep 20, 2020, at 2:28 AM, Carles Gomez Montenegro
>  wrote:
>> Thanks for the insight on the paper you mention. It offers interesting
>> details, and also experimental results consistent with our text, at
>> least
>> for some MSS range. It would have been great to see results for even
>> greater MSS than the ones considered in the paper.
>
> I agree. My intuition is that there is likely a peak number of segments
> past which adding more segments reduces performance; I suspect that this
> is probably close to the numbers the Berkeley paper arrived at, but we
> have no data. It would be good to have more data before making general
> assertions about what mss IoT devices should use, particularly given that
> some IoT transports may do per-fragment retransmission, while others
> won’t, and as you say, some IoT transports have reasonably large MTUs,
> while others don’t.
>>
>> Would the following proposed new text (that would replace the last
>> paragraph of 4.1.1) address your concern?
>>
>> PROPOSED:
>>
>>   Using larger MSS (to a suitable extent) may be beneficial in some
>>   scenarios, especially when transferring large payloads, as it reduces
>> the
>>   number of packets (and packet headers) required for a given payload.
>>   However, the characteristics of the constrained network need to be
>>   considered. In particular, in a network where unreliable fragment
>>   delivery is used, the amount of data that TCP unnecessarily
>>   retransmits due to fragment loss increases with the MSS. This happens
>>   because the loss of a fragment leads to the loss of the whole
>> fragmented
>>   packet being transmitted. Unnecessary data retransmission is
>> particularly
>>   harmful in CNNs due to the resource constraints of such environments.
>>   Note that, while the original 6LoWPAN fragmentation mechanism [RFC
>> 4944]
>>   does not offer reliable fragment delivery, fragment recovery
>>   functionality for 6LoWPAN or 6Lo environments is being standardized as
>> of
>>   the writing [draft-ietf-6lo-fragment-recovery].
>
> I think this is okay, although you don’t mention that given a constant
> per-frame error rate, the more frames you send, the higher the actual
> error rate will be, that this increases exponentially as the number of
> fragments increases, and further that, as you mention, in CNNs,
> retransmission traffic can swamp successful transmissions leading to worse
> and worse throughput as MSS increases.
>
> I don’t think it’s sufficient to mention this in a few sentences in a
> single paragraph. This needs to be part of a more detailed analysis.

Agreed. However, that analysis would probably be more suitable as a topic
for research work, and we understand that that kind of work would go
beyond the scope of this draft.

As a research topic, it would indeed be great to perform a deep analysis.
However, even then, it may be difficult to extract general conclusions,
since performance in a real-world scenario will depend on many factors
including network size, network density, network diameter, error
distribution, IoT technology used, layer 1 / layer 2 settings...

In this document, we try to provide the reader with the main advice of not
exceeding an MTU of 1280 bytes, and some guidance to help in this area
from the TCP point of view. We additionaly provide (non-quantified)
trade-offs regarding the MSS setting, so that the reader can be aware of
potential problems in some types of networks.

>> Thanks for your words. Yes, breaking the myth that 'TCP is not suitable
>> for IoT' is one of the main objectives of this document. Let's hope we
>> can
>> contribute to that!
>
> 100% agree. Thanks!

Thanks!

Carles

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

Re: [Lwip] Last Call: (TCP Usage Guidance in the Internet of Things (IoT)) to Informational RFC

[Carles Gomez Montenegro]

Hi Ted,

Thanks for your response. Please find below my inline responses:

> On Sep 18, 2020, at 8:14 AM, Carles Gomez Montenegro
>  wrote:
>> Could you please provide any pointers to "existing research that
>> shows that MSS of greater than perhaps five lowpan frames is quite
>> harmful.”
>> ?
>
> So, first of all, I really owe you an apology for both comments—this is
> just great evidence for why we should never say something about someone
> else’s work that we are not prepared for them to read. My reaction was
> the result of going to the thing I cared most about in the document,
> finding what it said to be incorrect based on what I think is true, and
> assuming that this would be representative of the rest of the document.
> There was actually no reason for me to make this assumption; what I was
> actually looking for from the person to whom I intended to send the
> message was reassurance that this wasn’t as bad as it seemed. My
> subsequent comment on the list acknowledging this faux pas actually made
> it worse because I was embarrassed and hadn’t gotten past the
> self-justification stage to the simple retraction stage. Sigh.

No worries, and thanks for your detailed response.

> The specific paper I am thinking of is one titled Performant TCP for
> Low-Power Wireless Networks, by Sam Kumar, Michael P Andersen, Hyung-Sin
> Kim, and David E. Culler at UC Berkeley
> (https://www.usenix.org/conference/nsdi20/presentation/kumar
> <https://www.usenix.org/conference/nsdi20/presentation/kumar>). Reviewing
> the paper, what it says is not inconsistent with what you’ve said. It
> appears to be the case that an mss of five frames tends to perform better
> than an mss of fewer frames, and that for example an mss of one frame
> performs poorly. Performance appears to increase up to five frames. So in
> a sense this is supporting the notion that even more frames would be
> better, but this was not studied.

Thanks for the insight on the paper you mention. It offers interesting
details, and also experimental results consistent with our text, at least
for some MSS range. It would have been great to see results for even
greater MSS than the ones considered in the paper.

> The reason I’m concerned about this is that it’s my understanding that
> generally on LLNs fragments are acknowledged at the packet level, not at
> the fragment level. This means that if five fragments are transmitted and
> one dropped, all five have to be retransmitted. This assumption may
> actually not be true—I haven’t tested it. It’s based on what others
> have told me about how this works. If this assumption isn’t true, then
> my primary concern goes away. The concern I have is that as packet loss
> rates rise, the likelihood of any given IP packet making it across an
> 802.15.4 mesh intact (with no fragments lost) drops. Because every
> fragment has to be retransmitted, this can result in a lot of extra
> traffic being sent, which can further increase packet loss.
>
>
> So if that’s true, it makes sense to keep the mss short, preferably
> shorter than 1280. 1280 would be thirteen fragments on 802.15.4, if my
> math is right. I think ideally we’d want to keep the MSS down nearer to
> 500 bytes.

In the document, our aim is to be comprehensive regarding underlying IoT
technologies. Some of these support a sufficiently large L2 MTU, and
therefore fragmentation is not needed. Many other IoT technologies support
their own (ARQ-enhanced) fragmentation mechanism at the link layer.
However, there are indeed examples where fragmentation does not support
additional functionality for reliable fragment delivery, such as the
original 6LoWPAN fragmentation defined in RFC 4944 over IEEE 802.15.4. In
such cases, a relatively large MSS may certainly create the issue that you
mentioned.

Would the following proposed new text (that would replace the last
paragraph of 4.1.1) address your concern?

PROPOSED:

   Using larger MSS (to a suitable extent) may be beneficial in some
   scenarios, especially when transferring large payloads, as it reduces the
   number of packets (and packet headers) required for a given payload.
   However, the characteristics of the constrained network need to be
   considered. In particular, in a network where unreliable fragment
   delivery is used, the amount of data that TCP unnecessarily
   retransmits due to fragment loss increases with the MSS. This happens
   because the loss of a fragment leads to the loss of the whole fragmented
   packet being transmitted. Unnecessary data retransmission is particularly
   harmful in CNNs due to the resource constraints of such environments.
   Note that, while the original 6LoWPAN fragmentation mechanism [RFC 4944]
   does not offer reliable fragment delivery, fragment recovery
   functionali

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

[Carles Gomez Montenegro]

Dear all,

We just submitted revision -10 of the "TCP Usage Guidance in the Internet
of Things (IoT)" draft.

The main changes in this revision are intended to address:

- Erik Kline's comments after his AD review.

- A comment from Markku Kojo on advice given in RFC 6691.

Thanks to both, Erik and Markku, for your valuable feedback!

Cheers,

Carles (on behalf of all authors)


 Original Message 
Subject: [Lwip] I-D Action:
draft-ietf-lwig-tcp-constrained-node-networks-10.txt
From:internet-dra...@ietf.org
Date:Mon, September 7, 2020 8:17 am
To:  i-d-annou...@ietf.org
Cc:  lwip@ietf.org
--


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-10.txt
Pages   : 30
Date: 2020-09-06

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-10
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-networks-10

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


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


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

Re: [Lwip] Publication has been requested fordraft-ietf-lwig-tcp-constrained-node-networks-09

[Carles Gomez Montenegro]

Hi Markku,

Thanks for your message below!

Your message is timely, as we are at an earlier stage of the document
process. (I understand that the shepherd writeup still needs to be
prepared, and the document has not yet been evaluated by the IESG.)

In the next update of the draft, we will add the reference and will edit
the text as per your suggestion.

Once again, thanks a lot for your contributions to this document!

Cheers,

Carles


> Hi Carles, All
>
> thanks again for your work on this!
>
> This seems still about to be advanced to publication in the process, so
> there is one reference that I just noted and that I (and others) missed
> earlier, and that you might want to add to this doc once it appears to
> auth48.
>
> It's related to my earlier comment on Sec 4.1.1 (see below):
>
> In addition, to my understanding TCP implementations typically
> address
> the presence of TCP options such that they eat the necessary space
> for
> TCP options from the payload, not by increasing the IP datagram size
> if TCP options are present. For example, if SMSS is set to, let's say
> 1460 octets, and a TCP sender adds a TCP timestamp option (12 bytes)
> it
> will send only 1448 bytes of payload in a TCP segment?
>
> What the draft now says in this respect is on the safe side, but it
> might be overcautious. I don't remember any RFC saying how SMSS and
> adding options to a TCP segment are related. Maybe someone of the TCP
> implementors may shed more light to this how?

 We have tried to address your two comments above. On this matter, we
> had
 received feedback that this measure (advertising an MSS smaller than
 1220
 bytes) would be safe, but we have tried to reflect that this might not
 be
 necessary, and even overcautious.
>>>
>>> Seems fine, thanks.
>
> I didn't remember at the time, but there actually is an RFC that gives
> the guidelines of handling this, RFC 6691, and it would be worth citing
> here. And possibly slightly editing the text that says "Note that, in
> many implementations, ..." to emphasize something along the lines:
> "However, note that it is recommended/reguired/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.
>
> The requirement in RFC 6691 is lower case must in an informational RFC, so
> not quite sure how to best reflect that here when citing (maybe using
> "advised" above)? My suggested text also slightly modifies the original
> text, but I believe it's all ok to edit it like this even during auth48?
> If you feel it is better not to change the text anymore at this point, I
> think it's also fine just adding the reference (though I personally find
> it better/more correct  to change the text a bit along the lines above).
>
> Best regards,
>
> /Markku
>
>
> On Fri, 6 Mar 2020, Zhen Cao via Datatracker wrote:
>
>> Zhen Cao has requested publication of
>> draft-ietf-lwig-tcp-constrained-node-networks-09 as Informational on
>> behalf of the LWIG working group.
>>
>> Please verify the document's state at
>> https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/
>>
>>
>> ___
>> 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] WGLC review ofdraft-ietf-lwig-tcp-constrained-node-networks

[Carles Gomez Montenegro]

Dear Markku,

First of all, our apologies for the delay in this response!

We would like to thank you once again for your thorough review and update
suggestions.

We recently published -09, with the aim of addressing the remaining points.

Please find below our inline responses:

> Dear Carles, all,
>
> it took longer to find time to pass through the draft than I thought a
> week or so ago. My apologies and thanks for your patience.
>
> It looks fine to me with a few exceptions that still seem to need some
> work, I think.
>
> Please see inline.
>
> Cheers,
>
> /Markku
>
> On Wed, 5 Jun 2019, Carles Gomez Montenegro wrote:
>
>> Dear Markku,
>>
>> Thank you very much for your comprehensive and detailed review of the
>> draft. Your constructive comments have been very useful to address
>> issues
>> and improve the quality of the document. Our updates can be found in
>> revision -08.
>>
>> Please find below our inline responses to your comments.
>>
>>> Hi all,
>>>
>>> I have reviewed the -07 version of this draft for the WGLC.
>>>
>>> The draft is very useful for many developpers using or considering of
>>> using TCP in CNN scenarious. It has improved a lot from the previous
>>> versions but there are still a number of issues worth addressing.
>>>
>>> See comments below.
>>>
>>> Best regards,
>>>
>>> /Markku
>>>
>>> Sec 4.1.
>>>
>>> Title: Path properties
>>> - Would it be better to use "Addressing path properties" or something
>>> similar as TCP cannot (much) affect the properties?
>>
>> Sounds good!
>>
>>> Sec. 4.1.1.
>>>
>>> If I understand it correctly, the discussion in this section is
>>> intended
>>> to be all about avoiding Path MTU discovery when running TCP oevr IPv6?
>>> Therefore, "Avoiding Path MTU Discovery in IPv6" would probably be
>>> a better title?
>>
>>> From our point of view, the section is actually about setting the MSS
>>> to a
>> suitable value, which then may help avoiding the need to support Path
>> MTU
>> Discovery, but also the need to perform IP-layer fragmentation at the
>> source. We have explicitly added the latter in -08.
>
> This seems fine now, except I noticed another problem that I didn't spot
> last time. The text says a few of times something about
> limiting/setting MTU, where you actually want to advice limiting IP
> datagram size (by setting the MSS), just like you say above. But the text
> reads, for example:
>
>   ... it may be desirable to limit the MTU to 1280 bytes ...
>
> which I believe should read somethig like:
>
>   ... it may be desirable to limit the IP datagram size to 1280 bytes ...
>
> MTU is the property of the network link at hand, not controllable same way
> as the IP datagram size which can be limited by setting the TCP MSS. And,
> if MTU was settable, avoiding framentation would call for setting it to as
> large value as possible, not limiting it.

Agreed!

>>> In addition, to my understanding TCP implementations typically address
>>> the presence of TCP options such that they eat the necessary space for
>>> TCP options from the payload, not by increasing the IP datagram size
>>> if TCP options are present. For example, if SMSS is set to, let's say
>>> 1460 octets, and a TCP sender adds a TCP timestamp option (12 bytes) it
>>> will send only 1448 bytes of payload in a TCP segment?
>>>
>>> What the draft now says in this respect is on the safe side, but it
>>> might be overcautious. I don't remember any RFC saying how SMSS and
>>> adding options to a TCP segment are related. Maybe someone of the TCP
>>> implementors may shed more light to this how?
>>
>> We have tried to address your two comments above. On this matter, we had
>> received feedback that this measure (advertising an MSS smaller than
>> 1220
>> bytes) would be safe, but we have tried to reflect that this might not
>> be
>> necessary, and even overcautious.
>
> Seems fine, thanks.
>
>>> The second but last para discussing IPv4 in this context is very
>>> confusing. In particular, the 2nd sentence
>>>
>>>   "In IPv4, the MTU is 576 bytes."
>>>
>>> is simply incorrect. In IPv4 the requirement is that any host must be
>>> able to accept datagrams of up to 576 octets, but there is no upper
>>> limit of 576 for IPv4 MTU!
>>
>> Indeed. The 2nd sentence missed the word ?minimum? b

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

[Carles Gomez Montenegro]

Dear all,

Please find below a new revision (-07) of the draft entitled "TCP Usage
Guidance in the Internet of Things (IoT)".

The updates in this revision are intended to address the comments and
incorporate the suggestions kindly provided by Gorry Fairhurst.

@Gorry: thank you very much for taking the time to review the draft.

Cheers,

Carles (on behalf of all authors)



 Original Message 
Subject: [Lwip] I-D Action:
draft-ietf-lwig-tcp-constrained-node-networks-07.txt
From:internet-dra...@ietf.org
Date:Fri, March 29, 2019 8:17 pm
To:  i-d-annou...@ietf.org
Cc:  lwip@ietf.org
--


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-07.txt
Pages   : 27
Date: 2019-03-29

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-07
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-networks-07

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


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


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

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

[Carles Gomez Montenegro]

Dear LWIP and TCPM WGs,

First of all, thanks to everyone who provided feedback on revision -04 of
our "TCP Usage Guidance in the Internet of Things (IoT)" draft.

Please find below the pointers to an update of the draft (revision -05),
based on the comments received.

Main changes:

o  Addressed comments by Yoshifumi Nishida
o  Removed mentioning MD5 as an example (comment by David Black)
o  Added memory footprint details of TCP implementations (Contiki-NG
   and lwIP 2.1.2) provided by Rahul Jadhav in the Annex [1]
o  Addressed comments by Ilpo Jarvinen throughout the whole document
o  Improved the RIOT section in the Annex, based on feedback from
   Emmanuel Baccelli

[1] Rahul kindly performed memory footprint measurements for the sake of
this draft (feel free to visit https://github.com/nyrahul/sizeof)

The authors believe that the document is now ready for WGLC.

Cheers,

Carles (on behalf of all authors)


 Original Message 
Subject: [Lwip] I-D Action:
draft-ietf-lwig-tcp-constrained-node-networks-05.txt
From:internet-dra...@ietf.org
Date:Sun, March 10, 2019 8:39 am
To:  i-d-annou...@ietf.org
Cc:  lwip@ietf.org
--


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-05.txt
Pages   : 26
Date: 2019-03-09

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-05
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-networks-05

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


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


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

Re: [Lwip] [tcpm] [Fwd: I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-04.txt]

[Carles Gomez Montenegro]

Hello Yoshi,

Sorry for the late reply, and thanks a lot for taking the time for your
review and for providing comments.

Please find below my inline responses:

> Hello,
>
> I've read the draft and I think the draft looks fine and mostly ready.
> I have some comments below..
>
> 1: Section 4.2.4:
>   "In that case, RTO algorithm tuning may be considered, although
> careful assessment of possible drawbacks is recommended"
>
> -> It might be better if we refer draft-ietf-tcpm-rto-consider here
> although it is not very certain the draft will be published at this
> moment? It seems to me the motivation of the doc fits the situation
> like this.

I agree. I guess we may cite draft-ietf-tcpm-rto-consider as an
informative reference for this section.

> 2: Section 4.3.1:
>"These algorithms work efficiently for window size of at least 5 MSS"
>
> -> Just curious why this is 5? Is it because the use of delayed ack is
> presumed?
>  A receiver may have a chance to send an ack for segment 1 before
> segment 3 arrives.

Yes, the text was written under the assumption that delayed ACKs might be
in place. In the next revision we will explicitly indicate the assumption,
and update the related text as per your comment.

> 3: Section 5.3
> CCN -> CNN?

Thanks for catching the typo!

>"This overhead could be reduced by TCP Fast Open (TFO)"
>
> -> Yes, but the use of TLS is not mandatory in this draft. If an
> implementation utilizes TFO, we might want to mention about app level
> idempotency here.

Not sure I'm following you here. Could you please elaborate?

>"TCP keep-alive messages are not very useful to..."
>
> -> We don't need to discuss reducing the interval of keep-alive here?

Currently, we have some text on this, although I agree it is a bit too
indirect. In the next revision, we will elaborate further.

Once again, thanks for your comments.

Cheers,

Carles


> Thanks,
> --
> Yoshi

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

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

[Carles Gomez Montenegro]

Dear LWIG and TCPM WGs,

As you can see below, we have updated the "TCP Usage Guidance in the
Internet of Things (IoT)" draft.

This revision intends to address previously pending TODOs, as well as
comments from the LWIG session in Montreal.

As you may recall, we are getting ready for requesting a WGLC. Your
comments will be most welcome.

Thanks,

Carles (on behalf of all authors)


 Original Message 
Subject: [Lwip] I-D Action:
draft-ietf-lwig-tcp-constrained-node-networks-04.txt
From:internet-dra...@ietf.org
Date:Tue, October 9, 2018 7:30 am
To:  i-d-annou...@ietf.org
Cc:  lwip@ietf.org
--


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-04.txt
Pages   : 25
Date: 2018-10-08

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-04
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-networks-04

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


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


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

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

[Carles Gomez Montenegro]

Dear LWIG WG,

As you can see below, we have updated the LWIG TCP draft. Comments are
welcome!

On the other hand, while we believe the document is starting to be quite
complete, we would like to take the opportunity to ask you a few
questions:

1.- With regard to the constrained TCP implementations survey in the
Annex, please let us know if you would object against presence in the
Annex of any of the currently covered implementations, or if you think
others may need to be included.

2.- So far, we have not been able to find or receive much content for the
“Data size” row in the summary table. A nice exception to this is RAM
usage measurement results on the RIOT TCP implementation, that have been
kindly provided by Simon Brummer. However, as getting similar information
for the rest of implementations appears to be difficult, our proposal
would be removing this row from the table (as shown in the current draft
version), while keeping the "Code size" row in. RAM usage details for the
RIOT TCP implementation have been included anyway as a table footnote.
Would anyone object to this approach?

3.- If you are aware of specific code vulnerabilities that may arise when
implementing TCP for constrained devices, please let us know.

Thanks,

Carles, Jon, Michael


 Original Message 
Subject: [Lwip] I-D Action:
draft-ietf-lwig-tcp-constrained-node-networks-03.txt
From:internet-dra...@ietf.org
Date:Sun, June 10, 2018 10:36 am
To:  i-d-annou...@ietf.org
Cc:  lwip@ietf.org
--


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-03.txt
Pages   : 24
Date: 2018-06-10

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-03
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-networks-03

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


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


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

Re: [Lwip] Genart telechat review of draft-ietf-lwig-energy-efficient-08

[Carles Gomez Montenegro]

Dear Peter,

Thanks a lot for your helpful review.

We plan to incorporate your suggestions in the next revision of the draft.

Best regards,

Carles


> Reviewer: Peter Yee
> Review result: Ready with Issues
>
> 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 wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-lwig-energy-efficient-08
> Reviewer: Peter Yee
> Review Date: 2017-12-09
> IETF LC End Date: None
> IESG Telechat date: 2018-01-11
>
> Summary: This Informational Track specification discusses aspects of
> network
> protocol design that can negatively affect energy consumption of
> constrained
> nodes.  It's generally informative, although it doesn't provide much
> specific
> guidance on how its recommendations can be accomplished.  Ready with
> Issues.
>
> Major issues:
>
> Minor issues:
>
> Page 8, section 3.6.1, section title: this whole section refers to IEEE
> 802.11,
> but there is no reference to primary specification given.  Furthermore, a
> specific version of IEEE 802.11 should be cited.  The current version is
> IEEE
> 802.11-2016.  Reference to IEEE 802.11v is made further down in this
> section,
> but in fact IEEE 802.11v was incorporated and subsumed into IEEE
> 802.11-2012
> and need not be separately cited any longer.  IEEE considers IEEE 802.11v
> to be
> a superseded standard.
>
> Page 9, 6th paragraph: this paragraph should be expanded and clarified.
> It
> makes the implied assumption that the protocol is operating on a
> constrained
> node, but there are (generally) two sides to a protocol.  The remote side
> may
> not be aware of the constrained nature of the device with which it is
> communicating.  And in fact, it may be communicating with a mix of
> constrained
> and unconstrained devices, so without some form of signaling, it will not
> necessarily know to synchronize with parameters that are complementary to
> the
> needs of the constrained device.  While I understand what the paragraph is
> saying, it gives the topic short shrift.
>
> Nits/editorial comments:
>
> General:
>
> Append a comma after occurrences of i.e. and e.g.
>
> Specific:
>
> Page 1, Abstract, 2nd sentence: delete the comma.
>
> Page 3, 2nd full paragraph, 1st sentence: insert a space before each of
> "[RFC6775]" and "[RFC4944]".
>
> Page 3, section 1.1: insert "and" between "[RFC7228]" and
> "[I-D.bormann-lwig-7228bis]".
>
> Page 8, section 3.4, 3rd sentence: the sentence refers to "the next
> subsection", but in fact that should be a point to subsection 3.6.  Either
> re-order subsections 3.4 and 3.5 to make the reference correct or change
> to an
> explicit "subsection 3.6".
>
> Page 8, section 3.6.1, 1st paragraph, 5th sentence: change "the latter" to
> "it".
>
> Page 9, 5th paragraph: change "client initiated" to "client-initiated".
> Change
> "network assisted" to "network-assisted".  Change "Idel" to "Idle".
> Change
> both occurrences of "save" to "saving".
>
> Page 9, section 3.6.2, 1st paragraph, 3rd sentence: delete the second
> "IPv6".
>
> Page 10, 1st full paragraph, 2nd sentence: change "since" to "from".
>
> Page 10, section 3.6.3, last sentence: chance "functionalites" to
> "functionalities".
>
> Page 13, 1st paragraph, 1st sentence: append a comma after "At the MAC
> level".
>
> Page 13, 1st paragraph, 2nd sentence: insert "a" before "paging".
>
> Page 13, 1st paragraph, 9th sentence: change "check" to "checking".
>
> Page 13, 2nd paragraph, 6th sentence: change "dummybearer" to "dummy
> bearer".
>
> Page 13, 2nd paragraph, 7th sentence: insert "a" before "longer".  Change
> "a"
> before "energy" to "an".
>
> Page 14, section 4, 2nd paragraph, 1st sentence: change "energy-efficient"
> to
> "energy efficient".
>
> Page 14, section 4, 2nd paragraph, 6th sentence: change "then" to "the"
> before
> "6LoWPAN".
>
> Page 15, 1st partial paragraph, 1st full sentence: change "alternative" to
> "alternatively".
>
> Page 15, section 5, 2nd paragraph, 6th sentence: change "energy-friendly"
> to
> "energy friendly".
>
> Page 15, section 5, 3rd paragraph, 2nd sentence: replace "allows to
> provide"
> with "provides".
>
> Page 17, section 6.4, 1st sentence: substitute "encodes" for "allows to
> encode".
>
> Page 18, section 9, 2nd paragraph: insert "The" before "Authors" and make
> "Authors" lowercase.
>
> Page 18, section 9, 3rd paragraph, 1st sentence: insert "the" before
> "IESG".
> Change "IETF87" to "IETF 87".
>
> Page 18, section 9, 3rd paragraph, 2nd sentence: Change "Jaeglli" to
> "Jaeggli".
>
> Page 19, section 11: change "the energy efficient" to "energy-efficient".
>
> Page 19, IEEE80211v reference: drop the period after "Management".
>
>


___
Lwip 

Re: [Lwip] Iotdir early review of draft-ietf-lwig-energy-efficient-07

[Carles Gomez Montenegro]

Dear Charlie,

Thank you very much for your detailed review, and for the constructive
feedback provided. Also, providing us with your editorial suggestions via
a diff file is very much appreciated!

We have updated the draft (now, -08). This version aims to address both
your editorial and technical comments.

Should you have further comments, please let us know.

Cheers,

Carles (on behalf of all authors)

---
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lwig-energy-efficient/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lwig-energy-efficient-08
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-energy-efficient-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-energy-efficient-08
---


> Reviewer: Charles Perkins
> Review result: On the Right Track
>
> [Please excuse if this is a duplicate.  I got an error from datatracker on
> my first attempt.]
>
> Overall comments:
>
> I think that some important techniques for energy efficiency deserve
> mention
> or significant enlargement:
>
> - Packet bundling
> - Data aggregation
> - Power management / range reduction
> - Fragmentation is more energy-efficient at lower layers than at higher
> layers
> - Compression, on the other hand, is more efficient at higher layers,
>   particularly before encryption.
>
> The document needs a concise statement of purpose.  Maybe insert the
> following after the first paragraph of the Introduction:
>
>In this document we describe techniques that are in common use at Layer
> 2
>and at Layer 3, and we indicate the need for higher-layer awareness of
>lower-layer features.
>
> Also in the introduction, some discussion is needed about cross-layer
> design.
> Is cross-layer design in scope for the [lwig] Working Group?
>
> In figure 1 and elsewhere, it should not be assumed that RPL is the only
> choice for routing in energy-efficient networks.  So, for instance,
> "RPL" could be replaced by "RTG" in Figure 1.
>
> Shouldn't there be an entry for synchronized reception in Figure 2?  Isn't
> Figure 2 actually a table, and thus should be labeled Table 1?
>
> Section 3.3 (Throughput) does not seem to add much if anything to the
> discussion.  The conclusion about the trade-off is quite obvious.
>
> Particularly in section 3.5.2, but also elsewhere, some examples would
> be very helpful.
>
> Section 6.3 (CoAP timers) seems to be only about one timer.
> Are there more?  What about interactions with TCP timers, etc.?
>
> Section 7 should be entitled "Summary and Conclusions".
> In section 7, it would be nice to offer cross references for each
> conclusion, referring the reader to the relevant section of the document.
> Each conclusion should follow from some previous section of the document.
> Unfortunately that currently isn't quite the case.
>
> The citation [Announcementlayer] does not appear in the body of the
> article.
>
> There are weird line breaks appearing at certain random points in the
> document.
>
> I have editorial suggestions and corrections which I will
> supply as an rfcdiff file under separate email.
>
> Regards,
> Charlie P.
>
> ___
> 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] 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)
>>> <michael.sch...@nokia.com>; Carles Gomez Montenegro
>>> <carle...@entel.upc.edu>; 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:
>>>

Re: [Lwip] Constrained TCP draft

[Carles Gomez Montenegro]

Hi Rahul,

Thank you very much for your comments.

Please find below inline responses:

> Hi Carles & co-authors,
>
> Foll are my comments for the
> draft-gomez-lwig-tcp-constrained-node-networks-03:
>
> 1.  Section 4.3 Window Size
> [RJ] A single MSS implies max one in-flight segment ... While such a
> mechanism sure will help reduce implementation complexity and the buffer
> requirement on the sender, but it has a major problem with delayed ACKs
> mechanism on the receiver. There is a hack (
> http://contiki.sourceforge.net/docs/2.6/a01696.html) implemented in UIP
> which circumvents this issue.

This is very interesting. We'll discuss this in the next update of the draft.

> 2. Section 3 Scenarios
> [RJ] I feel the doc need not talk about unconstrained scenarios ...

We actually only intend to talk about unconstrained devices when they
communicate with constrained devices. This appears to be a common scenario
(e.g. a constrained device talking to backend infrastructure).

> For
> the
> constrained environment, the doc can classify between different types of
> devices ... For example, a class A/B device with possibly single and same
> send/recv buffer, a class B device with possibly a separate send and recv
> buffer and a class C device with multiple say 5 send/recv buffers (pooled
> for either send/recv). Note that in case of uIP the send/recv buffers are
> same not only for TCP but they are shared for other protocols as well ...

Yes, I agree with something along these lines. In fact it would be great
to find out if those device classes can be related with RFC 7228 device
classes, or if we can directly refer to the existing definitions in RFC
7228.

> 3. Section 4.3 "it may be useful to allow window sizes of at least five
> MSSs
> "
> [RJ] I tried checking RFC5681, but could not relate to 5 MSSs for fast
> transmit/recovery...

Referring to a fragment of an email by Fred Baker, sent around one year ago:

"... name the packets in a given transmission burst A through F, and
presume that B gets lost. The sender should get an acknowledgement for A
when C arrives and duplicate acknowledgements when D, E, and F arrive. It
will retransmit B when the third duplicate ack arrives. In order to have
B, C, D, E, and F sent, the window has to be at least five."

> 4. Section 4.7
> [RJ] There is a redundant stmt ,, "Other TCP options should not be used,
> in
> keeping with the principle of lightweight operation" ... repeated on
> subsequent line.

Oh, thanks!

> 5. Section 7.1 uIP
> [RJ] May be this section can mention the Contiki "split hack" technique
> (link ref'd above) to avoid delayed ACKs in case of sender using single
> MSS. This helps because receivers now need not change to disable delayed
> ACKs and in most deployment such kind of control on the server/receiver is
> usually not possible.

Agreed.

> 6. Section 7.1 uIP "A buffer for outgoing data is not provided"
> [RJ] The same buffer is used for both incoming and outgoing traffic.

Agreed, we'll update this accordingly (the intent was about a *separate*
buffer).

> 7. Section 7.1 uIP "an application must be able to reproduce the same
> packet that had been transmitted"
> [RJ] Application cannot reproduce the same packet because application does
> not control the tcp header values and thus additional buffer space per
> connection is warranted (and is indeed used) in case of TCP in uIP.

Good catch, the sentence above needs to be modified to refer to the *data*.

> 8. Section 7.3 RiOT
> [RJ] Unlike uIP/lwip, the TCP numbers (prog mem) for RIOT-TCP aren't
> mentioned ! Would be nice to know this difference.

Same here ;-)

We've been in contact with a developer of the RIOT TCP implementation.
Let's see if we can be provided with more details on this.

Once again, thanks very much for your detailed comments.

Cheers,

Carles

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

[Lwip] [Fwd: New Version Notification for draft-gomez-lwig-tcp-constrained-node-networks-03.txt]

[Carles Gomez Montenegro]

Dear LWIG WG folks,

We have just submitted an update of the TCP over CNNs draft.

In this new version, we have aimed to address the feedback received in
Chicago, and we have added content on the RIOT and OpenWSN TCP
implementations.

Any comments will be very much welcome.

Cheers,

Carles




 Original Message 
Subject: New Version Notification for
draft-gomez-lwig-tcp-constrained-node-networks-03.txt
From:internet-dra...@ietf.org
Date:Fri, June 30, 2017 8:23 am
To:  "Jon Crowcroft" 
 "Michael Scharf" 
 "Carles Gomez" 
--


A new version of I-D, draft-gomez-lwig-tcp-constrained-node-networks-03.txt
has been successfully submitted by Carles Gomez and posted to the
IETF repository.

Name:   draft-gomez-lwig-tcp-constrained-node-networks
Revision:   03
Title:  TCP over Constrained-Node Networks
Document date:  2017-06-29
Group:  Individual Submission
Pages:  17
URL:   
https://www.ietf.org/internet-drafts/draft-gomez-lwig-tcp-constrained-node-networks-03.txt
Status:
https://datatracker.ietf.org/doc/draft-gomez-lwig-tcp-constrained-node-networks/
Htmlized:  
https://tools.ietf.org/html/draft-gomez-lwig-tcp-constrained-node-networks-03
Htmlized:  
https://datatracker.ietf.org/doc/html/draft-gomez-lwig-tcp-constrained-node-networks-03
Diff:  
https://www.ietf.org/rfcdiff?url2=draft-gomez-lwig-tcp-constrained-node-networks-03

Abstract:
   This document provides a profile for the Transmission Control
   Protocol (TCP) over Constrained-Node Networks (CNNs).  The
   overarching goal is to offer simple measures to allow for lightweight
   TCP implementation and suitable operation in such environments.




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.

The IETF Secretariat



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

[Lwip] [Fwd: New Version Notification for draft-gomez-lwig-tcp-constrained-node-networks-02.txt]

[Carles Gomez Montenegro]

Dear all,

We have submitted version -02 of the "TCP over Constrained-Node Networks"
draft. Please find pointers to the updated document below.

Cheers,

Carles

 Original Message 
Subject: New Version Notification for
draft-gomez-lwig-tcp-constrained-node-networks-02.txt
From:internet-dra...@ietf.org
Date:Sat, March 11, 2017 8:33 am
To:  "Jon Crowcroft" 
 "Carles Gomez" 
--


A new version of I-D, draft-gomez-lwig-tcp-constrained-node-networks-02.txt
has been successfully submitted by Carles Gomez and posted to the
IETF repository.

Name:   draft-gomez-lwig-tcp-constrained-node-networks
Revision:   02
Title:  TCP over Constrained-Node Networks
Document date:  2017-03-10
Group:  Individual Submission
Pages:  15
URL:   
https://www.ietf.org/internet-drafts/draft-gomez-lwig-tcp-constrained-node-networks-02.txt
Status:
https://datatracker.ietf.org/doc/draft-gomez-lwig-tcp-constrained-node-networks/
Htmlized:  
https://tools.ietf.org/html/draft-gomez-lwig-tcp-constrained-node-networks-02
Diff:  
https://www.ietf.org/rfcdiff?url2=draft-gomez-lwig-tcp-constrained-node-networks-02

Abstract:
   This document provides a profile for the Transmission Control
   Protocol (TCP) over Constrained-Node Networks (CNNs).  The
   overarching goal is to offer simple measures to allow for lightweight
   TCP implementation and suitable operation in such environments.




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.

The IETF Secretariat



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

Re: [Lwip] [tcpm] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt]

[Carles Gomez Montenegro]

Hi Fred,

Thank you very much for the great feedback!

> That's an amazing CC list :-) I would suggest moving to expertly one of
> those working groups.

Yes... :-)

(Still, keeping LWIG and TCPM...)

> Carsten's comment that TCP sessions are likely to be asymmetric, with a
> constrained node talking to an unconstrained node, is an important one.
> This seems like an excellent place to note the Robustness Principle -
> "conservative in what you send, liberal in what you receive". If the
> constrained node is limited to a profile like yours, and a peer tries to
> negotiate the use of other options, or simply sends other options, you
> want the CNN to act on what it understands and ignore the rest.

Yes, I agree that the implications of this asymmetric scenario have to be
highlighted, and also agree with the direction you indicate.

> There are a couple of constants in the draft that caught my attention.
>
> I imagine that the reason for a fixed effective window of one packet is to
> limit the issues with packet resequencing and congestion control. I think
> you still want to facilitate the Fast Recovery heuristic, which requires
> that you support an effective window of five. To work that through, later
> name the packets in a given transmission burst A through F, and presume
> that B gets lost. The sender should get an acknowledgement for A when C
> arrives and duplicate acknowledgements when D, E, and F arrive. It will
> retransmit B when the third duplicate ack arrives. In order to have B, C,
> D, E, and F sent, the window has to be at least five.
>
> I can see making that optional, but I don't think it should be precluded.

The reason for originally proposing a fixed effective window of one packet
is simplicity. There have been concerns in IoT-related WGs regarding the
'complexity' of TCP, and I remember specific comments expressing a goal
for the confirmable functionality in CoAP to be simple, and to avoid
'reproducing TCP complexity in CoAP'.

As the current stop-and-wait approach for CoAP confirmable messages seems
to be acceptable for the CoAP community, our draft aims to show how a
similar behavior can be achieved also with TCP (now that CoAP can also be
used over TCP).

Nevertheless, I agree that a 'MUST' for the stop-and-wait approach is
maybe a bit radical. Maybe one option could be to recommend this operation
without precluding the use of greater window sizes (in terms of segments),
e.g. to benefit from mechanisms such as Fast Recovery if people want to
use them?

Cheers,

Carles


> The two hour lifetime of a session also seems heavy-handed (and I would
> say the same about a two hour minimum keep-alive interval). I might
> suggest that the implementor or operator should figure out how many TCP
> peers a given system is likely to end to communicate with on a regular
> basis (the number of TCP-based application instances it runs being a
> possible guideline for that), and be required to have at least that many
> TCBs plus one. It should then allocate a TCB to a new session from that
> pool on an LRU basis, so that TCBs associated with active sessions tend to
> stay open. If you do that, I don't think you need to specify anything
> about session duration.
>
> My two yen...
>


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

Re: [Lwip] [core] [tcpm] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt]

[Carles Gomez Montenegro]

Hi Abhijan,

(Keeping the lists included as destinations, sorry for multiple copies...)

Thank you very much for your feedback. Please find some inline comments
below:

> Hi,
>
> Section 3.4 of the draft states the following:
>
> "it is envisaged that further segment exchanges will take place within an
> interval of two hours since the last segment has been sent"

Actually, the complete sentence is:

   'In CNNs, a TCP connection SHOULD be kept open as long as the two TCP
   endpoints have more data to exchange or it is envisaged that further
   segment exchanges will take place within an interval of two hours
   since the last segment has been sent.'

So the 'as long as' still precedes the sentence you have pointed out.
Anyway, prepending an 'if' to the sentence may help clarify the text.

By the way, the two-hour value (influenced by the default keep-alive
timer) was chosen here as a trade-off between avoiding too frequent TCP
connection establishment overhead and avoiding to keep unused state in
constrained devices for too long.

> Could you please explain a bit about the basis of such a deterministic
> assumption? If you could share some pointers to any study related to this.
> There is RFC 5382 which kind of mandates that the time out cannot be less
> than 124 minutes. Does it drive the above assumption? However, not sure
> how many implementations adheres to the time mentioned in RFC 5382.

RFC 5382 (which is very relevant for this draft) requires NATs not to
remove state for a live connection, ensuring that 'applications can send
keep-alive packets at the default rate (every 2 hours)'. So the two-hour
default keep-alive timer is also influencing the 124-minute time out
mentioned in RFC 5382.

> In the recent time I had been looking at the different efforts that has
> gone into improving TCP performance from different aspects under different
> circumstances since the early days. Given the short transactional type of
> exchanges, would it be also worthwhile to count experimental RFCs like
> "TCP Fast Open" and see how CoAP performs on top of it?

I agree that this is something to look at.

TCP Fast Open allows data to be carried in the SYN (and SYN-ACK) packet(s)
and consumed by the receiving end during the initial connection handshake.

However, TCP Fast Open involves an initial RTT for requesting a
4-to-16-byte cookie, which is then included in the Fast Open option of the
SYN segment of new connections. Furthermore, the cookie needs to be
updated (I'm not sure how often) for security.

TCP Fast Open can benefit applications that open 'many' new connections,
while the approach proposed in our draft is to keep a TCP connection open
for long time, avoiding connection establishment as much as possible.

If a TCP connection is kept open for long time, the possible benefits
(which, in my opinion, are not so clear considering all of the above) of
TCP Fast Open will become asymptotically negligible.

Cheers,

Carles


> Regards
> Abhijan Bhattacharyya


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

Re: [Lwip] [core] [tcpm] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt]

[Carles Gomez Montenegro]

Hi Ari,

Thank you very much for your feedback, and sorry for the late response.
Please find below a few inline comments:

>> By the way, currently the phrasing in the draft is that a window size of
>> one 'MUST' be used. This keeps a behavior equivalent to that of CoAP for
>> confirmable messages in RFC 7252, and dramatically simplifies
>> implementations. However, I wonder if some more freedom should be
>> offered,
>> and maybe the 'MUST' could become a 'SHOULD', at the expense of opening
>> the door to greater complexity... I personally tend to prefer the first
>> approach, but it would be great to receive more feedback on this!
>
> I like the simplicity too and would envision using that in cases where I'm
> using TCP for middlebox traversal cases. On the other hand, when doing
> something like firmware update for not-that-constrained device over long
> RTT link, this restriction could bite back big time. That makes me wonder
> if it would make sense to be able to indicate the capability for doing
> window bigger than 1 e.g., in RD registration.

I see your point...

Yes, firmware updates may suffer from a stop-and-wait behaviour (specially
for high RTT scenarios).

On the other hand, how are firmware updates being done today?
(Is it that e.g. CoAP with block is used over UDP, which would be
stop-and-wait by default, or are people using 'enhanced' settings such as
NSTART > 1?)

If TCP with a window of one segment is used, performance would be
relatively similar to that of CoAP (with NSTART=1) over UDP (although the
CoAP/TCP headers are larger than CoAP/UDP headers).

Cheers,

Carles


> Cheers,
> Ari
>
>


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

Re: [Lwip] [core] [tcpm] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt]

[Carles Gomez Montenegro]

Hi Wei,

> Hi Carles,
>
> I will give some comments as we have been doing both CoAP over Websocket
> and
> CoAP over TCP by extending Califorium.

Thanks a lot!

> I agree Carsten that CoAP over TCP will be used in the cloud and may also
> be
> in less-constrained networks.
> It is hard to say  that CoAP over TCP will be used in Constrained
> Networks.

There exist relevant examples such as:
https://www.ietf.org/proceedings/87/slides/slides-87-lwig-6.pdf

It could be that, within the constrained-node network space, TCP is used
rather in class 2 devices. However, we would need to collect more data to
be able to confirm this.

On the other hand, in our opinion, the CoAP over TCP activity may increase
the number of constrained devices using TCP (probably, in the 'constrained
device' to 'cloud' scenario).

Thanks again!

Best regards,

Carles



> Rgards,
>
> Gengyu WEI
> Network Technology Center
> School of Computer
> Beijing University of Posts and Telecommunications
> -----原始邮件-
> From: Carles Gomez Montenegro
> Sent: Friday, June 10, 2016 11:10 PM
> To: Carsten Bormann
> Cc: lwip@ietf.org ; t...@ietf.org Extensions ; jon.crowcr...@cl.cam.ac.uk
> ;
> c...@ietf.org WG
> Subject: Re: [core] [tcpm] [Lwip] [Fwd: New Version Notification for
> draft-gomez-core-tcp-constrained-node-networks-00.txt]
>
> Hi Carsten,
>
> Thanks a lot for your comments.
>
> While we work to address those, it would be really helpful if folks that
> have faced 'bad constrained TCP implementations', and/or have struggled
> with middlebox traversal can share their experience.
>
> Cheers,
>
> Carles
>
>
>> Carles,
>>
>> thanks for submitting this.
>>
>> I think that this draft is truly best handled in LWIG.
>>
>> We don't *have* to profile TCP for CoAP-over-TCP; people are free to use
>> whatever parts of TCP they think are useful.  (And, of course, there are
>> applications for CoAP-over-TCP that are in the backend.)
>>
>> On the other hand, it is useful to
>> -- manage expectations:
>>what can I expect that the *other* side will offer in TCP
>> functionality
>> -- give advice to implementers:
>>what is useful to implement, what not
>> -- collect implementation experience that is relevant for these two
>>
>> (One interesting effect I'm seeing is that people know how good TCP can
>> be, which shapes their expectations, but then they are hurt by using
>> really bad constrained TCP implementations...  We certainly should be
>> paying attention to this on the CoRE WG side.)
>>
>> My biggest comment is probably that for device-to-cloud, the level of
>> TCP functions implemented will be asymmetric (full TCP on cloud side,
>> possibly more limited on the device side) -- what is the effect of this
>> asymmetry?
>>
>> Maybe there also needs to be more discussion on the role of the
>> middlebox (after all, we are doing CoAP-over-TCP to devices for the sole
>> reason to climb over middleboxes).
>>
>> Grüße, Carsten
>>
>>
>> Scharf, Michael (Nokia - DE) wrote:
>>> Heads-up
>>>
>>> Michael
>>>
>>>
>>> -Original Message-
>>> From: Lwip [mailto:lwip-boun...@ietf.org] On Behalf Of Carles Gomez
>>> Montenegro
>>> Sent: Friday, June 10, 2016 11:36 AM
>>> To: lwip@ietf.org
>>> Cc: jon.crowcr...@cl.cam.ac.uk
>>> Subject: [Lwip] [Fwd: New Version Notification for
>>> draft-gomez-core-tcp-constrained-node-networks-00.txt]
>>>
>>> Dear LWIG WG,
>>>
>>> /** Apologies for possibly multiple similar e-mails... **/
>>>
>>> We have just submitted the draft entitled 'TCP over Constrained-Node
>>> Networks', which we believe may be of interest to the members of this
>>> group.
>>>
>>> We would like to kindly ask for feedback, specially on the basis of
>>> implementation experience.
>>>
>>> Thank you very much!
>>>
>>> Kind regards,
>>>
>>> The authors
>>>
>>>
>>>  Original Message
>>> 
>>> Subject: New Version Notification for
>>> draft-gomez-core-tcp-constrained-node-networks-00.txt
>>> From:internet-dra...@ietf.org
>>> Date:Fri, June 10, 2016 10:38 am
>>> To:  "Jon Crowcroft" <jon.crowcr...@cl.cam.ac.uk>
>>>  "Carles Gomez" <carle...@entel.upc.edu>
>>> --
>>

[Lwip] [Fwd: I-D Action: draft-ietf-lwig-energy-efficient-04.txt]

[Carles Gomez Montenegro]

Dear WG,

A new revision of the "energy efficient" draft is available. This revision
includes changes as a result of comments received during WGLC.

To the chairs: how should we proceed next?

Thanks!

Carles



 Original Message 
Subject: [Lwip] I-D Action: draft-ietf-lwig-energy-efficient-04.txt
From:internet-dra...@ietf.org
Date:Thu, February 25, 2016 10:48 am
To:  i-d-annou...@ietf.org
Cc:  lwip@ietf.org
--


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 of
the IETF.

Title   : Energy-Efficient Features of Internet of Things
Protocols
Authors : Carles Gomez
  Matthias Kovatsch
  Hui Tian
  Zhen Cao
Filename: draft-ietf-lwig-energy-efficient-04.txt
Pages   : 21
Date: 2016-02-25

Abstract:
   This document describes the problems and current practices of energy
   efficient protocol operation on constrained devices.  It summarizes
   the main link layer techniques for energy efficient networking, and
   it highlights the impact of such techniques on the upper layer
   protocols, so that they can coordinately achieve an energy efficient
   behavior.  The document also provides an overview of energy efficient
   mechanisms available at each layer of the constrained node network
   IETF protocol suite.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lwig-energy-efficient/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-lwig-energy-efficient-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-energy-efficient-04


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


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

Re: [Lwip] I-D Action: draft-ietf-lwig-energy-efficient-03.txt

[Carles Gomez Montenegro]

Dear WG,

We just submitted a new version of the Energy efficient draft.

Changes in this version:

- New subsection on power save services available in DECT ULE (contributed
by Jens T. Petersen in collaboration with the DECT ULE I-D team. Thanks!)

- Minor editorial changes.

Please note that, regarding the discussion on IEEE 802.15.4e DSME, since
there has not been feedback on the commercial significance of this mode,
it has not been covered in this version.

Finally, since we believe this new version addresses the comments received
in Dallas, we would like to request again whether a Working Group Last
Call can be issued for the draft.

Thanks!

Carles




 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
 Working Group of the IETF.

 Title   : Energy Efficient Implementation of IETF
 Constrained Protocol Suite
 Authors : Zhen Cao
   Carles Gomez
   Matthias Kovatsch
   Hui Tian
   Xuan He
   Filename: draft-ietf-lwig-energy-efficient-03.txt
   Pages   : 21
   Date: 2015-05-19

 Abstract:
This document summarizes the problems and current practices of energy
efficient protocol implementation on constrained devices, mostly
about how to make the protocols within IETF scope behave energy
friendly.  This document also summarizes the impact of link layer
protocol power saving behaviors to the upper layer protocols, so that
they can coordinately make the system energy efficient.


 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-lwig-energy-efficient/

 There's also a htmlized version available at:
 https://tools.ietf.org/html/draft-ietf-lwig-energy-efficient-03

 A diff from the previous version is available at:
 https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-energy-efficient-03


 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



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

Re: [Lwip] I-D Action: draft-ietf-lwig-energy-efficient-02.txt

[Carles Gomez Montenegro]

Dear Dominique,

Great, thanks a lot for your offer to provide the section on DECT-ULE!

By the way, please let us know whether your request in Dallas to add text
on the DSME mode of 15.4 would be satisfied by prepending the following
text to the current last paragraph/sentence of 3.5.3:

   Another relevant 802.15.4e mode is the Deterministic and Synchronous
   Multi-channel Extension (DSME). This mode improves the CFP functionality
   in IEEE 802.15.4 by extending the number of time slots that can be
   reserved for contentionless data transmission, and allowing the use of
   frequency channel diversity (note that TSCH offers similar
   functionality). DSME also favors the formation of beacon-enabled
   multihop networks. DSME defines a structure by which the beacon interval
   comprises a number of multi-superframes. Each one of the latter
   comprises a number of superframes. Each superframe in DSME may contain a
   CAP interval and must contain at least one CFP interval. As in TSCH
   mode, during unscheduled CFP time slots, nodes may keep their radio in
   inactive mode to save energy.

I believe once we add the text on DSME and the section on DECT-ULE, and
after applying some further typo corrections, we will be ready for
submitting a -03.

Best regards,

Carles



 Dear Carles, WG,

 As I mentioned during the meeting in Dallas, we would like to add a
 section 3.5.x on DECT-ULE.
 We will provide text within about a week.
 With best regards,

 Dominique

 -Message d'origine-
 De : Lwip [mailto:lwip-boun...@ietf.org] De la part de Carles Gomez
 Montenegro
 Envoyé : samedi 7 mars 2015 16:53
 À : lwip@ietf.org
 Objet : Re: [Lwip] I-D Action: draft-ietf-lwig-energy-efficient-02.txt

 Dear WG,

 As you have seen, version -02 of draft-ietf-lwig-energy-efficient is now
 available.

 The main changes are:

   - The feedback collected during IETF'91 is now incorporated into the
 document (mainly in subsection 6.2).

   - The Cross Layer Optimization section has been removed.

   - Subsections 3.3 and 3.4 have been added.

   - A new paragraph has been added in Subsection 3.5.1.

   - Other minor technical changes throughout the document.

   - Editorial improvements.


 I would like to ask for a 15-min slot in Dallas to present this update.

 Thanks,

 Carles



 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
 Working Group of the IETF.

 Title   : Energy Efficient Implementation of IETF
 Constrained Protocol Suite
 Authors : Zhen Cao
   Carles Gomez
   Matthias Kovatsch
   Hui Tian
   Xuan He
  Filename: draft-ietf-lwig-energy-efficient-02.txt
  Pages   : 19
  Date: 2015-03-07

 Abstract:
This document summarizes the problems and current practices of energy
efficient protocol implementation on constrained devices, mostly
about how to make the protocols within IETF scope behave energy
friendly.  This document also summarizes the impact of link layer
protocol power saving behaviors to the upper layer protocols, so that
they can coordinately make the system energy efficient.


 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-lwig-energy-efficient/

 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-lwig-energy-efficient-02

 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-energy-efficient-02


 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



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

 _

 Ce message et ses pieces jointes peuvent contenir des informations
 confidentielles ou privilegiees et ne doivent donc
 pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
 recu ce message par erreur, veuillez le signaler
 a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
 electroniques etant susceptibles d'alteration,
 Orange decline toute responsabilite si ce message a ete altere, deforme ou
 falsifie. Merci.

 This message and its attachments may contain confidential or privileged
 information that may be protected by law;
 they should not be distributed, used or copied without authorisation.
 If you have received

Re: [Lwip] 15.4e DSME ?

[Carles Gomez Montenegro]

+1

Let's see if anyone can provide a response to Dominique's question.
Otherwise, I agree it would be better not to add the DSME text.

Best regards,

Carles


 Dear Carles,

 From my reading of 15.4e-2012, I reckon the text you suggest on DSME is
 technically correct, and I second it.
 At the meeting in Dallas, I was also asking about the commercial
 significance of DSME.
 Does anybody know of equipment on the market today or under development
 that uses DSME? Just out of curiosity.
 I would think that those of this group that also go to 802.15 meetings
 would know who the forces behind DSME are, and what their intentions are.
 If we were to establish that DSME is not going to be used after all, at
 least not with an IP protocol stack, then adding the text that describes
 DSME in this draft would be a moot point.


 Best regards

 Dominique

 -Message d'origine-
 De : Carles Gomez Montenegro [mailto:carle...@entel.upc.edu]
 Envoyé : mercredi 1 avril 2015 15:15
 À : BARTHEL Dominique IMT/OLPS
 Cc : lwip@ietf.org; Jens Toftgaard Petersen (j...@rtx.dk); van de Logt,
 Marco marco.van-de-l...@gigaset.com (marco.van-de-l...@gigaset.com);
 Zach Shelby zach.she...@arm.com (zach.she...@arm.com); Peter Mariager
 (p...@rtx.dk)
 Objet : RE: [Lwip] I-D Action: draft-ietf-lwig-energy-efficient-02.txt

 Dear Dominique,

 Great, thanks a lot for your offer to provide the section on DECT-ULE!

 By the way, please let us know whether your request in Dallas to add text
 on the DSME mode of 15.4 would be satisfied by prepending the following
 text to the current last paragraph/sentence of 3.5.3:

Another relevant 802.15.4e mode is the Deterministic and Synchronous
Multi-channel Extension (DSME). This mode improves the CFP
 functionality
in IEEE 802.15.4 by extending the number of time slots that can be
reserved for contentionless data transmission, and allowing the use of
frequency channel diversity (note that TSCH offers similar
functionality). DSME also favors the formation of beacon-enabled
multihop networks. DSME defines a structure by which the beacon
 interval
comprises a number of multi-superframes. Each one of the latter
comprises a number of superframes. Each superframe in DSME may contain
 a
CAP interval and must contain at least one CFP interval. As in TSCH
mode, during unscheduled CFP time slots, nodes may keep their radio in
inactive mode to save energy.

 I believe once we add the text on DSME and the section on DECT-ULE, and
 after applying some further typo corrections, we will be ready for
 submitting a -03.

 Best regards,

 Carles



 Dear Carles, WG,

 As I mentioned during the meeting in Dallas, we would like to add a
 section 3.5.x on DECT-ULE.
 We will provide text within about a week.
 With best regards,

 Dominique

 -Message d'origine-
 De : Lwip [mailto:lwip-boun...@ietf.org] De la part de Carles Gomez
 Montenegro Envoyé : samedi 7 mars 2015 16:53 À : lwip@ietf.org Objet :
 Re: [Lwip] I-D Action: draft-ietf-lwig-energy-efficient-02.txt

 Dear WG,

 As you have seen, version -02 of draft-ietf-lwig-energy-efficient is
 now available.

 The main changes are:

   - The feedback collected during IETF'91 is now incorporated into the
 document (mainly in subsection 6.2).

   - The Cross Layer Optimization section has been removed.

   - Subsections 3.3 and 3.4 have been added.

   - A new paragraph has been added in Subsection 3.5.1.

   - Other minor technical changes throughout the document.

   - Editorial improvements.


 I would like to ask for a 15-min slot in Dallas to present this update.

 Thanks,

 Carles



 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 Working Group of the IETF.

 Title   : Energy Efficient Implementation of IETF
 Constrained Protocol Suite
 Authors : Zhen Cao
   Carles Gomez
   Matthias Kovatsch
   Hui Tian
   Xuan He
 Filename: draft-ietf-lwig-energy-efficient-02.txt
 Pages   : 19
 Date: 2015-03-07

 Abstract:
This document summarizes the problems and current practices of
 energy
efficient protocol implementation on constrained devices, mostly
about how to make the protocols within IETF scope behave energy
friendly.  This document also summarizes the impact of link layer
protocol power saving behaviors to the upper layer protocols, so
 that
they can coordinately make the system energy efficient.


 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-lwig-energy-efficient/

 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-lwig-energy-efficient-02

 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2

Re: [Lwip] I-D Action: draft-ietf-lwig-energy-efficient-02.txt

[Carles Gomez Montenegro]

Dear WG,

As you have seen, version -02 of draft-ietf-lwig-energy-efficient is now
available.

The main changes are:

  - The feedback collected during IETF'91 is now incorporated into the
document (mainly in subsection 6.2).

  - The Cross Layer Optimization section has been removed.

  - Subsections 3.3 and 3.4 have been added.

  - A new paragraph has been added in Subsection 3.5.1.

  - Other minor technical changes throughout the document.

  - Editorial improvements.


I would like to ask for a 15-min slot in Dallas to present this update.

Thanks,

Carles



 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
 Working Group of the IETF.

 Title   : Energy Efficient Implementation of IETF
 Constrained Protocol Suite
 Authors : Zhen Cao
   Carles Gomez
   Matthias Kovatsch
   Hui Tian
   Xuan He
   Filename: draft-ietf-lwig-energy-efficient-02.txt
   Pages   : 19
   Date: 2015-03-07

 Abstract:
This document summarizes the problems and current practices of energy
efficient protocol implementation on constrained devices, mostly
about how to make the protocols within IETF scope behave energy
friendly.  This document also summarizes the impact of link layer
protocol power saving behaviors to the upper layer protocols, so that
they can coordinately make the system energy efficient.


 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-lwig-energy-efficient/

 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-lwig-energy-efficient-02

 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-energy-efficient-02


 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



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

[Lwip] Question to the WG

[Carles Gomez Montenegro]

Dear WG members,

On behalf of the authors of draft-ietf-lwig-energy-efficient, and as per
the suggestion of co-chair Zhen Cao during the LWIG meeting in Toronto, I
would like to ask the WG list a question on which should be the approach
for Section 3 of draft-ietf-lwig-energy-efficient.

Section 3 aims at describing the techniques used by low-power radio
technologies in order to save energy. Currently, the section comprises an
introduction and three subsections, which focus on 802.11v, Bluetooth Low
Energy and IEEE 802.15.4.

Our question is: should we try to be comprehensive and cover as many
technologies relevant to the IETF (e.g. those currently considered for
IPv6 support in the 6lo WG) as possible?  Or instead, should we provide a
few examples of specific technologies (as is currently in Section 3) and
try to summarize their most relevant and common aspects?

Please let us know your opinion on this question.

Thanks!

Carles

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

Re: [Lwip] draft-ietf-lwig-energy-efficient-00

[Carles Gomez Montenegro]

Hi Hannes,

First of all, thanks for your review, comments and suggestions.

Please find a few inline replies:

 Hi all,

 I took a quick look at this document. Clearly this is an important topic
 but it is also challenging.

 When this topic was brought up at the IAB smart object workshop I was
 thinking about what guidelines I would offer and I came up with very few
 ideas. So, I was very interested to see what the authors have to say
 about this topic.

 A few aspects came to my mind when reading the document:

 a) The current discussion seems to focus on a single study only. I hope
 that's not true and the authors have done some studies themselves as
 well.

There exist several other studies (some of which involve coauthors of the
draft). I agree that a wider range of studies should be considered in
order to derive common issues and important details which might be
generalized, as well as aspects that might not.

 It is also heavily focused on energy consumption of networking
 only. RAM costs energy. Computations cost energy. Even sleeping costs
 energy. For embedded hardware there is not just a binary sleep/awake
 mode but many intermediate steps.

Agreed. We can provide information regarding these aspects.

 b) The comparison between different radio technologies would require far
 more details to be useful since there are many parameters that have an
 impact on the overall energy consumption. Selecting the right set of
 parameters also assumes that you understand the radio technique very well.

I don't think we are trying to do a comparison. Nevertheless, which kind
of details do you feel would be needed? When you talk about parameters, do
you mean parameters of the radio technologies (i.e. mainly PHY/MAC
parameters)?

 c) This is mostly a non-IETF topic. The IETF does not design radio
 technologies, nor does it impact the hardware design or focus on
 implementations. I agree with the statement that it is good to know the
 behaviors of lower layers. What would, however, then be needed is a
 tutorial on various radio technologies since they are often written in a
 way that is very different from IETF specifications and somewhat hard to
 understand for IETF-minded folks. There is text in there in Section 3
 about the different radios but it is too short to be understood by
 someone who does not yet already know the specific radio technology
 anyway. Why did you pick those three radios and not others?

I believe the description of the radios can be extended.

Regarding your (good) question, I think other relevant radios can very
well be added to Section 3, and actually the draft is in progress. I am
not sure to what extent Section 3 has to be comprehensive technology-wise.
Of course, technologies considered in the 6lo WG are candidates. However,
there are two approaches: i) being comprehensive, or ii) trying to cover
what seem to be the most common low-power techniques used by these radios.
What would the WG prefer?

 As an example, the text about Bluetooth Low Energy (which has been
 renamed to Bluetooth Smart)

(Yes, the Bluetooth SIG has introduced these trademarks, while the recent
Bluetooth 4.1 specification still uses the name Bluetooth Low Energy.)

 does not provide the reader much insight
 into the implications for the protocol design. Bluetooth Smart is
 different from Bluetooth and the specification defines an entire
 protocol stack. The required energy of a device depends on the function
 and on the parameter setting at each layer. Hence, it is a bit difficult
 to just focus on master / slave (terminology used for only one layer).

The section about BT-LE tries to focus on the layers relevant for using IP
over BT-LE. As per draft-ietf-6lo-btle-02, the 6LoWPAN layer is placed on
top of a stack composed of L2CAP (which in BLE provides upper layer
multiplexing and fragmentation/reassembly), Link Layer and Physical Layer.
From these layers, the main configurable parameters with a highly
significant impact on energy (and other parameters) performance are those 
from the Link Layer which the section focuses on.

Also, the master/slave terminology has its nature at the Link Layer (and
corresponds to the central and peripheral GAP roles), but is key to
understand the role of a device in a BT-LE network.

 It might also be worth pointing out that not all radio technologies used
 today are actually using IP. Bluetooth Smart is a good example that
 enjoys widespread deployment but there is almost no IP there since the
 wireless communication more or less replaces cables.

Well, we are trying to change that with draft-ietf-6lo-btle, as well as
with the other efforts of the 6lo WG. ;)

 d) The sections about routing protocols(Section 5), application layer
 (Section 6) and Cross Layer Optimization (Section 7) are currently a bit
 empty. It is also not clear whether you will be able to say too much
 there either.

Agreed. Although some information about possible cross-layer interactions
is already in some