Disabling congestion control a SHOULD?
Closed this issue · 3 comments
Joe Touch had two comments on the disabling of congestion control
- That MAY should be a SHOULD
- Strengthen the language on the downside of running nested congestion control loops in that section.
I personally don't think a SHOULD is reasonable here. We don't have enough data to demonstrate that this advice is always sound. My personal experience is that nested congestion control loops work fine in practice. (Note that this is nested congestion control, not nested loss recovery.) Whether this should be done or not is very dependent on the deployment environment. Adding some text warning of the risks is always good, but a normative recommendation is a step too far.
So I think the current MAY is likely a reasonable middle ground. From my perspective not nesting congestion control loops will no doubt be better based on the research that exist. It just that it might work good enough with nested in some cases. But, we also have the challenges with this HTTP environment that it is not always possible to avoid.
Agreed. I think we had a nice productive discussion on the list (and on #170) where the outcome was
- TCP-in-TCP has bad performance, we all agree that the document saying SHOULD NOT do that is a good solution
- nested congestion control is not as bad, but there's no literature on how bad it is yet. We landed on MAY disable congestion control even though a few folks would have preferred that MAY to be a SHOULD
Based on this, I'm closing this issue with no action.