Re: [tsvwg] path forward on L4S issue #16

["Holland, Jake" <[e-mail]>]

Hi Wes,

Thanks for your comments, I mostly agree with your remarks.

However, there was one point I thought needed a response:

On 6/22/20, 8:39 AM, "Wesley Eddy" <[e-mail]> wrote:
>> 5. operational considerations to recommend policing strategies that can
>>     solve the general case of non-compliant traffic that does not respond
>>     with the expected backoff to AQM congestion signaling.
>> a. Arguably this should be done regardless of L4S, because it seems like
>>     an underdeveloped piece of the puzzle for the general problem of active
>>     queue management in network devices.  However, solving this well and
>>     getting solutions widely deployed or at least available (or somehow
>>     deployed in conjunction with L4S endpoint enablement) could also
>>     potentially address issue 16.
>
> I personally agree with this.  I think it's not specific to L4S at all 
> though.  How bad flows are dealt with in general will also be applicable 
> to a buggy or malicious L4S flow.  So I personally think the gate for 
> L4S work in this regard should simply be WG confidence that the 
> situation is not made substantially worse by L4S flows (whether they are 
> legitimate or not).

I don't think it's right to conflate legitimate and illegitimate flows
here.

There's a difference in kind (and in the reasonable set of responses)
between 1. a one-off buggy or cheating sender, vs. 2. a DDOS attack, vs.
3. a growing population of legitimate endpoints that are by design
incompatible with existing network devices.

There are a number of countermeasures[*] that are completely reasonable
for illegitimate traffic (#'s 1 and 2), but that are much less reasonable
if trouble is caused by a growing population of legitimate endpoints.

So while I agree that this issue is not specific to L4S at all, to me
the reasoning is the other way around:
    Although L4S now seems unsafe to roll out at scale because of its
incompatibility with classic queues, there could be a good set of
solutions to "overburdened AQM response" that could change matters
once deployed.  So digging in this direction might be able to unblock
L4S, in addition to improving AQM operations in general. (But on a
long timeline.)

Or to put my take on it another way:
    L4S flows *would* make the situation substantially worse if they
started rolling out now.  But it might be possible in the future to make
it so they *would not* make things worse, with good solutions to this
other problem.

Best regards,
Jake


[*] to be more specific:
For #1 (a one-off buggy or cheating sender), the easiest and most
common initial response for an operator is "ignore it, it'll go away".
I've certainly run my share of 1-off flow experiments on the internet,
and most of the time nobody notices or cares (and once in a while you
get spanked a bit).

But when you legitimize and start scaling those, it becomes hard or
impossible to distinguish #2 from #3, and it *would* be a problem to
apply some of the common #2 countermeasures to legitimate traffic
(like triggering routing black holes or suchlike).

If it comes up for the L4S case, absent a better solution, this is
exactly how the best response available to an operator ends up
landing on approach #4 (bleach ECT(1) to NECT).

But although I'm not a big fan of bleaching, I would much prefer a
consensus decision that it's the best answer to a consensus decision
that no answer is necessary (leaving bleaching as the undocumented,
yet only sane option available to operators when trouble happens,
and hoping it's the one they choose).