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

[Ted Lemon <[e-mail]>]

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.

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.

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.

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.