Hacker News Reader

Comment by isostatic | Hacker News Reader

Do you want to have jitter, or do you want loss?

In reality I don't see buffer bloat on the internet adding jitter of more than a few milliseconds. I do see loss though or 20, 50, even 100ms. I'd rather have 50ms of jitter than 50ms of loss, but that's just my application.

View on HN

Why would you have to choose either?

fq_codel and cake use a tiny bit of packet loss to get a sending host to back off, for example to keep a large download flow within the limits of your home link. Other flows aren't affected.

Bufferbloat regularly adds hundreds of ms on home internet connections, you can get an indication of your bufferbloat on http://www.dslreports.com/speedtest

Not on my connection. I would rather my UDP packet arrive 30ms late than not arrive - especially on high latency links where I want to process the packet before a 300ms round trip nack/retransmit has a chance to work.

I don't see any buffer bloat or excessive jitter on my home internet (at least on wired connection) on BT ftth.

Note that the bufferbloat choice for me is whether or not I want my packets to arrive 1.5 seconds late, not 30ms.

Anecdotally, I've seen larger amounts of packet loss and jitter when TCP accelerates faster into a loss event. The small amount of preventative loss reduces both of these values.

there is no such thing as 50ms of loss. Loss, when your queue is short, is recovered from in an round trip. Bloat on the internet can add seconds of jitter. ( http://www.dslreports.com/speedtest/results/bufferbloat)

But, I too am allergic to loss. fq_codel supports ECN, (explicit congestion notification), which is enabled, now, universally by IOS. As near as I can tell, the ECN usage of 6% (https://www.ietf.org/proceedings/98/slides/slides-98-maprg-t... ) in france is almost entirely from free.fr's deployment of fq_codel which they enabled by default in 2012 (!!!!!!). I had expected all the ISPs to have lept on this by now....

Yes there is. I have multiple UDP/RTP streams at different bitrates, from the same IP to the same IP.

I then get a loss on a 30mbit stream (3000 packets a second) of 150 packets. At the exact same time I get a loss on a 20mbit stream of 100 packets, and a 10mbit stream of 50 packets.

This is an outage for 150ms, probably because of a reroute in an MPLS network somewhere.

My packets have already been emmitted by the time any round trip resend would have come back.

Tcp needs packets to be dropped quickly to get the feedback that your link can't handle the speed. Without that, it will appear that the speed of the network is fluctuating (as the buffer fills it appears your network is faster than it is, when the buffer is full it will start dropping packets which causes tcp to back off which causes the buffer to drain, now if tcp starts sending data before the buffer is empty you'll get a different apparent speed to tcp) and it is that fluctuation which causes the issues.

Reply on news.ycombinator.com