<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Luca,<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 19/06/2019 14:02, Luca Muscariello
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAH8sseSQaCbknok--hf=DgwzCs3OnnkKjPy5bdLgnzjq7-+c_w@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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>
    </blockquote>
    [BB] I'm afraid this is a common misunderstanding. We have gone to
    great lengths to ensure that the coupled dualQ does not give any
    privilege, by separating out latency from throughput, so:<br>
    <ul>
      <li>It solely isolates traffic that gives /itself/ low latency
        from traffic that doesn't.</li>
      <li>It is very hard to get any throughput advantage from the
        mechanism, relative to a FIFO (see further down this email).</li>
    </ul>
    The phrase "relative to a FIFO" is important. In a FIFO, it is of
    course possible for flows to take more throughput than others. We
    see that as a feature of the Internet not a bug. But we accept that
    some might disagree...<br>
    <br>
    So those that want equal flow rates can add per-flow bandwidth
    policing, e.g. AFD, to the coupled dualQ. But that should be (and
    now can be) a separate policy choice. <br>
    <br>
    An important advance of the coupled dualQ is to cut latency without
    interfering with throughput.<br>
    <br>
    <br>
    <blockquote type="cite"
cite="mid:CAH8sseSQaCbknok--hf=DgwzCs3OnnkKjPy5bdLgnzjq7-+c_w@mail.gmail.com">
      <div dir="ltr">
        <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>
    </blockquote>
    [BB] This has all already been explained and discussed at length
    during various IETF meetings. I had an excellent student (Henrik
    Steen) act as a "red-team" guy. His challenge was: Can you contrive
    a mis-marking strategy with unresponsive traffic to cause any more
    harm than in a FIFO? We wanted to make sure that introducing a
    priority scheduler could not be exploited as a significant new
    attack vector.<br>
    <br>
    Have you looked at his thesis - the [<a
href="https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-09#ref-DualQ-Test"
      title=""Destruction Testing: Ultra-Low Delay using Dual Queue
      Coupled Active Queue Management"">DualQ-Test</a>] reference
    at the end of this subsection of the Security Considerations in the
    aqm-dualq-coupled draft:<br>
     <a moz-do-not-send="true"
href="https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-09#section-4.1.3">4.1.3. 
      Protecting against Unresponsive ECN-Capable Traffic</a> ?<br>
    (we ruled evaluation results out of scope of this already over-long
    draft - instead giving references).<br>
    <br>
    Firstly, when unresponsive traffic < link rate,
    counter-intuitively it doesn't matter which queue it classifies
    itself into. Any responsive traffic in either or both queues still
    shares out the remaining capacity as if the unresponsive traffic had
    subtracted from the overall capacity (like a FIFO). <br>
    <br>
    Beyond that, Henrik tested whether the persistent overload mechanism
    that switches off any distinction between the queues (<a
      moz-do-not-send="true"
href="https://github.com/L4STeam/sch_dualpi2_upstream/blob/master/net/sched/sch_dualpi2.c">code
      in the reference Linux implementation</a>, <a
href="https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-09#appendix-A.2">pseudocode
      and explanation in Appendix A.2</a>) left any room for mis-marked
    traffic to gain an advantage before the switch-over. There was a
    narrow region in which unresponsive traffic mismarked as ECN could
    strengthen its attack relative to the same attack on the Classic
    queue without mismarking. <br>
    <br>
    I presented a one-slide summary of Henrik's experiment here <a
href="https://datatracker.ietf.org/meeting/99/materials/slides-99-tcpm-ecn-adding-explicit-congestion-notification-ecn-to-tcp-control-packets-02#page=12">in
      2017 in IETF tcpm</a>.<br>
    I tried to make the legends self-explanatory as long as you work at
    it, but shout if you need it explained.<br>
    Each column of plots shows attack traffic at increasing fractions of
    the link rate; from 70% to 200%.<br>
    <br>
    Try to spot the difference between the odd columns and the even
    columns - they're just a little different in the narrow window
    either side of 100% - a sharp kink instead of a smooth kink. <br>
    I included log-scale plots of the bottom end of the range to magnify
    the difference.<br>
    <br>
    Yes, the system oscillates around the switch-over point, but you can
    see from the tcpm slide that the oscillations are also there in the
    3rd column (which emulates the same switch-over in a FIFO). So we
    haven't added a new problem.<br>
    <br>
    In summary, the advantage of mismarking was small and it was hard
    for the attacker not to trip the dualQ into overload state when it
    applies the same drop level in either queue. And that was when the
    victim traffic was just a predictable long-running flow. With normal
    less predictable victim traffic, I cannot think how to get this
    attack to be effective.<br>
    <br>
    <br>
    <blockquote type="cite"
