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

Markku Kojo <> Wed, 28 August 2019 09:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 821E51200B4; Wed, 28 Aug 2019 02:55:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 QTPdqpzyMpJL; Wed, 28 Aug 2019 02:55:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E4CC2120096; Wed, 28 Aug 2019 02:55:25 -0700 (PDT)
X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 Wed, 28 Aug 2019 12:55:16 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=5gwaDTTYrx1qgHnZf 6DH4HY93jUOHbWeMwf0BmpKEtY=; b=ATdBwHgiPoZhBtz8nFDx2L0VBKL33VWv1 N1/7Y0b3+8rqNfDQJTAR7hk04u3n73NjIRrdMl6lqCR3xB4nFARA9A5UAZyNZvmt gnvuzU9lAVPqim/lGbSKyP2zXlEn9F1LlGm+grnE9t6rFxYGOxjbXTuSdDi+nh/h l5uWMKcZJc=
Received: from ( []) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by with ESMTPSA; Wed, 28 Aug 2019 12:55:16 +0300 id 00000000005A0146.000000005D664F84.000047AC
Date: Wed, 28 Aug 2019 12:55:16 +0300
From: Markku Kojo <>
To: Mohit Sethi M <>
cc: Carles Gomez Montenegro <>, Ilpo Järvinen <>, "" <>, "" <>, "" <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_script-18416-1566986116-0001-2"
Archived-At: <>
Subject: Re: [tcpm] [Lwip] Review ofdraft-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: Wed, 28 Aug 2019 09:55:30 -0000

Hi Mohit, all,

I've missed this reply, sorry. I'll have a look at it this week.



On Fri, 23 Aug 2019, Mohit Sethi M wrote:

> 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