Hacker News Reader

Comment by ra1n85 | Hacker News Reader

Bufferbloat is a side affect of congestion or microbursts, and not the primary cause of poor voice calls. Either packets get dropped (shallow buffer) or queued (enough buffer), and in both cases the quality of the call will suffer.

Mitigation: Don't congest. If you need to, mark VOIP traffic with a DSCP value that has queues that are serviced prior to all others (e.g., EF, DSCP46).

View on HN

Yes. I'm a Republic Wireless (WiFi VoIP phone) customer. They mark their RTP packets with DSCP 48 (CS6 / ToS 192) and their SIP packets with DSCP 56 (CS7 / ToS 224). I limit ingress & egress bandwidth on my home router (a Mikrotik), and prioritize flows with those DSCPs above all other traffic.

The result is that even when my pipe is completely full, VoIP packet latency is practically unaffected. Compare to ~3 s latencies I would incur by Comcast's awful traffic shaping.

Applications do it already, but edge routers are adept at ignoring these flags or applying them only to their own service.

So that you use it and not competition.

Net neutrality would be the antidote.

You're correct, most applications do.

QoS/CoS services are best when clearly spelled out in service agreements. Providers may clear markings, but likely because either they don't want to have a free for all when it comes to their queues, or because they didn't purchase the gear that offers the rich queuing needed.

If those flags provide better quality of service, why am I not applying them to all of my traffic? Any attempt to "know" if my use is legitimate would undermine network neutrality.

Sure, you could make yourself crazy trying to prioritize all the traffic with varying kinds of flags.

Or you could just let an algorithm (SQM - fq_codel or cake) automatically determine which flows are sending more than their fair share of traffic into the bottleneck link, and offer backpressure to slow those applications down, so other applications work well.

re: net neutrality. That applies to whether my ISP (or any provider upstream in the Internet) should prioritize packets/data from various sources toward (or from) me. The answer should be, No. My contract with my ISP is that I get X mbps of data. The contract doesn't say the ISP will provide higher priority or data rate for service Y over service Z...

SQM has no effect on net neutrality: I'm simply configuring my own router to prioritize the data that I'm requesting (or sending). My ISP should handle them in a totally neutral way...

Yes, Don't Congest. But you can spend your life marking various kinds of traffic (many apps already do mark it, as someone down-thread mentioned), and pray that your router (and remote equipment) handles the markings properly.

Or just use SQM with Cake qdisc. It actually looks at the "sojourn time" for packets in various streams/flows of data and offers backpressure for sessions that are generating queues of data: all the other flows "go right through" without a lot of other settings.

I have almost no bufferbloat when downloading (about 1ms) but about 300ms when uploading.

What does this mean?

I didn't look at that tool, but just reading this suggests that you're being shaped/policed more aggressively on egress (in the direction of your provider) than you are on ingress. Shaping and policing (typically) both use the same mechanisms as interface buffers to temporarily store packets in order to prevent congestion/discards. The distinction between them is that shaping actively buffers packets, where policing will more aggressively drop them (and aim to trigger a TCP congestion event) - in most cases, policing will involve a burst bucket that is somewhat similar to a shallow queue.

This would make sense if you have a higher bit rate from your provider for down vs up.

What speed connection do you have, and what speed connection did that tool report?

If your connection is fast enough that that tool is unable to max it out for whatever reason (say you're on a poor WiFi connection), you will experience no bufferbloat.

Reply on news.ycombinator.com