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

"Carles Gomez Montenegro" <carlesgo@entel.upc.edu> Wed, 05 June 2019 08:58 UTC

Return-Path: <carlesgo@entel.upc.edu>
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 6896A12061E; Wed, 5 Jun 2019 01:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 AKdG1bGN81CB; Wed, 5 Jun 2019 01:58:56 -0700 (PDT)
Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 8494D1200B6; Wed, 5 Jun 2019 01:58:55 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x558wkYM025874; Wed, 5 Jun 2019 10:58:46 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 012581D53C1; Wed, 5 Jun 2019 10:58:45 +0200 (CEST)
Received: from 131.111.5.141 by webmail.entel.upc.edu with HTTP; Wed, 5 Jun 2019 10:58:45 +0200
Message-ID: <184404a792aadb06ac772ffe05bc3233.squirrel@webmail.entel.upc.edu>
In-Reply-To: <alpine.DEB.2.20.1904261602000.23031@whs-18.cs.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>
Date: Wed, 5 Jun 2019 10:58:45 +0200
From: "Carles Gomez Montenegro" <carlesgo@entel.upc.edu>
To: =?iso-8859-1?Q?=22Ilpo_J=E4rvinen=22?= <ilpo.jarvinen@cs.helsinki.fi>
Cc: lwip@ietf.org, michael.scharf@hs-esslingen.de, jon.crowcroft@cl.cam.ac.uk, tcpm@ietf.org
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.2 at violet
X-Virus-Status: Clean
X-Greylist: Delayed for 00:39:06 by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Wed, 05 Jun 2019 10:58:46 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/kUO0JupZtwhAya8M1c8v3x5W-2M>
Subject: Re: [tcpm] Review of draft-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, 05 Jun 2019 08:58:59 -0000

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)