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

Ilpo Järvinen <ilpo.jarvinen@cs.helsinki.fi> Fri, 26 April 2019 14:11 UTC

Return-Path: <ilpo.jarvinen@cs.helsinki.fi>
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 6174B120145 for <lwip@ietfa.amsl.com>; Fri, 26 Apr 2019 07:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.735
X-Spam-Level:
X-Spam-Status: No, score=-2.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 lY0WQLlHc2wY for <lwip@ietfa.amsl.com>; Fri, 26 Apr 2019 07:11:50 -0700 (PDT)
Received: from smtp-rs2-vallila1.fe.helsinki.fi (smtp-rs2-vallila1.fe.helsinki.fi [128.214.173.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC98B12004B for <lwip@ietf.org>; Fri, 26 Apr 2019 07:11:49 -0700 (PDT)
Received: from whs-18.cs.helsinki.fi (whs-18.cs.helsinki.fi [128.214.166.46]) by smtp-rs2.it.helsinki.fi (8.14.7/8.14.7) with ESMTP id x3QE4Twq023533; Fri, 26 Apr 2019 17:04:29 +0300
Received: by whs-18.cs.helsinki.fi (Postfix, from userid 1070048) id 0EF59361322; Fri, 26 Apr 2019 17:04:29 +0300 (EEST)
Received: from localhost (localhost [127.0.0.1]) by whs-18.cs.helsinki.fi (Postfix) with ESMTP id 0D6C43600C1; Fri, 26 Apr 2019 17:04:29 +0300 (EEST)
Date: Fri, 26 Apr 2019 17:04:29 +0300
From: Ilpo Järvinen <ilpo.jarvinen@cs.helsinki.fi>
X-X-Sender: ijjarvin@whs-18.cs.helsinki.fi
To: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
cc: lwip@ietf.org, michael.scharf@hs-esslingen.de, jon.crowcroft@cl.cam.ac.uk
In-Reply-To: <c9a84f24e05fd1b433cf22fe742857c5.squirrel@webmail.entel.upc.edu>
Message-ID: <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>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/MegjwIdo3vUP6qioWRtu4cptTk4>
X-Mailman-Approved-At: Fri, 26 Apr 2019 07:32:05 -0700
Subject: Re: [Lwip] Review of draft-ietf-lwig-tcp-constrained-node-networks-04
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Apr 2019 14:11:53 -0000

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!

> 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).

> > 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).

> > 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.

> > 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?

> > 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!



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.

Section 4.2

"single-MSS", I'd use "single segment" (like the change you made into
the annex table) throughout the document.

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.

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.

Nits:

In the pdf version, the "Subsection x.x.x" meta linkage does begin
only from "section".

Section 5.2 2nd para: comsuming -> consuming



-- 
 i.