Return-Path: X-Original-To: lwip@ietfa.amsl.com Delivered-To: lwip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09AC12008A; Mon, 16 Oct 2017 03:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Hn167fw8nz8; Mon, 16 Oct 2017 03:24:42 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B181321CB; Mon, 16 Oct 2017 03:24:41 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id b11so9341594uae.12; Mon, 16 Oct 2017 03:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u20r1Pmg8kJtWo3fTgpAvJMTeDOg376+kb1guYrSQZA=; b=mMUynRp6pvvGeRUIjfV3vKxWy2dcUiW7cRtuL0PPDb6e7M+j//Z37jm8wOzDEhu52R /h+gJKKCxvGgqloLKFTMEaoWdGgINmCSZlpwgECRQ5IuAB91gYsrVfVufrw0qR4JViBX BgGTwpJ5Uun4AbY5y+AOeypNK6uJ4ftIR9qPxXkp57x4dhuqtXLI+H7xaVshmmEgf+bL HGBYPxmWBOp9E68afIAerN1XqGK5rZzpLabfPcwrQEUJhFx57+mjqBvote9eeBNPjbvh kn7Tj7pNTG6JD6xRDi4nP8ftkc6RZ0s6MDGrwPBhh6DmqAXYmfoVpzSYdUFbBeiASy// ZYlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u20r1Pmg8kJtWo3fTgpAvJMTeDOg376+kb1guYrSQZA=; b=tNuWu+IHR7uceyqUPDLJ/RzPiibxU58Vt86OIibX08w85gCJTAhAHljLQ8960s3ivg dHwNtcVmFxI93DUaDVJlO/F4oWOMToFFRgUszkTNJv2GCtCeGu9Rdkl3XsAz9olVnh2U 5WLzwSipIcH7hfWrSuIzldGyHjgQ7UQl3nYYXAcNDXWBnJhcQTxULo+6gg4vHFsze5G3 pUBhoHbNWutjBUMqyynRougGtqdkHv1pOSpl1wH6SS9X4dYZX4dAktoCpsgLUhTrywcB xdsTsCGwTMVU38pN+68T7lNaQ4Ozx2X8oxr3YJf1ZaE4fbX1nR3vRdLnWHtzM3ZH3WEO y4hw== X-Gm-Message-State: AMCzsaW5aoLFhp18AXzkzDzUxmrBjlTUPzlIRI0mgcTP40ZcjJLo+8Ty OhmWkRM2OIG1Rrm8LP0vA8wmfGFgCSLu2/bKQk5DXw== X-Google-Smtp-Source: ABhQp+T4cwB4FesNnJXyinINFkApOWBjhaOpnd/li6Hg/l1TOJ61Z7/AD6UC2kSYtPA3+9LzHhJRN99XfySkvYcSQwM= X-Received: by 10.159.53.99 with SMTP id o90mr2883138uao.78.1508149480549; Mon, 16 Oct 2017 03:24:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.28.17 with HTTP; Mon, 16 Oct 2017 03:24:39 -0700 (PDT) In-Reply-To: <150809235685.12141.6306659248838809120@ietfa.amsl.com> References: <150809235685.12141.6306659248838809120@ietfa.amsl.com> From: Abhijan Bhattacharyya Date: Mon, 16 Oct 2017 15:54:39 +0530 Message-ID: To: internet-drafts@ietf.org Cc: i-d-announce@ietf.org, lwip@ietf.org, Abhijan Bhattacharyya Content-Type: multipart/alternative; boundary="94eb2c03cb4a0e739a055ba76ad9" Archived-At: Subject: Re: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-01.txt X-BeenThere: lwip@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Lightweight IP stack List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 10:24:45 -0000 --94eb2c03cb4a0e739a055ba76ad9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, =E2=80=9CTCP Behavior of a Busy Internet Server= : Analysis and Improvements =E2=80=9C, in Proc. Of IEEE Infocomm =E2=80=9998,= CA, USA, March, 1998. [2] N. Cardwell, et al, =E2=80=9CModeling the Performance of Short TCP Connections=E2=80=9D, Technical Report, University of Washington, October, = 1998 ( http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.30.2099&rep=3Dre= p1&type=3Dpdf ) [3] K. Avrachenkov, et al, =E2=80=9CDifferentiation between short and long = TCP flows: predictability of the response time=E2=80=9D, INFOCOM 2004 [4] N. Kartik, =E2=80=9CTCP optimized for short flows=E2=80=9D, Stanford Un= iversity, 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, =E2=80=9CEnhancing TCP'= s loss recovery using limited transmit=E2=80=9D , January, 2001. On Mon, Oct 16, 2017 at 12:02 AM, 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=3Ddraft-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 > Lwip@ietf.org > https://www.ietf.org/mailman/listinfo/lwip > --=20 Regards, Abhijan Bhattacharyya, *Scientist @ TCS Research, India* --94eb2c03cb4a0e739a055ba76ad9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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-author= s 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 g= eneralized class of problem related to TCP performance for short flows. Thi= s is an old problem and has been studied in many literatures (Example: [1-3= ]). The case for IoT is a specialization (the word "specialization&quo= t; would most likely attribute to the factors like scalability, h/w constra= ints, 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 technolog= ical issues under one umbrella that predominantly deals with constrained=C2= =A0 devices and networks.)

