[solarexplorer]

Traffic shaping shaping implies dropping packets. You could try to buffer some of them to send them later when bandwidth is available, but you would run out of buffer space very quickly. Buffering and flow control is best left to the endpoints. Packet loss is common on the internet and protocols are designed to handle it well.

In this example I would rather be worried about the additional latency/overhead of copying all the packets to user space and back.

[alexgartrell]

I don't think latency is the primary issue here, as you're probably really far from your users and the hop is a mild cost compared to transiting the internet.

In my mind the bigger issue is limited throughput, packets per second are fundamentally limited by this approach (tun devices, at least in linux, are generally limited to a single packet per read). Ted even alludes to a 25% reduction in traffic, though it's unclear to me what the link speed is (likely 100M or 1G). In my experience, even with the latest and greatest in linux, you're not going to see reasonable packet rates, and you're still better off doing this type of stuff in the kernel.

That said, tun devices are super cool, and a great tool for anyone to have if they need to do weird stuff like low-level network testing, so I think this is a really cool post. You can read more about it for linux here: https://www.kernel.org/doc/Documentation/networking/tuntap.t...

[X-Istence]

Why does Linux make a difference here? The example uses OpenBSD, does OpenBSD have the same limitations?

[sgoody]

Thanks for the response. I knew that TCP handles dropped packets. But it seems like using an exceptional case for dealing with errors shouldn't be the norm. Is this also how more traditional traffic shaping works?

I presume that under circumstances such as this you end up generating a lot more network traffic than you need to, because of the overhead in retransmitting failed packets.

I know you couldn't buffer indefinitely because your buffer would overflow, but could you maybe delay the acknowledgements of packets, e.g. To simulate a slower link.

Not saying there's anything wrong with the approach or article, merely curious from the perspective of a non-networks guy.