<font face="arial" size="3"><p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">It's essential that the normal state of the Internet, everywhere, is that all queues, except at the ultimate source and destination, average to < 1 packet queued on the outgoing link.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">That's for many interlocking reasons.  Transient queue buildup MUST be drained back to less than 1 packet with alacrity. All queue buildups must sit either at the entry to the shared network or at the recipient node.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">Now it is straightforward algorithmically to prioritize competing flows, basically by changing the packet admission rates *at the entry* (through windowing or rate control). To do so requires that there be enough information reflected into each flow (by drops or ECN or whatever) to cause the rates/windowing controls to selectively prioritize the scheduling of admission at the entry endpoint.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">These are in the nature of desirable invariants achieved by the interaction of the distributed system of flows.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">Thus, the task of scheduling packets at every congestion point (whether there are priorities or not) must keep the queues short.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">IMO, far too much focus is currently maintained on "within router" algorithmics.  The problem of congestion is entirely a system-wide problem, not a router problem.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">Use a little queueing theory and control theory to understand this. It's non-standard queueing and control theory, because the control is "decentralized" and "distributed".</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">The design of the Internet *requires* no central controller. That's its design point for very good reasons. That's why we (not you kids) built it.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">One can imagine something called "5G" (not the Internet) that has a master world control center. It won't scale, but it is a fantasy of phone companies like BT and suppliers like ALU. Feel free to design that thing. Just don't think that would be an "Internet".</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">On Friday, June 14, 2019 5:44pm, "Dave Taht" <dave@taht.net> said:<br /><br /></p>
<div id="SafeStyles1560629632">
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">> <br />> This thread using unconventional markers for it is hard to follow.<br />> <br />> Luca Muscariello <muscariello@ieee.org> writes:<br />> <br />> > On Fri, Jun 7, 2019 at 8:10 PM Bob Briscoe <ietf@bobbriscoe.net><br />> > wrote:<br />> ><br />> ><br />> ><br />> ><br />> > I'm afraid there are not the same pressures to cause rapid<br />> > roll-out at all, cos it's flakey now, jam tomorrow. (Actually<br />> > ECN-DualQ-SCE has a much greater problem - complete starvation of<br />> > SCE flows - but we'll come on to that in Q4.)<br />> <br />> Answering that statement is the only reason why I popped up here.<br />> more below.<br />> <br />> > I want to say at this point, that I really appreciate all the<br />> > effort you've been putting in, trying to find common ground.<br />> <br />> I am happy to see this thread happen also, and I do plan to<br />> stay out of it.<br />> <br />> ><br />> > In trying to find a compromise, you've taken the fire that is<br />> > really aimed at the inadequacy of underlying SCE protocol - for<br />> > anything other than FQ.<br />> <br />> The SCE idea does, indeed work best with FQ, in a world of widely<br />> varying congestion control ideas as explored in the recent paper, 50<br />> shades of congestion control:<br />> <br />> https://arxiv.org/pdf/1903.03852.pdf<br />> <br />> > If the primary SCE proponents had<br />> > attempted to articulate a way to use SCE in a single queue or a<br />> > dual queue, as you have, that would have taken my fire.<br />> <br />> I have no faith in single or dual queues with ECN either, due to<br />> how anyone can scribble on the relevant bits, however...<br />> <br />> ><br />> ><br />> > But regardless, the queue-building from classic ECN-capable endpoints<br />> that<br />> > only get 1 congestion signal per RTT is what I understand as the main<br />> > downside of the tradeoff if we try to use ECN-capability as the dualq<br />> > classifier. Does that match your understanding?<br />> ><br />> > This is indeed a major concern of mine (not as major as the<br />> > starvation of SCE explained under Q4, but we'll come to that).<br />> <br />> I think I missed a portion of this thread. Starvation is impossible,<br />> you are reduced to no less than cwnd 2 (non-bbr), or cwnd 4 (bbr).<br />> <br />> Your own work points out a general problem with needing sub-packet<br />> windows with too many flows that cause excessive marking using CE, which<br />> so far as I know remains an unsolved problem.<br />> <br />> https://arxiv.org/pdf/1904.07598.pdf<br />> <br />> This is easily demonstrated via experiment, also, and the primary reason<br />> why, even with FQ_codel in the field, we generally have turned off ecn<br />> support at low bitrates until the first major release of sch_cake.<br />> <br />> I had an open question outstanding about the 10% figure for converting<br />> to drop sch_pie uses that remains unresolved.<br />> <br />> As for what level of compatability with classic transports in a single<br />> queue that is possible with a SCE capable receiver and sender, that<br />> remains to be seen. Only the bits have been defined as yet. Two<br />> approaches are being tried in public, so far.<br />> <br />> ><br />> > Fine-grained (DCTCP-like) and coarse-grained (Cubic-like)<br />> > congestion controls need to be isolated, but I don't see how,<br />> > unless their packets are tagged for separate queues. Without a<br />> > specific fine/coarse identifier, we're left with having to re-use<br />> > other identifiers:<br />> ><br />> > * You've tried to use ECN vs Not-ECN. But that still lumps two<br />> > large incompatible groups (fine ECN and coarse ECN) together.<br />> > * The only alternative that would serve this purpose is the flow<br />> > identifier at layer-4, because it isolates everything from<br />> > everything else. FQ is where SCE started, and that seems to be<br />> > as far as it can go.<br />> <br />> Actually, I was seeking a solution (and had been, for going on 5 years)<br />> to the "too many flows not getting out of slow start fast enough",<br />> problem, which you can see from any congested airport, public space,<br />> small office, or coffeeshop nowadays. The vast majority of traffic<br />> there does not consist of long duration high rate flows.<br />> <br />> Even if you eliminate the wireless retries and rate changes and put in a<br />> good fq_codel aqm, the traffic in such a large shared environment is<br />> mostly flows lacking a need for congestion control at all (dns, voip,<br />> etc), or in slow start, hammering away at ever increasing delays in<br />> those environments until the user stops hitting the reload button.<br />> <br />> Others have different goals and outlooks in this project and I'm<br />> not really part of that.<br />> <br />> I would rather like to see both approaches tried in an environment<br />> that had a normal mix of traffic in a shared environment like that.<br />> <br />> Some good potential solutions include reducing the slower bits of the<br />> internet back to IW4 and/or using things like initial spreading, both of<br />> which are good ideas and interact well with SCE's more immediate<br />> response curve, paced chirping also.<br />> <br />> ><br />> > Should we burn the last unicorn for a capability needed on<br />> > "carrier-scale" boxes, but which requires FQ to work? Perhaps yes<br />> > if there was no alternative. But there is: L4S.<br />> <br />> The core of the internet is simply overprovisioned, with fairly short<br />> queues. DCTCP itself did not deploy in very many places that I know of.<br />> <br />> could you define exactly what carrier scale means?<br />> <br />> ><br />> ><br />> ><br />> > I have a problem to understand why all traffic ends up to be<br />> > classified as either Cubic-like or DCTCP-like.<br />> > If we know that this is not true today I fail to understand why this<br />> > should be the case in the future.<br />> > It is also difficult to predict now how applications will change in<br />> > the future in terms of the traffic mix they'll generate.<br />> > I feel like we'd be moving towards more customized transport services<br />> > with less predictable patterns.<br />> ><br />> > I do not see for instance much discussion about the presence of RTC<br />> > traffic and how the dualQ system behaves when the<br />> > input traffic does not respond as expected by the 2-types of sources<br />> > assumed by dualQ.<br />> ><br />> > If my application is using simulcast or multi-stream techniques I can<br />> > have several video streams in the same link, that, as far as I<br />> > understand,<br />> > will get significant latency in the classic queue. Unless my app<br />> > starts cheating by marking packets to get into the priority queue.<br />> ><br />> > In both cases, i.e. my RTC app is cheating or not, I do not understand<br />> > how the parametrization of the dualQ scheduler<br />> > can cope with traffic that behaves in a different way to what is<br />> > assumed while tuning parameters.<br />> > For instance, in one instantiation of dualQ based on WRR the weights<br />> > are set to 1:16. This has to necessarily<br />> > change when RTC traffic is present. How?<br />> ><br />> > Is the assumption that a trusted marker is used as in typical diffserv<br />> > deployments<br />> > or that a policer identifies and punishes cheating applications?<br />> ><br />> > BTW I'd love to understand how dualQ is supposed to work under more<br />> > general traffic assumptions.<br />> ><br />> > Luca<br />> _______________________________________________<br />> Ecn-sane mailing list<br />> Ecn-sane@lists.bufferbloat.net<br />> https://lists.bufferbloat.net/listinfo/ecn-sane<br />> </p>
</div></font>