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
