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 protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/lwip > -- Regards, Abhijan Bhattacharyya, *Scientist @ TCS Research, India*
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