cite="mid:CAH8sseSQaCbknok--hf=DgwzCs3OnnkKjPy5bdLgnzjq7-+c_w@mail.gmail.com">
      <div dir="ltr">
        <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>
    </blockquote>
    [BB] <br>
    1/ Queue protection is an alternative to overload protection, not an
    addition. <br>
    <ul>
      <li>The Linux implementation solely uses the overload mechanism,
        which is sufficient to prevent the priority scheduler amplifying
        a mismarking attack (whether ECN or DSCP).</li>
      <li>The DOCSIS implementation use per-flow queue protection
        instead.<br>
      </li>
    </ul>
    2/ Aligned incentives<br>
    <br>
    The coupled dualQ with just overload protection ensures incentives
    are aligned so that, normal developers won't intentionally mismark
    traffic. As explained at the start of this email:<br>
    <blockquote>the DualQ solely isolates traffic that gives /itself/
      low latency from traffic that doesn't. Low latency solely depends
      on the traffic's own behaviour. Traffic doesn't /get/ anything
      from the low latency queue, so there's no point mismarking to get
      into it.<br>
    </blockquote>
    However, incentives only address rational behaviour, not accidents
    and malice. That's why DOCSIS operators asked for Q protection - to
    protect against something accidentally or deliberately introducing
    bursty or excessive traffic into the low latency queue.<br>
    <br>
    The Linux code is sufficient under normal circumstances though.
    There are already other mechanisms that deal with the worms,
    trojans, etc. that might launch these attacks. <br>
    <br>
    3/ DOCSIS Q protection does not black-list flows. <br>
    <br>
    It redirects certain /packets/ from those flows with the highest
    queuing scores into the Classic queue, only if those packets would
    otherwise risk a threshold delay for the low latency queue being
    exceeded. <br>
    <br>
    If a flow has a temporary wobble, some of its packets get redirected
    to protect the low latency queue, but if it gets back on track, then
    there's just no further packet redirection. <br>
    <br>
    <blockquote type="cite"
cite="mid:CAH8sseSQaCbknok--hf=DgwzCs3OnnkKjPy5bdLgnzjq7-+c_w@mail.gmail.com">
      <div dir="ltr">
        <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>
    </blockquote>
    4/ Slight punishment is a feature, not a bug<br>
    <br>
    If an unresponsive flow is well-paced and not contributing to
    queuing, it will accumulate only a low queuing score, and experience
    no redirected packets.<br>
    <br>
    If it is contributing to queuing and it is mismarking itself, then Q
    Prot will redirect some of its packets, and the continual reordering
    will (intentionally) give it worse service quality. This deliberate
    slight punishment gives developers a slight incentive to mark their
    flows correctly.<br>
    <br>
    I could explain more about the queuing score (I think I already did
    for you on these lists), but it's all in Annex P of <a
      moz-do-not-send="true"
      href="https://specification-search.cablelabs.com/CM-SP-MULPIv3.1">the
      DOCSIS spec</a>. and I'm trying to write a stand-alone document
    about it at the moment.<br>
    <br>
    <br>
    <blockquote type="cite"
cite="mid:CAH8sseSQaCbknok--hf=DgwzCs3OnnkKjPy5bdLgnzjq7-+c_w@mail.gmail.com">
      <div dir="ltr">
        <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, </div>
      </div>
    </blockquote>
    [BB] As above, the Linux implementation works and aligns incentives
    without Q Prot, which is merely an optional additional protection
    against accidents and malice.<br>
    <br>
    (and there's no flow black-list).<br>
    <br>
    <br>
    <blockquote type="cite"
cite="mid:CAH8sseSQaCbknok--hf=DgwzCs3OnnkKjPy5bdLgnzjq7-+c_w@mail.gmail.com">
      <div dir="ltr">
        <div>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. <br>
        </div>
      </div>
    </blockquote>
    <br>
    I do find the tone of these emails rather disheartening. We've done
    all this work that we think is really cool. And all we get in return
    is criticism in an authoritative tone as if it is backed by
    experiments. But so far it is not. There seems to be a presumption
    that we are not professional and we are somehow not to be trusted to
    have done a sound job.<br>
    <br>
    Yes, I'm sure mistakes can be found in our work. But it would be
    nice if the tone of these emails could become more constructive.
    Possibly even some praise. There seems to be a presumption of
    disrespect that I'm not used to, and I would rather it stopped.<br>
    <br>
    Sorry for going silent recently - had too much backlog. I'm working
    my way backwards through this thread. Next I'll reply to Jake's
    email, which is, as always, perfectly constructive.<br>
    <br>
    Cheers<br>
    <br>
    <br>
    Bob<br>
    <br>
    <blockquote type="cite"
cite="mid:CAH8sseSQaCbknok--hf=DgwzCs3OnnkKjPy5bdLgnzjq7-+c_w@mail.gmail.com">
      <div dir="ltr">
        <div>Luca</div>
      </div>
    </blockquote>
    <blockquote type="cite"
cite="mid:CAH8sseSQaCbknok--hf=DgwzCs3OnnkKjPy5bdLgnzjq7-+c_w@mail.gmail.com">
      <div dir="ltr"><br>
        <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"
            moz-do-not-send="true">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" moz-do-not-send="true">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>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Ecn-sane mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ecn-sane@lists.bufferbloat.net">Ecn-sane@lists.bufferbloat.net</a>
<a class="moz-txt-link-freetext" href="https://lists.bufferbloat.net/listinfo/ecn-sane">https://lists.bufferbloat.net/listinfo/ecn-sane</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
________________________________________________________________
Bob Briscoe                               <a class="moz-txt-link-freetext" href="http://bobbriscoe.net/">http://bobbriscoe.net/</a></pre>
  </body>
</html>