On 2019-02-10 13:33, Christian Huitema wrote: > > 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. Well, that's not a true scavenger application. Restarting the transport connection might be a reasonable option, but giving up on LE is effectively saying "lower effort is not really what I wanted." Anyway, I think that reinforces my point: it's an interesting discussion, but out of scope for this draft. Brian