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

From: [email-masked]
Date: Sun, 15 Oct 2017 11:32:36 -0700

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-01.txt
	Pages           : 20
	Date            : 2017-10-15

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

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

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/

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Mon, 16 Oct 2017 15:54:39 +0530

Hi Carles,
This is indeed an important piece of work. The fact that this draft is
maturing in tandem with the evolution of the CoAP-on-TCP darft is really
beneficial for the IoT technology space.
During the last Prague meeting I made some comments towards the end of the
presentation. I take this opportunity to put those comments in the mailing
list in a more organized form. See if you and your co-authors find them
useful.

One thing that I would like to stress upon is that, I would like to see TCP
in IoT as an inheritance of a more generalized class of problem related to
TCP performance for short flows. This is an old problem and has been
studied in many literatures (Example: [1-3]). The case for IoT is a
specialization (the word "specialization" would most likely attribute to
the factors like scalability, h/w constraints, etc.). In [4] one can find a
mathematical definition for short flows for TCP.

(In fact, going by [5], it will not be too wrong to say that IoT is
basically a culmination of different existing technological issues under
one umbrella that predominantly deals with constrained  devices and
networks.)

So, just check if you can deliver the problem statement in a bit
generalized manner if the above makes sense.

Coming to the problem with short flows, the basic problem is the
sub-optimal performance of slow-start and non-availability of enough
duplicate ACKs (dupacks) to start the fast-retransmission. Now , your draft
very rightly takes into account the cases where the window may run over
more than one (and only a few) MSS. While you have mentioned about the
utility of ECN and SACK, probably it would also be useful to mention about
the "limited transmit" algorithm [6]. I do not have readily available
statistics about its implementation in Kernels at present. But, probably it
is available. [6] essentially optimizes on how the fast re-transmit works
for short-flows which do not run over enough segments to ensure sufficient
number of dupacks to indicate a 'softer' congestion and thus prevents the
sender from going into the costly slow-start phase (as RTO remains the only
option to detect congestion in the absence of enough dupacks). Combination
of SACK and [6] may benefit the system. However, I do not have any readily
available study on the performance benchmark for this. But it is an option
worth keeping in this work, I think.

