<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 7, 2019 at 8:10 PM Bob Briscoe <<a href="mailto:ietf@bobbriscoe.net">ietf@bobbriscoe.net</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">
  
    
  
  <div bgcolor="#FFFFFF"><br><blockquote type="cite">
    </blockquote>
     I'm afraid there are not the same pressures to cause rapid roll-out
    at all, cos it's flakey now, jam tomorrow. (Actually ECN-DualQ-SCE
    has a much greater problem - complete starvation of SCE flows - but
    we'll come on to that in Q4.)<br>
    <br>
    I want to say at this point, that I really appreciate all the effort
    you've been putting in, trying to find common ground. <br>
    <br>
    In trying to find a compromise, you've taken the fire that is really
    aimed at the inadequacy of underlying SCE protocol - for anything
    other than FQ. If the primary SCE proponents had attempted to
    articulate a way to use SCE in a single queue or a dual queue, as
    you have, that would have taken my fire. <br>
    <br>
    <blockquote type="cite">
      <pre class="gmail-m_-3668415976964028159moz-quote-pre">But regardless, the queue-building from classic ECN-capable endpoints that
only get 1 congestion signal per RTT is what I understand as the main
downside of the tradeoff if we try to use ECN-capability as the dualq
classifier.  Does that match your understanding?</pre>
    </blockquote>
    This
    is indeed a major concern of mine (not as major as the starvation of
    SCE explained under Q4, but we'll come to that).<br>
    <br>
    Fine-grained (DCTCP-like) and coarse-grained (Cubic-like) congestion
    controls need to be isolated, but I don't see how, unless their
    packets are tagged for separate queues. Without a specific
    fine/coarse identifier, we're left with having to re-use other
    identifiers:<br>
    <ul>
      <li>You've tried to use ECN vs Not-ECN. But that still lumps two
        large incompatible groups (fine ECN and coarse ECN) together.</li>
      <li>The only alternative that would serve this purpose is the flow
        identifier at layer-4, because it isolates everything from
        everything else. FQ is where SCE started, and that seems to be
        as far as it can go.<br>
      </li>
    </ul>
    Should we burn the last unicorn for a capability needed on
    "carrier-scale" boxes, but which requires FQ to work? Perhaps yes if
    there was no alternative. But there is: L4S.<br>
    <br></div></blockquote><div><br></div><div>I have a problem to understand why all traffic ends up to be classified as either Cubic-like or DCTCP-like. </div><div>If we know that this is not true today I fail to understand why this should be the case in the future. </div><div>It is also difficult to predict now how applications will change in the future in terms of the traffic mix they'll generate.</div><div>I feel like we'd be moving towards more customized transport services with less predictable patterns.</div><div><br></div><div>I do not see for instance much discussion about the presence of RTC traffic and how the dualQ system behaves when the </div><div>input traffic does not respond as expected by the 2-types of sources assumed by dualQ.</div><div><br></div><div>If my application is using simulcast or multi-stream techniques I can have several video streams in the same link,  that, as far as I understand,</div><div>will get significant latency in the classic queue. Unless my app starts cheating by marking packets to get into the priority queue.</div><div><br></div><div>In both cases, i.e. my RTC app is cheating or not, I do not understand how the parametrization of the dualQ scheduler </div><div>can cope with traffic that behaves in a different way to what is assumed while tuning parameters. </div><div>For instance, in one instantiation of dualQ based on WRR the weights are set to 1:16.  This has to necessarily </div><div>change when RTC traffic is present. How?</div><div><br></div><div><div>Is the assumption that a trusted marker is used as in typical diffserv deployments</div><div>or that a policer identifies and punishes cheating applications?</div></div><div><br></div><div>BTW I'd love to understand how dualQ is supposed to work under more general traffic assumptions.</div><div><br></div><div>Luca</div><div><br></div><div> </div></div></div>