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

Markku Kojo <kojo@cs.helsinki.fi> Wed, 28 August 2019 09:55 UTC

Return-Path: <kojo@cs.helsinki.fi>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821E51200B4; Wed, 28 Aug 2019 02:55:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi
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 QTPdqpzyMpJL; Wed, 28 Aug 2019 02:55:26 -0700 (PDT)
Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (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 mail.cs.helsinki.fi Wed, 28 Aug 2019 12:55:16 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; 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 dx6-cs-02.pc.helsinki.fi (dx6-cs-02.pc.helsinki.fi [193.167.160.58]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Wed, 28 Aug 2019 12:55:16 +0300 id 00000000005A0146.000000005D664F84.000047AC
Date: Wed, 28 Aug 2019 12:55:16 +0300 (EEST)
From: Markku Kojo <kojo@cs.helsinki.fi>
X-X-Sender: kojo@dx6-cs-02.pc.helsinki.fi
To: Mohit Sethi M <mohit.m.sethi@ericsson.com>
cc: Carles Gomez Montenegro <carlesgo@entel.upc.edu>, "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" <ilpo.jarvinen@cs.helsinki.fi>, "lwip@ietf.org" <lwip@ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>, "jon.crowcroft@cl.cam.ac.uk" <jon.crowcroft@cl.cam.ac.uk>
In-Reply-To: <bdb83140-4bc1-dd45-1a5e-e5f4e23c638f@ericsson.com>
Message-ID: <alpine.DEB.2.20.1908281253120.5906@dx6-cs-02.pc.helsinki.fi>
References: <alpine.DEB.2.20.1811071352180.14868@whs-18.cs.helsinki.fi> <c9a84f24e05fd1b433cf22fe742857c5.squirrel@webmail.entel.upc.edu> <alpine.DEB.2.20.1904261602000.23031@whs-18.cs.helsinki.fi> <184404a792aadb06ac772ffe05bc3233.squirrel@webmail.entel.upc.edu> <bdb83140-4bc1-dd45-1a5e-e5f4e23c638f@ericsson.com>
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: <https://mailarchive.ietf.org/arch/msg/tcpm/_PB9HMvWZgKmdRgFdFI4DJ8EtQ4>
Subject: Re: [tcpm] [Lwip] Review ofdraft-ietf-lwig-tcp-constrained-node-networks-04
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=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.

Thanks,

/Markku

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
>> Lwip@ietf.org
>> https://www.ietf.org/mailman/listinfo/lwip
>
>