1. 37

  2. 3

    It jumps out to me that you had to include an estimate of your connection speed in the configuration. What’s the behavior if Comcast either gives you a free performance boost, or runs in a degraded state with lower performance?

    1. 3

      There’s not much you can do about that. You could always monitor it with a cron job and update the params/rules with a script I suppose.

      1. 3

        Right, but what happens? How does the system behave in those circumstances?

        1. 7

          If the actual bandwidth is more than what’s specified, it won’t hurt but you will be artificially limiting yourself. If it is less than what’s specified, then it probably won’t work very well because even though the buffers on your router will remain empty (LAN<->WAN both at 1Gbps), the next device in sequence will start buffering and that’s outside of your control at this point. In other words, you want the router that is doing QoS to be the bottleneck.

          On OpenBSD, if you don’t specify the bandwidth param, then it will default to whatever rate the NICs are running at (10/100/1000Mbps for example).

          1. 3


    2. 1

      The bufferbloat and quality were actually worse with the change in my case. Maybe my EdgeRouter Lite can’t handle it or something.

      1. 4

        I looked up a lot of discussion on this over in their forums…maybe some of that could help?

        1. 1

          Thanks but I’m not sure if it could help since I’m running OpenBSD on it and not the default OS.

      2. 1

        Why is there a bandwidth limit on the outq? That shouldn’t be necessary. Maybe it’s just the implementation in pf, but it’s totally not required in FreeBSD’s IPFW.

        Point is that for incoming traffic you cannot control the flow of packets so you have to fake a lower bandwidth link by artificially dropping packets to slow down the sender. For outbound traffic you have full control of the sending rate and the ability to detect congestion early so limiting your max outbound bandwidth should not be required.

        1. 1

          Your home router doesn’t know the uplink bandwidth of your cable modem connection to your ISP. So you have to dial it in for the FQ-CoDel algorithm to know how to achieve the right send rate to flush the buffers quickly and fairly enough.

          1. 1

            Your home router doesn’t know the uplink bandwidth of your cable modem connection to your ISP

            That doesn’t matter. The firewall has the ability to detect congestion of the outbound traffic and apply queueing/shaping to immediately control the sending rate and prevent buffer bloat. It shouldn’t need a bandwidth limitation. That’s only required for inbound traffic where you cannot control the sending rate, so you fake a smaller pipe with reasonable overhead (~10%) to drop packets early to slow down the sender and prevent severe congestion/buffer bloat.

            All I can tell you is that I am not restricting any bandwidth for outbound with FQ-CoDel via DummyNet+IPFW and I get passing test results every time. I only have to restrict on the incoming. So something is different between your pf implementation and my DummyNet implementation. Does the OpenBSD pf implementation include ECN (Explicit Congestion Notification) ?

            ipfw pipe 1 config delay 0
            ipfw pipe 2 config bw 220Mbit/s delay 0
            ipfw sched 1 config pipe 1 type fq_codel
            ipfw sched 2 config pipe 2 type fq_codel
            ipfw queue 1 config sched 1
            ipfw queue 2 config sched 2
            $cmd 00100 queue 1 ip from any to any out via $pif
            $cmd 00101 queue 2 ip from any to any in via $pif

            Here is my test result: http://www.dslreports.com/speedtest/35535303