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

[Abhijan Bhattacharyya <[e-mail]>]

Hey Michael,
Got it. Thanks a lot.

On 17 Oct 2017 00:25, "Scharf, Michael (Nokia - DE/Stuttgart)" <
[e-mail]> 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>
>
>   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:[e-mail]] *On Behalf Of *Abhijan
> Bhattacharyya
> *Sent:* Monday, October 16, 2017 12:25 PM
> *To:* [e-mail]
> *Cc:* [e-mail]; Abhijan Bhattacharyya <[e-mail]>;
> [e-mail]
> *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, <[e-mail]> wrote:
>
>
> 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/
>
> _______________________________________________
> Lwip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lwip
>
>
>
>
> --
>
> Regards,
>
> Abhijan Bhattacharyya,
>
> *Scientist @ TCS Research, India*
>