|
On 2/9/2019 10:52 AM, Brian E Carpenter
wrote:
First, Section 3 mentions : "Since LE traffic could be starved completely for a longer period of time, transport protocols or applications (and their related congestion control mechanisms) SHOULD be able to detect and react to such a starvation situation. " This is an important point for such a service. Applications and/or transport protocols that are intended to be used with this service should be capable of supporting long losses of connectivity that may cause connections to fail. The document should strongly recommend to only use this service with applications/protocols that are capable of resuming an aborted data transfert.Isn't that what the SHOULD already says? There's no implication that one would use TCP. I would expect a pragmatic UDP-based mechanism. But I don't think this draft should cover that - its role is to define the code point and the per-hop behaviour, not the end to end protocol. There is some experience of that with other scavenger modes, e.g. using LEDBAT. Slowing down to a trickle is fine, but slowing down to zero is not. In practice, many applications that are willing to use a scavenger mode will trigger an error if they see no progress for a sustained amount of time, and then they will restart the connection and remove the LEDBAT or LE option -- which of course defeats the purpose. -- Christian Huitema
|
