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,

We just submitted a new version of the draft (-11), which includes the
modified paragraph that we were talking about, slightly further modified
in the lines of your comments below:
https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/

Please find below an inline response to your last message:

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

Agreed. However, that analysis would probably be more suitable as a topic
for research work, and we understand that that kind of work would go
beyond the scope of this draft.

As a research topic, it would indeed be great to perform a deep analysis.
However, even then, it may be difficult to extract general conclusions,
since performance in a real-world scenario will depend on many factors
including network size, network density, network diameter, error
distribution, IoT technology used, layer 1 / layer 2 settings...

In this document, we try to provide the reader with the main advice of not
exceeding an MTU of 1280 bytes, and some guidance to help in this area
from the TCP point of view. We additionaly provide (non-quantified)
trade-offs regarding the MSS setting, so that the reader can be aware of
potential problems in some types of networks.

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

Thanks!

Carles