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 1DDAE134315 for ; Mon, 16 Oct 2017 12:04:24 -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 tPeRgSkSUlMb for ; Mon, 16 Oct 2017 12:04:21 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 AD24F134563 for ; Mon, 16 Oct 2017 12:04:20 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id h34so10408223uaa.6 for ; Mon, 16 Oct 2017 12:04:20 -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=YmB7RCXe6Dl5f4lYQgfM68kPh4gqJgrHiJCKe7KROpQ=; b=CBgNkxj50w7UYjjuK454lWkFmXglOBjyEL8fzvHyXZXBTAF3eoPzoeooU96jvXY0JR f/jSc1FE9ZtTAqNGKIF3k21ARzhvt6jcv0A6pzFx5ivDxsdMDGPzoO9DZWZmfdXPcD98 Apbf7dysHQNHJ0kPwUATK+9WXc9PAzNNDeVTqnnIgkGfagFERPWpy1rSPKtFQJTyLZBr zdfPapviWdPfMC9QulUKkeuD7ysAwnTSgBasgYr/p6qk1j3ChTmP2l6lX56QmDgo4LNA U+GPI84hml698atMyUNHaOCYC7ciYDfUKlMMGw8TCQ6BPDIXeZB8GKcgs+12sNlCBUTT h8iw== 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=YmB7RCXe6Dl5f4lYQgfM68kPh4gqJgrHiJCKe7KROpQ=; b=XadugKZWhnedbCs7I8mSYOgq9nmpD6wy9h1YrLsTtvsdn6Ahw2h+rcBpgqOGbREP2L P0Ocx8MJ3IlSatEIWKLicZ9zM1qGh3J83Rj2adJuu+8f0MPtf964vUiFQI0Lg+WAU+AV RKyekXuz45JMhyJHbyRDwp7j4NS7zmYmsqNLVNGg0ia06Qt6mj3i9k42NELso9kTI5gD tayc++JhBd+B687OK36/yYaMeLuiX8Y13xmleuzx2KCXEuGBL55FF4VNsJsJJfi4YQmi Nyr5h/PLaFThfOvE/N9rhsQrhf2DN/sgqX1X6rLDKDTFbSy+NLbJwZRBVqkc106RefA7 MqHw== X-Gm-Message-State: AMCzsaVHHPPbrEoU2jUp59VywPKEiKqfwVJbhGsn/GpDCJKY5umQrOyE kGIBvWrq3AShuWZkbQT1t5PoVUtOXaMAdqyYWgc= X-Google-Smtp-Source: AOwi7QBO1Hj27TU1d7ld1KnTUl76vmaTnc99Z9rK4F9UL0ww/XUtoHjU32Lmodl/CIZPqEInKjATw6U1XLZtQADALjQ= X-Received: by 10.176.21.35 with SMTP id o32mr8219667uae.177.1508180659571; Mon, 16 Oct 2017 12:04:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.28.17 with HTTP; Mon, 16 Oct 2017 12:04:19 -0700 (PDT) Received: by 10.176.28.17 with HTTP; Mon, 16 Oct 2017 12:04:19 -0700 (PDT) In-Reply-To: References: <150809235685.12141.6306659248838809120@ietfa.amsl.com> From: Abhijan Bhattacharyya Date: Tue, 17 Oct 2017 00:34:19 +0530 Message-ID: To: "Scharf, Michael (Nokia - DE/Stuttgart)" Cc: Abhijan Bhattacharyya , lwip@ietf.org Content-Type: multipart/alternative; boundary="001a11428a547892ee055baeac7a" 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 19:04:24 -0000 --001a11428a547892ee055baeac7a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Michael, Got it. Thanks a lot. On 17 Oct 2017 00:25, "Scharf, Michael (Nokia - DE/Stuttgart)" < michael.scharf@nokia.com> 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 Pragu= e > meeting: > > > > > > For bulk data transfers further TCP improvements may also be useful, > such as limited transmit [RFC3402]. > > > > > > Yet, I now realize that there is a typo in this reference. Instead of RFC > 3042, version -01 wrongly refers to RFC3402, which doesn=E2=80=99t make a= ny 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:lwip-bounces@ietf.org] *On Behalf Of *Abhijan > Bhattacharyya > *Sent:* Monday, October 16, 2017 12:25 PM > *To:* internet-drafts@ietf.org > *Cc:* lwip@ietf.org; Abhijan Bhattacharyya ; > i-d-announce@ietf.org > *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 th= e > presentation. I take this opportunity to put those comments in the mailin= g > 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 relat= ed > 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 dra= ft > 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 abou= t > 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 sufficien= t > 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 on= ly > option to detect congestion in the absence of enough dupacks). Combinatio= n > of SACK and [6] may benefit the system. However, I do not have any readil= y > available study on the performance benchmark for this. But it is an optio= n > 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 Serv= er: > Analysis and Improvements =E2=80=9C, in Proc. Of IEEE Infocomm =E2=80=999= 8, 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=3Drep1&type=3Dpdf ) > [3] K. Avrachenkov, et al, =E2=80=9CDifferentiation between short and lon= g 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 = University, June > 2003, (http://web.stanford.edu/class/ee384y/projects/download03/nitin3.pd= f > ). > [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 TC= P'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 > > > > > -- > > Regards, > > Abhijan Bhattacharyya, > > *Scientist @ TCS Research, India* > --001a11428a547892ee055baeac7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Michael,
Got it. Thanks a lot.
=

On 17 Oct 2= 017 00:25, "Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com> wrote= :

Hi Abhijan,

=C2=A0

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.

=C2=A0

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

=C2=A0

<snip>

=C2=A0 For bulk data transfers further TCP improveme= nts may also be useful, such as limited transmit [RFC3402].

</snip>

=C2=A0

Yet, I now realize that there is a typo in this refe= rence. Instead of RFC 3042, version -01 wrongly refers to RFC3402, which do= esn=E2=80=99t make any sense ;-) I apologize for that mistake. This typo wi= ll be fixed in -02.

