[Ecn-sane] https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-03#page-21

[Sebastian Moeller <moeller0@gmx.de>]

How is the following going to work in the light of the light of LLLLS being advertised as requiring only a single "bit" identifier and no further classification:

"8.2. 'Latency Friendliness' The L4S service does rely on self-constraint - not in terms of limiting rate, but in terms of limiting latency (burstiness). It is hoped that standardisation of dynamic behaviour (cf. TCP slow-start) and self-interest 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."

I fail to see how punitive action can be targeted to offending flows without using more that ECT(1), unless those are clearly identified (maybe https://www.ietf.org/rfc/rfc3514.txt can be leveraged here ;) ). If low latency low loss is to be the future of the internet, I feel, the L4S architecture should start taking the often hostile environment the internet provides into account, unless the whole idea is to build a LLLLS conduit from the nearest DC into all homes only, which if all operated by the same ISP might actually be sufficiently robust against attacks, but also will fall short of replacing the current internet with L4S in the future....

Best Regards
	Sebastian