<div dir="ltr">Jake,<div><br></div><div>Yes, that is one scenario that I had in mind. </div><div>Your response comforts me that I my message was not totally unreadable. </div><div><br></div><div>My understanding was</div><div>- There are incentives to mark packets if they get privileged treatment because of that marking. This is similar to the diffserv model with all the consequences in terms of trust.</div><div>- Unresponsive traffic in particular (gaming, voice, video etc.) has incentives to mark. Assuming there is x% of unresponsive traffic in the priority queue, it is non trivial to guess how the system works.</div><div>- in particular it is easy to see the extreme cases, </div><div> (a) x is very small, assuming the system is stable, the overall equilibrium will not change. </div><div> (b) x is very large so the dctcp like sources fall back to cubic like and the systems behave almost like a single FIFO.</div><div> (c) in all other cases x varies according to the unresponsive sources' rates. </div><div> Several different equilibria may exist, some of which may include oscillations. Including oscillations of all fallback mechanisms.</div><div>The reason I'm asking is that these cases are not discussed in the I-D documents or in the references, despite these are very common use cases.</div><div><br></div><div>If we add the queue protection mechanism, all unresponsive flows that are caught cheating are registered in a blacklist and always scheduled in the non-priority queue.</div><div>It that happens unresponsive flows will get a service quality that is worse than if using a single FIFO for all flows.</div><div><br></div><div>Using a flow blacklist brings back the complexity that dualq is supposed to remove compared to flow-isolation by flow-queueing.</div><div>It seems to me that the blacklist is actually necessary to make dualq work under the assumption that x is small, because in the other cases the behavior</div><div>of the dualq system is unspecified and likely subject to instabilities, i.e. potentially different kind of oscillations. </div><div><br></div><div>Luca</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 18, 2019 at 9:25 PM Holland, Jake <<a href="mailto:jholland@akamai.com">jholland@akamai.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Bob and Luca,<br>
<br>
Thank you both for this discussion, I think it helped crystallize a<br>
comment I hadn't figured out how to make yet, but was bothering me.<br>
<br>
I’m reading Luca’s question as asking about fixed-rate traffic that does<br>
something like a cutoff or downshift if loss gets bad enough for long<br>
enough, but is otherwise unresponsive.<br>
<br>
The dualq draft does discuss unresponsive traffic in 3 of the sub-<br>
sections in section 4, but there's a point that seems sort of swept<br>
aside without comment in the analysis to me.<br>
<br>
The referenced paper[1] from that section does examine the question<br>
of sharing a link with unresponsive traffic in some detail, but the<br>
analysis seems to bake in an assumption that there's a fixed amount<br>
of unresponsive traffic, when in fact for a lot of the real-life<br>
scenarios for unresponsive traffic (games, voice, and some of the<br>
video conferencing) there's some app-level backpressure, in that<br>
when the quality of experience goes low enough, the user (or a qoe<br>
trigger in the app) will often change the traffic demand at a higher<br>
layer than a congestion controller (by shutting off video, for<br>
instance).<br>
<br>
The reason I mention it is because it seems like unresponsive<br>
traffic has an incentive to mark L4S and get low latency. It doesn't<br>
hurt, since it's a fixed rate and not bandwidth-seeking, so it's<br>
perfectly happy to massively underutilize the link. And until the<br>
link gets overloaded it will no longer suffer delay when using the<br>
low latency queue, whereas in the classic queue queuing delay provides<br>
a noticeable degradation in the presence of competing traffic.<br>
<br>
I didn't see anywhere in the paper that tried to check the quality<br>
of experience for the UDP traffic as non-responsive traffic approached<br>
saturation, except by inference that loss in the classic queue will<br>
cause loss in the LL queue as well.<br>
<br>
But letting unresponsive flows get away with pushing out more classic<br>
traffic and removing the penalty that classic flows would give it seems<br>
like a risk that would result in more use of this kind of unresponsive<br>
traffic marking itself for the LL queue, since it just would get lower<br>
latency almost up until overload.<br>
<br>
Many of the apps that send unresponsive traffic would benefit from low<br>
latency and isolation from the classic traffic, so it seems a mistake<br>
to claim there's no benefit, and it furthermore seems like there's<br>
systematic pressures that would often push unresponsive apps into this<br>
domain.<br>
<br>
If that line of reasoning holds up, the "rather specific" phrase in<br>
section 4.1.1 of the dualq draft might not turn out to be so specific<br>
after all, and could be seen as downplaying the risks.<br>
<br>
Best regards,<br>
Jake<br>
<br>
[1] <a href="https://riteproject.files.wordpress.com/2018/07/thesis-henrste.pdf" rel="noreferrer" target="_blank">https://riteproject.files.wordpress.com/2018/07/thesis-henrste.pdf</a><br>
<br>
PS: This seems like a consequence of the lack of access control on<br>
setting ECT(1), and maybe the queue protection function would address<br>
it, so that's interesting to hear about.<br>
<br>
But I thought the whole point of dualq over fq was that fq state couldn't<br>
scale properly in aggregating devices with enough expected flows sharing<br>
a queue? If this protection feature turns out to be necessary, would that<br>
advantage be gone? (Also: why would one want to turn this protection off<br>
if it's available?)<br>
<br>
<br>
</blockquote></div>