addresses in traffic shaping rules for IPv6?

[meyergru]

I doubt that. I had the same problem, when my MTU settings were wrong and once more, when I used the traffic shaper and found that sometimes, you need a reboot to apply the traffic shaper settings correctly. That was discussed here: https://forum.opnsense.org/index.php?topic=46990.0, but I thought the problem had been fixed in the meantime.

If the tests fails for you, then something is wrong in your setup. Maybe, you use adblockers that interfere with the tests on those pages.

[Seimus]

Why is the limiting by the ISP so terrible?

Ask your ISP.
ISPs usually don't care to accommodate possible congestion in their networks. The bufferbloat community developed a LibreQoS platform that is targeted to be used by ISP, they try to make ISPs to take advantage of this to mitigate buffer bloat in their networks. But once again most of the ISPs do not care.

During that speedtest, the numbers for the latency keep changing all the time, so I can't really tell what it is.  Upload latency seems to be much lower than the download latency.

You have to check the latency number after the test is done if you do ooklaspeedtest... But, just go with the other two test sites they will tell you more precisely.

When I set the pipe numbers to half the bandwiths I'm supposed to have, bandwith is lower and the latency seems the same.  When I set the numbers to double the bandwidth, latency is like half and I'm getting about 10% more bandwidth than I'm supposed to get.  When I set the numbers to 10% over what I'm supposed to get --- and that is more than the limits the ISP suggests --- I'm getting better bandwidth and lower latency.

This doesn't give any sense at all. Plus the way how you previously described that you check for latency during load, I am honestly not sure if you even get proper readings in first place.

I can only guess that shaping on the router doesn't kick in because I'm not reaching the bandwith.  So I guess I could as well delete all the settings because they don't give any measurable benefits and only lower the usable bandwidth.

FQ_C is an active AQM, even if you are not reaching the "BW" it measures time of each packet within the flow/queue. Once again I am honestly not sure if you even get proper readings in first place.

So what is the point of this traffic shaping?  It seems to only lower the bandwith I'm getting and to increase the latency.  This doesn't make sense.

This is just not true. If you are having worse latency when doing FQ_C, most likely you do something wrong. Or you don't properly read the output of the testing results.

BTW, there's one difference with no traffic shaping: at the start of the test, download bandwidth may spike up to about over 2.5 times of what I'm supposed to get before it goes down.  With traffic shaping, that doesn't happen.  But does it even matter?

It does matter, that latency bump you see on start is cause by burst of traffic. This causes a lot of problems with start of transmissions and application startups.

What do you suggest?  Should I just delete the settings?

Read the documentation and properly read the outputs of the tests. Because from what I read so far I am really not sure you read the outputs of the test correctly.

Regards,
S.

[defaultuserfoo]

As far as I can tell, the latency shown by the ookla speedtest shows the last value that showed up while the test was running.  So that value is some more or less random number and not even an average.  I'd expect the test to run for a couple weeks at least to provide a good average and meaningful results.

So no, I don't think I'm reading the output incorrectly.

Why should there be a problem with latency at the start of the test when no traffic shaping on the router is in place?  It's not like the transmitted data would arrive later because the buffers are full.  A single packet may arrive later when a buffer is full, but if there were traffic shaping in place, such a packet would be either dropped and later retransmitted, and/or it would be sent later.  So the latency might be not higher, or not lower.

What would explain that there would be higher latency in regards to the data that is transmitted whithout traffic shaping?  When the transfer is sustained, the bandwidth settles at the limit anyway.

I can imagine that certain types (i. e. marked) packets could be made to experience less latency by giving those a preference over other packets, but the basic traffic shaping that limits the usage of the overall bandwidth doesn't do that -- or at least I didn't configure any such preferences myself.

[meyergru]

Now, that is not the way it works. Of course you are seeing changing numbers without traffic shaping. That is exactly the pumping effect that traffic shaping tries to avoid.

By dropping packets earlier via traffic shaping, you can avoid the pumping effect over high BDP (bandwidth * delay product) links. If the other side does not get notified early about the buffer being overrun, it will pump data into the pipe which will subsequently get discarded. Then TCP relies on the retry mechanism to reget the dropped packets. Over a high-latency connection, it simply takes too long to accomodate for small buffers at the target.

