<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Thank you, Jonathan - I will add the ethernet keyword and run
      some tests to get a more precise reading of exactly what 1% should
      be in both directions and also play with the "dual-*host" settings
      and post back my findings or more than likely a few more questions
      :-)</p>
    <p>Marco<br>
    </p>
    <div class="moz-cite-prefix">On 9/22/2019 9:26 PM, Jonathan Morton
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:F35FA667-3AE9-487E-9747-2EFCB6627556@gmail.com">
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">I have searched every nook and cranny of the bloated internet looking for any information I can find on whether Frontier/Verizon FIOS (assuming the only difference between the service offered by both Frontier and Verizon is in name only) requires any special framing parameters passed on to sch_cake's overhead settings. Most mentions of cake/fq/scm/etc and FIOS are ether very dated and inconclusive or I find messages and forum posts asking questions a lot like this one.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
I don't know precisely what framing FIOS uses.  However, most provisioning shapers used by cable/fibre ISPs operate on Ethernet frames, so if you use the "ethernet" keyword you should match what the shaper is doing.  The proof of the pudding is in the eating, of course.

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Currently this is what I have and am also curious if I should be using the "nat" keyword for both ingress and egress? I'm not entirely sure - see below:
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
If your box is doing NAT *and* you are using a flow-mode that depends on accurate internal host information, then you should have the "nat" keyboard on in both directions.  Otherwise it's more efficient to switch it off, though leaving it on does no harm otherwise.

The default flow-mode is "triple-isolate", which does use internal host information.  So do the "dual-srchost" and "dual-dsthost" modes, which are more precise but need you to specify which direction the traffic is flowing.  The "besteffort" and "flows" modes do not, but you should only use those if you're deliberately experimenting with something.

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">In absence of framing compensation I figured I should just go extreme by reserving more bandwidth than the qdisc needs because I also read somewhere I think that mentioned that if you don't compensate and are incorrect everything stops working as opposed to if you over compensate you might lose out on bandwidth but you'll still win in the latency department.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
That's approximately correct, close enough for actual practice.  It's also why we included the "conservative" keyword, which applies the maximum amount of framing compensation that is ever likely to be seen in the wild - much more than you'd expect to see on a cable/fibre link, but only slightly more than on most ADSL lines.

The overhead compensation matters more with small packets than with the larger ones used for bulk transfers; for the latter, reserving a little more bandwidth will appear to make everything work.  For fibre I would try "ethernet" and reserve about 1% bandwidth each way, then if possible test to see whether there is any bloat.

 - Jonathan Morton</pre>
    </blockquote>
  </body>
</html>