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

[Markku Kojo <[e-mail]>]

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lwip
>
>