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 protected]] On Behalf Of Abhijan Bhattacharyya Sent: Monday, October 16, 2017 12:25 PM To: [email protected] Cc: [email protected]; Abhijan Bhattacharyya <[email protected]>; [email protected] 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 protected]<mailto:[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<http://tools.ietf.org>. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Lwip mailing list [email protected]<mailto:[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
