Re: [Lwip] Last Call: <draft-ietf-lwig-tcp-constrained-node-networks-10.txt> (TCP Usage Guidance in the Internet of Things (IoT)) to Informational RFC

[Carles Gomez Montenegro <[e-mail]>]

Hi Ted,

Thanks for your response. Please find below my inline responses:

> On Sep 18, 2020, at 8:14 AM, Carles Gomez Montenegro
> <[e-mail]> wrote:
>> Could you please provide any pointers to "existing research that
>> shows that MSS of greater than perhaps five lowpan frames is quite
>> harmful.”
>> ?
>
> So, first of all, I really owe you an apology for both comments—this is
> just great evidence for why we should never say something about someone
> else’s work that we are not prepared for them to read. My reaction was
> the result of going to the thing I cared most about in the document,
> finding what it said to be incorrect based on what I think is true, and
> assuming that this would be representative of the rest of the document.
> There was actually no reason for me to make this assumption; what I was
> actually looking for from the person to whom I intended to send the
> message was reassurance that this wasn’t as bad as it seemed. My
> subsequent comment on the list acknowledging this faux pas actually made
> it worse because I was embarrassed and hadn’t gotten past the
> self-justification stage to the simple retraction stage. Sigh.

No worries, and thanks for your detailed response.

> The specific paper I am thinking of is one titled Performant TCP for
> Low-Power Wireless Networks, by Sam Kumar, Michael P Andersen, Hyung-Sin
> Kim, and David E. Culler at UC Berkeley
> (https://www.usenix.org/conference/nsdi20/presentation/kumar
> <https://www.usenix.org/conference/nsdi20/presentation/kumar>). Reviewing
> the paper, what it says is not inconsistent with what you’ve said. It
> appears to be the case that an mss of five frames tends to perform better
> than an mss of fewer frames, and that for example an mss of one frame
> performs poorly. Performance appears to increase up to five frames. So in
> a sense this is supporting the notion that even more frames would be
> better, but this was not studied.

Thanks for the insight on the paper you mention. It offers interesting
details, and also experimental results consistent with our text, at least
for some MSS range. It would have been great to see results for even
greater MSS than the ones considered in the paper.

> The reason I’m concerned about this is that it’s my understanding that
> generally on LLNs fragments are acknowledged at the packet level, not at
> the fragment level. This means that if five fragments are transmitted and
> one dropped, all five have to be retransmitted. This assumption may
> actually not be true—I haven’t tested it. It’s based on what others
> have told me about how this works. If this assumption isn’t true, then
> my primary concern goes away. The concern I have is that as packet loss
> rates rise, the likelihood of any given IP packet making it across an
> 802.15.4 mesh intact (with no fragments lost) drops. Because every
> fragment has to be retransmitted, this can result in a lot of extra
> traffic being sent, which can further increase packet loss.
>
>
> So if that’s true, it makes sense to keep the mss short, preferably
> shorter than 1280. 1280 would be thirteen fragments on 802.15.4, if my
> math is right. I think ideally we’d want to keep the MSS down nearer to
> 500 bytes.

In the document, our aim is to be comprehensive regarding underlying IoT
technologies. Some of these support a sufficiently large L2 MTU, and
therefore fragmentation is not needed. Many other IoT technologies support
their own (ARQ-enhanced) fragmentation mechanism at the link layer.
However, there are indeed examples where fragmentation does not support
additional functionality for reliable fragment delivery, such as the
original 6LoWPAN fragmentation defined in RFC 4944 over IEEE 802.15.4. In
such cases, a relatively large MSS may certainly create the issue that you
mentioned.

Would the following proposed new text (that would replace the last
paragraph of 4.1.1) address your concern?

PROPOSED:

   Using larger MSS (to a suitable extent) may be beneficial in some
   scenarios, especially when transferring large payloads, as it reduces the
   number of packets (and packet headers) required for a given payload.
   However, the characteristics of the constrained network need to be
   considered. In particular, in a network where unreliable fragment
   delivery is used, the amount of data that TCP unnecessarily
   retransmits due to fragment loss increases with the MSS. This happens
   because the loss of a fragment leads to the loss of the whole fragmented
   packet being transmitted. Unnecessary data retransmission is particularly
   harmful in CNNs due to the resource constraints of such environments.
   Note that, while the original 6LoWPAN fragmentation mechanism [RFC 4944]
   does not offer reliable fragment delivery, fragment recovery
   functionality for 6LoWPAN or 6Lo environments is being standardized as of
   the writing [draft-ietf-6lo-fragment-recovery].

> It may be that my reasoning is completely wrong here, but the reason for
> my reaction to this document is that this is my present understanding of
> the problem, and hence the recommendation of a 1280 byte mss seems wrong.
> If I misread that, I apologize. As I said, I need to give the document a
> closer read.  Generally speaking I would really like to see the old canard
> that TCP can’t work on LLNs put to pasture, so I want this work to
> succeed. Again, I’m sorry for the unkind comment.

Thanks for your words. Yes, breaking the myth that 'TCP is not suitable
for IoT' is one of the main objectives of this document. Let's hope we can
contribute to that!

Cheers,

Carles