Thus, it is better if the target (i.e.: you) signals early when it it gets overwhelmed by the amount of data the source (i.e.: any website you open) can pump into its uplink, which is often 10x or more than what your downlink can chew.

[defaultuserfoo]

Now, that is not the way it works. Of course you are seeing changing numbers without traffic shaping. That is exactly the pumping effect that traffic shaping tries to avoid.

Are you referring to the bandwidth or to the latency?  Bandwidth settles in after the spike at the start.  The latency continues to go up and down during the test no matter what.  When the bandwith usage is over, the last number that showed up during the test continues to be displayed.

By dropping packets earlier via traffic shaping, you can avoid the pumping effect over high BDP (bandwidth * delay product) links. If the other side does not get notified early about the buffer being overrun, it will pump data into the pipe which will subsequently get discarded. Then TCP relies on the retry mechanism to reget the dropped packets. Over a high-latency connection, it simply takes too long to accomodate for small buffers at the target.

How does the other side get notified about the buffers being overrun?  The traffic shaping on my router doesn't have any information about the conditions of the buffers that may be between the router and the target and thus has no way to inform the target about their conditions.

What does it matter where the packets are being dropped?  One way or another, some are being dropped somewhere.

Thus, it is better if the target (i.e.: you) signals early when it it gets overwhelmed by the amount of data the source (i.e.: any website you open) can pump into its uplink, which is often 10x or more than what your downlink can chew.

My router doesn't get overwhelmed.  The bandwidth is limited somewhere else before it ever reaches my router.  The ISP allows only so much bandwidth to go through my connection, and my router doesn't have any influence over that.  Same goes for upstream, it doesn't overwhelm the router but the ISP limits it somewhere else.

The only thing my router can do is limit the bandwidth even further.  And why would I want it to do that?

It still doesn't make sense.

[meyergru]

I get why you are skeptical — it really sounds like "slowing yourself down on purpose" would not help. But the key is that traffic shaping is not about speed, it is about control.

Without shaping, your router sends and receives as fast as it can until something upstream (your ISP) gets overwhelmed. Packets then pile up in the ISP's queue, latency goes through the roof, and the sender (like a website or download server) does not notice the congestion until a packet finally gets dropped far away. That delay in feedback is what causes the up-and-down "pumping" effect you see.

When you enable shaping, your router makes sure your own queue is the first place that fills up — not the ISP's. It starts dropping or delaying packets slightly earlier, so the congestion signals (packet delay or loss) happen right at your end. TCP reacts much faster, keeping the link steady and latency low.

That is easy to see on the upload side, but it actually helps downloads too. TCP slow start and congestion control work based on the acknowledgments (ACKs) your system sends back upstream. If your upload queue gets bloated, those ACKs get delayed — which makes the sender think the link is slower than it really is, then it overshoots and backs off again. It is a mess of ramp-ups and stalls. By shaping your outgoing traffic, you keep those ACKs flowing smoothly, which makes your downloads smoother too.

And if you shape downstream directly (some routers can), you do the same thing on incoming packets: you hold them just before they hit your LAN instead of letting the ISP's buffer clog up. That way, you control the bottleneck and the TCP sender sees early feedback during slow start, preventing those massive bursts that cause latency spikes.

You can see this in action: Do a ping test or play an online game while maxing out your connection — watch the latency jump without shaping. Then turn TS on and do it again. Pings stay steady, downloads are smoother, and everything just feels "snappier". That is basically what most test sites proposed at bufferbloat.net do.

So yes — it might sound like limiting yourself for no reason, but shaping actually moves the bottleneck to where you can control it. The physics of TCP feedback do not care where the limit is, just how quickly the sender learns about it. Also, some ISPs already do a good work at adressing this. If your measurements are fine without traffic shaping enabled, then leave it be.

Other than that, my suggestion is: Try it first, measure the pings, then argue. 😄

P.S.: Do you really think so many people would think about this, fine-tune it and/or use it, if it were useless?

[defaultuserfoo]

I get why you are skeptical — it really sounds like "slowing yourself down on purpose" would not help. But the key is that traffic shaping is not about speed, it is about control.