So, just check if y= ou can deliver the problem statement in a bit generalized manner if the abo= ve makes sense.

Coming to the problem with short flows, t= he basic problem is the sub-optimal performance of slow-start and non-avail= ability of enough duplicate ACKs (dupacks) to start the fast-retransmission= . Now , your draft very rightly takes into account the cases where the wind= ow may run over more than one (and only a few) MSS. While you have mentione= d about the utility of ECN and SACK, probably it would also be useful to me= ntion about the "limited transmit" algorithm [6]. I do not have r= eadily available statistics about its implementation in Kernels at present.= But, probably it is available. [6] essentially optimizes on how the fast r= e-transmit works for short-flows which do not run over enough segments to e= nsure sufficient number of dupacks to indicate a 'softer' congestio= n 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 enou= gh dupacks). Combination of SACK and [6] may benefit the system. However, I= do not have any readily available study on the performance benchmark for t= his. But it is an option worth keeping in this work, I think.
=C2=A0
=
Thank you.
Best wishes for your draft.
-------= -----------------
[1] H. Balakrishnan, et al, =E2=80=9CTCP Behavior of a= Busy Internet Server: Analysis and Improvements =E2=80=9C, in Proc. Of IEE= E Infocomm =E2=80=9998, CA, USA, March, 1998.
[2] N. Cardwell, et al, = =E2=80=9CModeling the Performance of Short TCP Connections=E2=80=9D, Techni= cal Report, University of Washington, October, 1998 (http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.30.2= 099&rep=3Drep1&type=3Dpdf )
[3] K. Avrachenkov, et al, =E2= =80=9CDifferentiation between short and long TCP flows: predictability of t= he response time=E2=80=9D, INFOCOM 2004
[4] N. Kartik, =E2=80=9CTCP opti= mized for short flows=E2=80=9D, 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 O= VERVIEW", October, 2015.
[6] M. Allman, H. Balakrishnan, S. Floyd, = RFC 3042, =E2=80=9CEnhancing TCP's loss recovery using limited transmit= =E2=80=9D , January, 2001.
=
On Mon, Oct 16, 2017 at 12:02 AM, <= internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Light-Weight Implementation Guidance WG of= the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= TCP Usage Guidance in the Internet of Things (IoT)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Carl= es Gomez
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jon Crowcroft
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Michael Scharf
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-lwig-tcp-constrained-node-networks-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-10-15

Abstract:
=C2=A0 =C2=A0This document provides guidance on how to implement and use th= e
=C2=A0 =C2=A0Transmission Control Protocol (TCP) in Constrained-Node Networ= ks
=C2=A0 =C2=A0(CNNs), which are a characterstic of the Internet of Things (I= oT).
=C2=A0 =C2=A0Such environments require a lightweight TCP implementation and= may
=C2=A0 =C2=A0not make use of optional functionality.=C2=A0 This document ex= plains a
=C2=A0 =C2=A0number of known and deployed techniques to simplify a TCP stac= k as
=C2=A0 =C2=A0well as corresponding tradeoffs.=C2=A0 The objective is to hel= p embedded
=C2=A0 =C2=A0developers with decisions on which TCP features to use.


The IETF datatracker status page for this draft is:
https://datatracker.i= etf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/
There are also htmlized versions available at:
https://tools.ietf.org/h= tml/draft-ietf-lwig-tcp-constrained-node-networks-01
https://datatr= acker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-netw= orks-01

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


Please note that it may take a couple of minutes from the time of submissio= n
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



--
Regards,
=
Abhijan Bhattacharyya,
Scientist @ TCS Rese= arch, India
--94eb2c03cb4a0e739a055ba76ad9--