Re: [tsvwg] Consensus call on ECT(1)

[Sebastian Moeller <[e-mail]>]

Hi Stuart,

I have a question about your rationale below.


> On May 14, 2020, at 05:44, Stuart Cheshire <cheshire=[e-mail]> wrote:
> 
> On 4 May 2020, at 11:15, Wesley Eddy <[e-mail]> wrote:
> 
>> In this email thread, please state, concisely, which of the following viewpoints on ECT(1) you prefer.
> 
> I support option 1, using ECT(1) as an *input* signal to the network.
> 
> We need an input signal to the network because it allows the sender to signal to the network that it it is able to gracefully handle (and indeed, benefit from) ultra-shallow network queues. It also serves as a commitment by the sender not to abuse that shallow queue by bloating it (under pain of severe penalty if caught doing that by a stochastic traffic policer). Without an input signal to communicate the source’s request for the shallower queue (and acceptance of the corresponding consequences if caught cheating) the network can’t know to which traffic it can safely apply the stricter policy.

	[SM] The L4S RFCs make it explicitly clear, that no such "stochastic traffic policer" will be mandated (or maybe not even needed). In an earlier discussions here on the mailing list I got the impression that even the idea of mandating even just the implementation (let alone default activation) of such a monitoring and enforcement was rejected. The official L4S position seems to be that the shallowness of the LL-queue alone would be sufficient to act as disincentive against abuse.

From https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4s-arch-06:

"8.1.  Traffic (Non-)Policing


   Because the L4S service can serve all traffic that is using the
   capacity of a link, it should not be necessary to police access to
   the L4S service.  In contrast, Diffserv only works if some packets
   get less favourable treatment than others.  So Diffserv has to use
   traffic rate policers to limit how much traffic can be favoured.  In
   turn, traffic policers require traffic contracts between users and
   networks as well as pairwise between networks.  Because L4S will lack
   all this management complexity, it is more likely to work end-to-end.

[...]
8.2.  'Latency Friendliness'


   Like the Classic service, the L4S service relies on self-constraint -
   limiting rate in response to congestion.  In addition, the L4S
   service requires self-constraint in terms of limiting latency
   (burstiness).  It is hoped that self-interest and standardization of
   dynamic behaviour (especially flow start-up) will be sufficient to
   prevent transports from sending excessive bursts of L4S traffic,
   given the application's own latency will suffer most from such
   behaviour.

   Whether burst policing becomes necessary remains to be seen.  Without
   it, there will be potential for attacks on the low latency of the L4S
   service.  However it may only be necessary to apply such policing
   reactively, e.g. punitively targeted at any deployments of new bursty
   malware.

   A per-flow (5-tuple) queue protection function [I-D.briscoe-docsis-q-protection] 
   has been developed for the low
   latency queue in DOCSIS, which has adopted the DualQ L4S
   architecture.  It protects the low latency service from any queue-
   building flows that accidentally or maliciously classify themselves
   into the low latency queue.  It is designed to score flows based
   solely on their contribution to queuing (not flow rate in itself).
   Then, if the shared low latency queue is at risk of exceeding a
   threshold, the function redirects enough packets of the highest
   scoring flow(s) into the Classic queue to preserve low latency.

   Such a queue protection function is not considered a necessary part
   of the L4S architecture, which works without it (in a similar way to
   how the Internet works without per-flow rate policing).  Indeed,
   under normal circumstances, DOCSIS queue protection does not
   intervene, and if operators find it is not necessary they can disable
   it.  Part of the L4S experiment will be to see whether such a
   function is necessary.
"


and https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-11"

"4.1.  Overload Handling


   Where the interests of users or flows might conflict, it could be
   necessary to police traffic to isolate any harm to the performance of
   individual flows.  However it is hard to avoid unintended side-
   effects with policing, and in a trusted environment policing is not
   necessary.  Therefore per-flow policing (e.g.
   [I-D.briscoe-docsis-q-protection]) needs to be separable from a basic
   AQM, as an option under policy control."


It seems clear that this position of not requiring a policer is not based on actual data, as otherwise there would be references demonstrating that. IMHO this is based on hope/wishful thinking.


QUESTIONS:

1) Are you agreeing that these definitions are not fully aligned with your idea that misusing the input signal will have negative consequences for the abuser?

2) Are you proposing to make such policing mandatory (which would require at least changes to the cited section of RFC drafts) or are you fine with leaving this aspect purely for implementers? At that point L4S proponents will argue that this will drag in reading L4 headers something they want to avoid at all costs* 


Best Regards
	Sebastian



*) IMHO this is misguided, a node not having access to L4 headers simply can use a 3-tupel (just from the IP header) for "flow-group" identification, or on IPv6 ualso se the flow label as part of the flow identification or not use ECN in its AQM at all. Or put differently, I do not assume meaningful roll-out of AQMs to this nodes, as the value equation that has made operators not deploy single queue PIE or Codel to those nodes still apply. And those single queue AQMs would already deliver the bulk of the latency improvement expected with L4S, from multiple 100s to 1000s of milliseconds down to the high single to low double digit millisecond range. But I digress.





> 
> Stuart Cheshire
>