Without shaping, your router sends and receives as fast as it can until something upstream (your ISP) gets overwhelmed. Packets then pile up in the ISP's queue, latency goes through the roof, and the sender (like a website or download server) does not notice the congestion until a packet finally gets dropped far away. That delay in feedback is what causes the up-and-down "pumping" effect you see.

I'm not seeing a pumping effect.  It can be expected that there's a spike at the start of the test before the parties involved settle on a bandwidth, and I'm not seeing any disadvantages from that.  I see big advantages because I get about 10% higher bandwidth though.  So I disabled it and am not seeing any disadvantages, either.

When you enable shaping, your router makes sure your own queue is the first place that fills up — not the ISP's. It starts dropping or delaying packets slightly earlier, so the congestion signals (packet delay or loss) happen right at your end. TCP reacts much faster, keeping the link steady and latency low.

I think you have a misconception about latency.  Reducing the bandwidth through shaping only makes it so that the packets get delayed at a different place, i. e. at the router.  That means that they are being sent later and arrive later.  Without traffic shaping, the packets are being sent earlier and are then delayed at a different place, so they are being sent earlier and arrive later.

The outcome is the same.  The disadvantage is that you can not use the available bandwidth but loose about 10%.  Why would I want that?

That is easy to see on the upload side, but it actually helps downloads too.

Upload latency according to the speedtest is between 1 and 6ms.  Traffic shaping has no influence on that.  I have doubts that these values are correct, but that's what the test says.

TCP slow start and congestion control work based on the acknowledgments (ACKs) your system sends back upstream. If your upload queue gets bloated, those ACKs get delayed — which makes the sender think the link is slower than it really is, then it overshoots and backs off again. It is a mess of ramp-ups and stalls. By shaping your outgoing traffic, you keep those ACKs flowing smoothly, which makes your downloads smoother too.

That's not what the test shows.  It shows a spike at the start and after that, it settles on a bandwidth.  Acknowledging the packets seems to work fine.  That is what is to be expected.

And if you shape downstream directly (some routers can), you do the same thing on incoming packets: you hold them just before they hit your LAN instead of letting the ISP's buffer clog up. That way, you control the bottleneck and the TCP sender sees early feedback during slow start, preventing those massive bursts that cause latency spikes.

I have not seen or experienced latency spikes with or without shaping.

You can see this in action: Do a ping test or play an online game while maxing out your connection — watch the latency jump without shaping. Then turn TS on and do it again. Pings stay steady,

What do you suggest I ping?

downloads are smoother, and everything just feels "snappier". That is basically what most test sites proposed at bufferbloat.net do.

If anything, things are snappier with traffic shaping disabled.

So yes — it might sound like limiting yourself for no reason, but shaping actually moves the bottleneck to where you can control it. The physics of TCP feedback do not care where the limit is, just how quickly the sender learns about it.

That's what I've been saying, the packets are being delayed one way or another.  When the bottleneck is closer to the sender, I can assume that the sender learns sooner where the limit is.  Creating the bottlneck the furthest away from the sender as it possibly can would be the worst setup.

After all experimentation I've done, I still can only say that when you have issues that would seem to make traffic shaping useful, the issues don't go away with traffic shaping, and the only solution is to get more bandwidth.

Also, some ISPs already do a good work at adressing this. If your measurements are fine without traffic shaping enabled, then leave it be.

This one suggests I enable traffic shaping.  They didn't say that before I upgraded to more bandwidth.  I wouldn't have bothered with it if they hadn't suggested it and if I hadn't been curious.

Other than that, my suggestion is: Try it first, measure the pings, then argue. 😄

I'll try that, but what should I ping?

I'm curious about it.  In practise, it won't make a difference because I'm the only user of this connection, so there's noone else who would use all the bandwidth and cause delays for me.  Reducing the usable bandwidth for myself is more disadvantageous than anything else.

P.S.: Do you really think so many people would think about this, fine-tune it and/or use it, if it were useless?

People say lots of things.  So far, no people have actually shown any benefit of traffic shaping to me.  My own experimentations always have shown no benefits of traffic shaping.

I've even tried it with a 348Kbit connection.  You would think that traffic shaping makes all the difference, but no, it doesn't.  The congestion on a connection with so little bandwidth overcomes all traffic shaping, and it's not really usable nowadays, shaping or not.