Introduce coupling between loss recovery strategies and CC

[mattmathis]

Although loss recovery is out of scope, some loss recovery design choices affect the suitability of some CCAs. If we don't take this into account, we doom our relevance in constrained environments. A partial list:

• simple RTO only
• simple fast retransmit (TCP Tahoe)
• fast retransmit with Fast recovery (New Reno)
• Go-bank-N
• Modern SACK based In addition the presence of some tcp features has a profound impact on appropriate CCA behavior, For example TCP without WSCALE is sufficiently constrained to avoid many of the hazards of concern here. It might be appropriate to greatly relax the guidelines for transports with 64kB maximum window sizes.

[huitema]

Yes. This is another way to tackle the overhead issue.

[huitema]

"The onset of congestion is very likely to cause packet losses and increase delays. Some loss recovery algorithms detect packet losses too soon and try to repeat packets that were not actually lost -- an example wold be algorithms relying on fixed timers. Other algorithms respond to the loss of one packet by sending many packets -- an example would be algorithms repeating whole messages if one of the packets carrying the message is lost. Such algorithms create additional traffic overhead during congestion periods, and thus increase the risk of congestion collapse. The Internet congestion events of the late 1980's were likely amplified by those two factors: TCP then did not properly compute retransmission timers [cite Lixia's paper] and reacted to packet losses by repeating all packets in flight, using a "Go Back N" strategy. Modern packet loss recover methods avoid these pitfalls, see [cite the RACK RFC]."

[nealcardwell]

It might be appropriate to greatly relax the guidelines for transports with 64kB maximum window sizes.

I would argue against that. Even a 64KByte maximum window size can cause massive buffer bloat at the data rates of dial-up modems or LPWAN networks, which constrained/IoT devices might be using:

64*1024*8bits / 56kbps > 9.3 secs

https://en.wikipedia.org/wiki/Low-power_wide-area_network "The LPWAN data rate ranges from 0.3 kbit/s to 50 kbit/s per channel."

[mattmathis]

Yes, even with a constrained window, a RTT clamp should be required.

[martinduke]

Editors: @gorryfair is going to paste this text into his advice document, but this seems tangential to the purpose of 5033bis