On Sep 20, 2020, at 2:28 AM, Carles Gomez Montenegro <[email protected]> 
wrote:
> 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.

I agree. My intuition is that there is likely a peak number of segments past 
which adding more segments reduces performance; I suspect that this is probably 
close to the numbers the Berkeley paper arrived at, but we have no data. It 
would be good to have more data before making general assertions about what mss 
IoT devices should use, particularly given that some IoT transports may do 
per-fragment retransmission, while others won’t, and as you say, some IoT 
transports have reasonably large MTUs, while others don’t.
> 
> 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].

I think this is okay, although you don’t mention that given a constant 
per-frame error rate, the more frames you send, the higher the actual error 
rate will be, that this increases exponentially as the number of fragments 
increases, and further that, as you mention, in CNNs, retransmission traffic 
can swamp successful transmissions leading to worse and worse throughput as MSS 
increases.

I don’t think it’s sufficient to mention this in a few sentences in a single 
paragraph. This needs to be part of a more detailed analysis.

> 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!

100% agree. Thanks!

_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip

Reply via email to