=C2=A0

Of course, further comments would be welcome.=

=C2=A0

Thanks

=C2=A0

Michael

=C2=A0

=C2=A0

=C2=A0

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 Pragu= e 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 organi= zed form. See if you and your co-authors find them useful.

One thing that I woul= d like to stress upon is that, I would like to see TCP in IoT as an inherit= ance 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 Io= T is a specialization (the word "specialization" would most likel= y 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=C2=A0 = devices and networks.)

=C2=A0

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 pr= oblem is the sub-optimal performance of slow-start and non-availability of = enough duplicate ACKs (dupacks) to start the fast-retransmission. Now , you= r 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 w= ould also be useful to mention about the "limited transmit" algor= ithm [6]. I do not have readily available statistics about its implementation in Kernels at present. But, probably i= t 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 t= he costly slow-start phase (as RTO remains the only option to detect conges= tion in the absence of enough dupacks). Combination of SACK and [6] may ben= efit 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.
=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 IEEE Infocomm =E2=80=999= 8, CA, USA, March, 1998.
[2] N. Cardwell, et al, =E2=80=9CModeling the Performance of Short TCP Conn= ections=E2=80=9D, Technical Report, University of Washington, October, 1998= (http://citeseerx.ist.= psu.edu/viewdoc/download?doi=3D10.1.1.30.2099&rep=3Drep1&= 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/c= lass/ee384y/projects/download03/nitin3.pdf).
[5] Karen Rose, Scott Eldridge, Lyman Chapin, "THE INTERNETOF THINGS:A= N OVERVIEW", October, 2015.
[6] M. Allman, H. Balakrishnan, S. Floyd, RFC 3042, =E2=80=9CEnhancing TCP&= #39;s loss recovery using limited transmit=E2=80=9D , January, 2001.=

=C2=A0

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.ietf.org/doc/dr= aft-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?u= rl2=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
ht= tps://www.ietf.org/mailman/listinfo/lwip




--

Regards,

Abhijan Bhattacharyya,

Scientist @ TCS Research, India

--001a11428a547892ee055baeac7a--