Re: [tcpm] [Lwip] Review of draft-ietf-lwig-tcp-constrained-node-networks-04

Mohit Sethi M <> Fri, 23 August 2019 15:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 082F3120105; Fri, 23 Aug 2019 08:32:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cqyV7C_2x_HR; Fri, 23 Aug 2019 08:32:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 232D212004D; Fri, 23 Aug 2019 08:32:09 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=Mfd3L66dmH+9OyQe3Uoe9LsswYZofTNyFvq09/t1hzfi/8dQH8/rtkx/kqDaP0RjdtG+f7eqAtSOHgWn6aplTrbLOY/ReMi3686F/Ekk/QojCx+MtYdbDlIz1wF0Y9uPR+RVs6CJKqbweUL3AthjZFE4+CqrxDzKb/yTD+Pz3qQFLvPwC/5gFpYCTN5MtuYyJGC7IqRggLXRUPE6jeAnPsYLkxtLu5LuyGlMhDc1XVoAINcxoFxcKFAmnmxs0LyPVdaGsoimgufEzeYk12dhVsm8Lxkf2icc3J8TY+tUszvkMP3miQJb6HXdI8xaDU8LV8lipQIl1qQjGuqyPN3Gqw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GmRDvM7jPkwc/vI+nkBhlpMp3vH9MieKEMA7NZdmduc=; b=WTIi+hPEzlUdB7SjOCq0pMW8XUO9EsC4EtYkQ0GqgigZxJQP/cNfh+bC8l1A3d6pvx0+l9qpkmRfqSA8KOWds9XKy+hv+2jYCy8Y2XPoKxm40w4L8iNIfvGDXHUEEQ/vruXcfq8A7lyJSxV97F/DO3/jRrfgQ1SEhfjlOyEp1pmGVnAGHTjYaA2e2GUqDSsoUy8ainhpf8uLs9Pwa8ZhRWCzJ7k/iv7YsAWA6g2OlO76g4jsOFUMjpYYIXJ4TqIb5V+XPcJKbOb6vwaCI/6UuKqU3++STn8Df3ZddkWsP7TWdgyvDaz7cbqSk7GOeClJT1KsZLVP5IOTZPvC/cswuA==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GmRDvM7jPkwc/vI+nkBhlpMp3vH9MieKEMA7NZdmduc=; b=oMO3fTfHXXCVfisheYlhgrFQUEvFJ5n3pfUrlTyQIylNdsgrMgncz6IpBT9Ux+HB8J6CwcTaV5m+9IAYYIuU0OWWa4+LAlOAq4/zfY7RKhnXEzjjBWvOrp4Pr9qdlUGzMWEXnR3q9Bh1S4hMM45rRTQK4gLt4yDnI6lfFoN/PmY=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.10; Fri, 23 Aug 2019 15:32:06 +0000
Received: from ([fe80::e4a6:7d44:ffe2:7e60]) by ([fe80::e4a6:7d44:ffe2:7e60%12]) with mapi id 15.20.2199.015; Fri, 23 Aug 2019 15:32:06 +0000
From: Mohit Sethi M <>
To: Carles Gomez Montenegro <>, =?utf-8?B?SWxwbyBKw6RydmluZW4=?= <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: [Lwip] Review of draft-ietf-lwig-tcp-constrained-node-networks-04
Thread-Index: AQHVWcfriFFnLvgljku5nKaIaXNJdA==
Date: Fri, 23 Aug 2019 15:32:06 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3d36715d-c945-4078-6e11-08d727df0e16
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0701MB2347;
x-ms-traffictypediagnostic: HE1PR0701MB2347:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0138CD935C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(376002)(346002)(136003)(39860400002)(199004)(189003)(14454004)(478600001)(5660300002)(966005)(4326008)(76176011)(476003)(446003)(11346002)(6246003)(2171002)(6116002)(53936002)(31686004)(3846002)(71200400001)(71190400001)(6306002)(2906002)(2616005)(486006)(6512007)(25786009)(36756003)(26005)(53546011)(102836004)(305945005)(6506007)(7736002)(99286004)(186003)(66446008)(86362001)(31696002)(76116006)(66556008)(66946007)(66476007)(64756008)(316002)(110136005)(229853002)(54906003)(65806001)(65956001)(66066001)(6436002)(8676002)(81156014)(6486002)(81166006)(8936002)(14444005)(256004)(58126008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2347;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: wr9/V/c6qdUgI04f6WxWn6qjLPX9LkaB4a7W7T3bVFW+yRZeKOivm7lfkRVinNK2/TXm3SkNsL56xIMKxkqPZWobXYHjZG55ecuZUAbCU4yIc0eBgJ2IXASSyQgEcTu8Y5KWDN7229b4Yczj2rhi8I2vVAiLVwyQfqLU9A5srlhZA5hWQADex/ytDnCdtjTo3K+XOAvODZX7KW8Uz3rdPp5Yaw49Ap0YCor4c+DY3zJnL5xqW/oNAY/VjgRo1P6YRp1VbjPvjshGI9KUqyHeKBu6FlgDaUUBTuPoM0wRZ/KIXJCTEmUSCgAx+3Hg/Zqm8X7LR8QkEGl8bKZ/Dhwjx8plzyl/rdu7WpJBK5DbzMu59juhobeurjACGhzlpDuamOu7iiN4hZfv7oX6G6wxBeAylJzNxz2LAzP40T9cVX4=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3d36715d-c945-4078-6e11-08d727df0e16
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2019 15:32:06.2936 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: RHVBkiZsRyWVwfcZq9aMgILc5tyDQFrok+sTL+nyb/873mOy4SgH7zSz94L09PrjiJV/CT9feC4BTis5db80dcWnsMqm66NUUffA6sWge34=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2347
Archived-At: <>
Subject: Re: [tcpm] [Lwip] Review of draft-ietf-lwig-tcp-constrained-node-networks-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Aug 2019 15:32:13 -0000

Hi Ilpo and Markku,

Could you confirm that -08 version of the draft addresses all your 
concerns. We will then send it to the IESG for review.

Zhen and Mohit

On 6/5/19 11:58 AM, Carles Gomez Montenegro wrote:
> Hi Ilpo,
> (CC'ing also TCPM.)
> First of all, sorry for the delay in our response.
> Thank you very much for reviewing the draft again, and for answering our
> questions. Your comments have been very useful to improve the quality of
> the document. Our updates can be found in revision -08.
> Please find below our inline responses to your comments.
>> On Sun, 10 Mar 2019, Carles Gomez Montenegro wrote:
>>>> General Comments / Structure
>>>> ----------------------------
>> I've read the document (-07) through once again, and in general I got
>> a feeling that it has improved substancially!
> Thank you!
>>> In the new draft version, in some cases, we have tried to be more
>>> specific
>>> (e.g. ?message overhead?, ?memory overhead?, etc.). However, in some
>>> other
>>> cases the context may help to better determine the scope of ?overhead?,
>>> or
>>> ?overhead? relates with all the dimensions you listed (and for
>>> simplicity,
>>> we prefer to keep just ?overhead?).
>> I didn't find unqualified "overheads" a problem anymore either (that is,
>> in case there were some as I didn't even notice them anymore).
> Thanks for your confirmation.
>>>> Small Points
>>>> ------------
>>>> Sec 3.2 Usage Scenarios, 3rd para: I fail to get the point of this
>>>> paragraph. There are two distinct points about the environment:
>>>> middleboxes on path and asymmetry in end point capabilities. No
>>>> implications about bringing these two in particular up in the same
>>>> paragraph are mentioned. That is, why I must note the asymmetry when
>>>> there's a middlebox?
>>> Because the middlebox will often be transparent to TCP (but not to other
>>> protocols). Basically, the presence of such middleboxes is a major
>>> motivation for use of TCP in IoT environments (e.g. RFC 8323).
>> I still don't see the connection between a middlebox requiring use of
>> TCP and that I must note asymmetry in the scenario. But this not all that
>> important part of the text anyway so I guess it could be left like that.
>> There's, however, duplication between the 1st and the last paragraphs
>> (and also somewhat with this 3rd paragraph text now that I look).
> In -08, we have merged part of the first and the third paragraph, which
> helped reduce redundancy. After this change, we believe that the first and
> the last paragraphs (of section 3.2) do not contain duplicated content.
>>>> 4.3.2 SACK
>>>> IMHO, SACK should be subsection of loss recovery or 4.3.1
>>>> should be retitled to only FR/FR.
>>> Yes, we agree with the suggestion, and prefer to make SACK a subsection
>>> of
>>> 4.3.1.
>>>> Out-of-order queue handling is unrelated to SACK, should be
>>>> covered somewhere else? There is implicit complexity & TCB
>>>> impact when the flow may have >1 MSS wnd, maybe group all these
>>>> (when not related to a particular mechanism that has its own
>>>> discussion somewhere) under a single section).
>>> Not sure if the current wording may lead to different understandings,
>>> but
>>> out-of-order is mentioned here to denote the fact that a few segments
>>> may
>>> be lost and the receiver will need to inform about the data blocks
>>> actually received.
>> "The receiver supporting SACK will need to managed the reception of
>> possible out-of-order received segments, requiring sufficient buffer
>> space."
>> This text seems to imply that because of SACK, managing ofo segments is
>> necessary but it is a feature that is needed also w/o SACK when TCP
>> supports multi-segment window. So any loss recovery regardless of SACK
>> will need to deal with that. What SACK adds to that on the receiver
>> side, is keeping track of the SACK blocks to send back.
> The text (after removing the SACK mention) is now before the SACK
> subsection. We have also added your point on the SACK-specific tasks to be
> done by a receiver supporting SACK.
>>>> No sender-side SACK aspect covered?
>>> We currently have:
>>> ?a sender (having previously sent the SACK-Permitted
>>>     option) can avoid performing unnecessary retransmissions, saving
>>>     energy and bandwidth, as well as reducing latency.?
>>> Is there any particular aspect you think should be added ?
>> When the sender get SACK blocks from the receiver in ACKs, it need to
>> bookkeep the per seq/segment state to avoid sending the particular
>> data/segments again during the recovery.
>> But perhaps there just isn't a convincing IoT scenario for the device to
>> be sending enough data to benefit from the sending side SACK in the first
>> place?
> Well, perhaps in some cases a device might keep a relatively large file
> (e.g. containing sensor readings taken over a relatively long time
> interval). For the sake of completeness, we have added your point on the
> sender needing to bookkeep the necessary state for resending only the
> needed data.
>>>> In general, there's occassionally confusion within the document
>>>> whether some advice/description is for the receiving or sending
>>>> side (this is of course scenario dependant which the implementer
>>>> should consider in his/her own case but the document should cover
>>>> both cases where applicable).
>>> We?d welcome specific suggestions of document sections where your
>>> comment
>>> applies.
>> Somehow, I didn't get a similar feeling anymore so I guess some of
>> edits have done enough to resolve sender/receiver ambiguity below
>> noticable level!
> Thanks for your confirmation.
>> Here are some additional comments that I noted while reading it through
>> for the second time:
>> 4.1.2 ECN
>> 3rd para. There is an unresolved contradition related to "throughput"
>> in the paragraph (none of the text is "wrong" per se but the dots just
>> don't seem to connect well enough to make sense). ECN with 1 segment is
>> said to "result in very low throughput" and in the very next sentence it
>> is said "In addition to better throughtput...". Neither is incorrect but
>> I wouldn't put those statements next to each other to avoid confusion
>> it easily causes.
> Thanks for pointing this out. Markku proposed new text that solves the
> problem. That text is now included in -08.
>> Section 4.2
>> "single-MSS", I'd use "single segment" (like the change you made into
>> the annex table) throughout the document.
> Done.
>> The use of "stack" in the 4.2 and its subsections would be better as
>> "window" because some of the text applies also to the unconstrained
>> end of the connection that is not a single mss/segment stack
>> but is only communicating with such a stack.
> We see your point and we have replaced “stack” with “window” in some
> instances. However, in some cases “stack” was actually intended as
> “implementation”, therefore in those cases we have left “stack”
> unmodified.
>> Section 4.2.4
>> 2nd para. "cannot use" -> "cannot benefit from". It is possible
>> to "use" but no benefits can be gained. It's relevant in particular
>> when the connection is one segment but the sender is unconstrained,
>> the text now excludes this valid scenario by adding "than for a more
>> powerful TCP stack" but it shouldn't, IMHO.
> Agreed.
>> Nits:
>> In the pdf version, the "Subsection x.x.x" meta linkage does begin
>> only from "section".
> Perhaps this is something that might be solved at the RFC editor stage...
>> Section 5.2 2nd para: comsuming -> consuming
> Done.
> Once again, thank you very much for all your feedback!
> Cheers,
> Carles (on behalf of all coauthors)
> _______________________________________________
> Lwip mailing list