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 20, 2020, at 2:28 AM, Carles Gomez Montenegro <[e-mail]> 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!