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

From: Mohit Sethi M <[email-masked]>
Date: Fri, 23 Aug 2019 15:32:06 +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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip

---

From: Markku Kojo <[email-masked]>
Date: Wed, 28 Aug 2019 12:55:16 +0300 (EEST)

Hi Mohit, all,

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

Thanks,

/Markku

---

From: Ilpo Järvinen <[email-masked]>
Date: Wed, 28 Aug 2019 14:53:37 +0300 (EEST)

> concerns. We will then send it to the IESG for review.

For me, no major concerns remaining. A few minor points from the text 
edited in -08.

The "pure ACK" might be better to write open, e.g., "ACK without
payload".

The current text in FR/FR scenario with 1-6 segment might confuse as
the sixth segment is only sent out on the first (duplicate) ACK. The 
current wording makes it to sound as if 1-6 would be outstanding right
at the beginning (instead of first 1-5 and then 2-6 after the ACK).

"plus two additional segments for each one of the first two duplicate 
ACKs."
I think this might be misinterpreted to mean 2*2 segments.

-- 
 i.