Thank you.
Best wishes for your draft.
------------------------
[1] H. Balakrishnan, et al, “TCP Behavior of a Busy Internet Server:
Analysis and Improvements “, in Proc. Of IEEE Infocomm ’98, CA, USA, March,
1998.
[2] N. Cardwell, et al, “Modeling the Performance of Short TCP
Connections”, Technical Report, University of Washington, October, 1998 (
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.30.2099&rep=rep1&type=pdf
)
[3] K. Avrachenkov, et al, “Differentiation between short and long TCP
flows: predictability of the response time”, INFOCOM 2004
[4] N. Kartik, “TCP optimized for short flows”, Stanford University, June
2003, (http://web.stanford.edu/class/ee384y/projects/download03/nitin3.pdf).
[5] Karen Rose, Scott Eldridge, Lyman Chapin, "THE INTERNETOF THINGS:AN
OVERVIEW", October, 2015.
[6] M. Allman, H. Balakrishnan, S. Floyd, RFC 3042, “Enhancing TCP's loss
recovery using limited transmit” , January, 2001.

On Mon, Oct 16, 2017 at 12:02 AM, <[email-masked]> wrote:

> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip
>

-- 
Regards,
Abhijan Bhattacharyya,
*Scientist @ TCS Research, India*

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Mon, 16 Oct 2017 18:28:50 +0000

Hi all,

Version -01 should address all recent feedback and comments. Here is an overview of the changes compared to -00:

   o  Changed title and abstract

   o  Clarification that communication with standard-compliant TCP endpoints is required, based on feedback from Joe Touch

   o  Additional discussion on communication patters

   o  Numerous changes to address a comprehensive review from Hannes Tschofenig

   o  Reworded security considerations

   o  Additional references and better distinction between normative and informative entries

   o  Feedback from Rahul Jadhav on the uIP TCP implementation

   o  Basic data for the TinyOS TCP implementation added, based on source code analysis

Please have a look at the new version and please feel free to comment.

Further extensions and improvements are planned for the next version.

Thanks

Michael

-----Original Message-----
From: Lwip [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, October 15, 2017 8:33 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-01.txt

Abstract:

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.

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Mon, 16 Oct 2017 18:55:09 +0000

Hi Abhijan,

I fully agree that for some use cases basically the known TCP optimizations for short flows apply. Version -01 already includes quite some new wording on TCP stacks that use a window of some (few) MSS. The plan is to better organize that content in -02.

Specifically, version -01 already includes guidance regarding limited transmit in Section 4.3, in order to address your feedback from the Prague meeting:

<snip>
  For bulk data transfers further TCP improvements may also be useful, such as limited transmit [RFC3402].
</snip>

Yet, I now realize that there is a typo in this reference. Instead of RFC 3042, version -01 wrongly refers to RFC3402, which doesn’t make any sense ;-) I apologize for that mistake. This typo will be fixed in -02.

Of course, further comments would be welcome.

Thanks

Michael

From: Lwip [mailto:[email-masked]] On Behalf Of Abhijan Bhattacharyya
Sent: Monday, October 16, 2017 12:25 PM
To: [email-masked]
Cc: [email-masked]; Abhijan Bhattacharyya <[email-masked]>; [email-masked]
Subject: Re: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-01.txt

Hi Carles,
This is indeed an important piece of work. The fact that this draft is maturing in tandem with the evolution of the CoAP-on-TCP darft is really beneficial for the IoT technology space.
During the last Prague meeting I made some comments towards the end of the presentation. I take this opportunity to put those comments in the mailing list in a more organized form. See if you and your co-authors find them useful.
One thing that I would like to stress upon is that, I would like to see TCP in IoT as an inheritance of a more generalized class of problem related to TCP performance for short flows. This is an old problem and has been studied in many literatures (Example: [1-3]). The case for IoT is a specialization (the word "specialization" would most likely attribute to the factors like scalability, h/w constraints, etc.). In [4] one can find a mathematical definition for short flows for TCP.
(In fact, going by [5], it will not be too wrong to say that IoT is basically a culmination of different existing technological issues under one umbrella that predominantly deals with constrained  devices and networks.)

So, just check if you can deliver the problem statement in a bit generalized manner if the above makes sense.
Coming to the problem with short flows, the basic problem is the sub-optimal performance of slow-start and non-availability of enough duplicate ACKs (dupacks) to start the fast-retransmission. Now , your draft very rightly takes into account the cases where the window may run over more than one (and only a few) MSS. While you have mentioned about the utility of ECN and SACK, probably it would also be useful to mention about the "limited transmit" algorithm [6]. I do not have readily available statistics about its implementation in Kernels at present. But, probably it is available. [6] essentially optimizes on how the fast re-transmit works for short-flows which do not run over enough segments to ensure sufficient number of dupacks to indicate a 'softer' congestion and thus prevents the sender from going into the costly slow-start phase (as RTO remains the only option to detect congestion in the absence of enough dupacks). Combination of SACK and [6] may benefit the system. However, I do not have any readily available study on the performance benchmark for this. But it is an option worth keeping in this work, I think.

Thank you.
Best wishes for your draft.
------------------------
[1] H. Balakrishnan, et al, “TCP Behavior of a Busy Internet Server: Analysis and Improvements “, in Proc. Of IEEE Infocomm ’98, CA, USA, March, 1998.
[2] N. Cardwell, et al, “Modeling the Performance of Short TCP Connections”, Technical Report, University of Washington, October, 1998 (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.30.2099&rep=rep1&type=pdf )
[3] K. Avrachenkov, et al, “Differentiation between short and long TCP flows: predictability of the response time”, INFOCOM 2004
[4] N. Kartik, “TCP optimized for short flows”, Stanford University, June 2003, (http://web.stanford.edu/class/ee384y/projects/download03/nitin3.pdf).
[5] Karen Rose, Scott Eldridge, Lyman Chapin, "THE INTERNETOF THINGS:AN OVERVIEW", October, 2015.
[6] M. Allman, H. Balakrishnan, S. Floyd, RFC 3042, “Enhancing TCP's loss recovery using limited transmit” , January, 2001.

On Mon, Oct 16, 2017 at 12:02 AM, <[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

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<http://tools.ietf.org>.

_______________________________________________
Lwip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lwip

--
Regards,
Abhijan Bhattacharyya,
Scientist @ TCS Research, India

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Tue, 17 Oct 2017 00:34:19 +0530

Hey Michael,
Got it. Thanks a lot.

On 17 Oct 2017 00:25, "Scharf, Michael (Nokia - DE/Stuttgart)" <
[email-masked]> wrote:

> Hi Abhijan,
>
>
>
> I fully agree that for some use cases basically the known TCP
> optimizations for short flows apply. Version -01 already includes quite
> some new wording on TCP stacks that use a window of some (few) MSS. The
> plan is to better organize that content in -02.
>
>
>
> Specifically, version -01 already includes guidance regarding limited
> transmit in Section 4.3, in order to address your feedback from the Prague
> meeting:
>
>
>
> <snip>
>
> Yet, I now realize that there is a typo in this reference. Instead of RFC
> 3042, version -01 wrongly refers to RFC3402, which doesn’t make any sense
> ;-) I apologize for that mistake. This typo will be fixed in -02.
>
>
>
> *From:* Lwip [mailto:[email-masked]] *On Behalf Of *Abhijan
> Bhattacharyya
> *Sent:* Monday, October 16, 2017 12:25 PM
> *To:* [email-masked]
> *Cc:* [email-masked]; Abhijan Bhattacharyya <[email-masked]>;
> [email-masked]
> *Subject:* Re: [Lwip] I-D Action: draft-ietf-lwig-tcp-
> constrained-node-networks-01.txt
>
>
>
> Hi Carles,
>
> One thing that I would like to stress upon is that, I would like to see
> TCP in IoT as an inheritance of a more generalized class of problem related
> to TCP performance for short flows. This is an old problem and has been
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.
> 30.2099&rep=rep1&type=pdf )