The Internet is Broken, and How to Fix It | Hacker News Reader

The Internet is Broken, and How to Fix It

gettys.wordpress.com

42 pointswmf8 comments

Why use TCP? Video conferencing, VOIP, and other low-latency applications typically don't need guaranteed delivery. With the right error-correction, some packets can be dropped without issue, and an occasional cut-out is more acceptable than constant low throughput. UDP makes a lot more sense in those cases.

UDP has issues of course. Breaking through NAT is tricky, and you have a smaller selection of libraries and tools. Still, that trade-off seems a lot better than trying to get everyone to change their congestion algorithms and adopt new standards.

UDP fills the same (overlarge) buffers before it can be sent over a link; it can be stalled by misbehaving TCP. Since TCP still dominates bandwidth usage, TCP bufferbloat needs to be fixed for UDP to have a chance at low latency.

Also, if a UDP application can possibly use a significant share of the bottleneck bandwidth, it will need its own latency feedback to avoid being another cause of bufferbloat. Whatever fills the buffer has no bearing on the outcome in most cases (most buffers are just for ethernet retransmission and routers don't manage them; the exceptions I know are with AQM and QoS).

He's already assuming that latency-sensitive apps are using UDP (which they are); the problem is that apps that are (properly or improperly) using TCP can easily kill UDP. For example, a single TCP connection can near-instantly queue up 10 packets (15KB), creating >100 ms of latency for any UDP traffic.

esr is working on a small gps timing device to test bloat:

Announcement: http://esr.ibiblio.org/?p=4171

Update: http://esr.ibiblio.org/?p=4335

Mailing List: https://lists.bufferbloat.net/listinfo/thumbgps-devel

I've read about his GPS adventures before, but I didn't know what it was for. Is this to be able to inject packets with precisely known start times for measuring latency across the network?

He is also the maintainer of gpsd so some of the gps material might have been for the gpsd project in general.

From what I understand the GPS device is just used for getting accurate time stamps (via gpsd not ntp reference implementation). It is odd because no self respecting time-nut[1] would use PPS over usb, too much jitter. But the meat of the project will be the system for measuring latency so its not vital that the measuring nodes have microsecond offset agreement.

[1] http://www.leapsecond.com/time-nuts.htm

Opened the link to see what they thought was broken with some webapages and webdevelopers (i.e. NOT the Internet) and was pleasently surprised with a well thought discussion of the underlying technologies.

Haven't read the post, but I assume it just says "unplug it, then plug it back in".

Reply on news.ycombinator.com