Re: [tsvwg] Tsvart last call review of draft-ietf-tsvwg-le-phb-08

[Christian Huitema <[e-mail]>]

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