Hi Ted, Thanks for your response. Please find below my inline responses: > On Sep 18, 2020, at 8:14 AM, Carles Gomez Montenegro > <carlesgo@xxxxxxxxxxxxx> 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
