Re: [Ecn-sane] robustness against attack?

["David P. Reed" <dpreed@deepplum.com>]

[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]


The only latency-under-load mechanism other than FQ that can work is "no (absolute minimal) queueing". That's fine as a goal.
 
Unfortunately, I would suggest that the whole concept of ECN/SCE has to be rethought from the ground up if the goal is "no queueing", because ECN and SCE are currently defined only when a queue has built up, which of course means that latency has built up.
 
Now, of course, throughput is completely independent of queueing delay (except when there are a lot of erasure errors on the links, in which case modest queueing can perhaps enhance aggregate throughput).
 
When the whole point of things is to minimize queueing delay through whatever links turn out to be bottlenecks, by getting flows to be throttled by lowering cwnd or source rate or whatever, the ONLY way to do this is to get early feedback as queueing just begins to build.
 
(Of course, I am one of those people who constantly point out that classes of service have no meaning, really, unless one precisely defines the queue management in terms of flows, not individual packets).
 
I really worry that this discussion is going off the rails due to a lack of understanding of queueing theory and control theory.
 

[-- Attachment #2: Type: text/html, Size: 2458 bytes --]