Live data from Hacker News

Keeping Netflix Reliable Using Prioritized Load Shedding

netflixtechblog.com

71–77 of 77 posts

Re: Keeping Netflix Reliable Using Prioritized Load Shedding

#71

Totally anecdotal evidence, but I was in a rural NY house served by DSL for the past 6 months. The DSL has consistent packet loss between 4 and 6%. The only video service that could handle this level of packet loss well was Amazon Prime. Netflix couldn't even load its browse screen until the past two weeks, where something changed, and suddenly Netflix could handle the high packet loss as well as Amazon Prime. Thank…

> Netflix couldn't even load its browse screen until the past two weeks I assume the browse screen is based entirely on TCP? I'm struggling to understand why packet loss would prevent it from loading -- it should be slower but TCP should handle re-transmission, no? Or is Netflix doing something tricky with UDP even in their browsing UX?

I doubt Netflix is doing anything tricky with UDP anywhere in their stack.

QUIC doesn't count because it's not tricky.

I'd love to see a source for this but seeing as YouTube works great over regular HTTP and TCP, I doubt anyone else is out in the weeds trying some custom UDP solution and reinventing wheels.

Re: Keeping Netflix Reliable Using Prioritized Load Shedding

#73
post #47

Earlier quoted context omitted.

Aren’t MTU issues typically only up to a router? As in, even if the parent had a different MTU than Netflix uses, it wouldn’t matter since their router or the ISP’s router will transform packets between their appropriate MTUs? And if this is true, then how could it be that Amazon works without problem and Netflix doesn’t?

"how could it be that Amazon works without problem and Netflix doesn’t" Supporting Path MTU discovery (PMTUD), or perhaps just capping their outbound packets to 1450 or similar. Cloudflare found and fixed a problem in this space: https://blog.cloudflare.com/path-mtu-discovery-in-practice/

Oh wow, TIL about the “don’t fragment” bit and all the stuff that comes with it.

Thanks for sharing, I learned a lot from that blog post.

Re: Keeping Netflix Reliable Using Prioritized Load Shedding

#74

Totally anecdotal evidence, but I was in a rural NY house served by DSL for the past 6 months. The DSL has consistent packet loss between 4 and 6%. The only video service that could handle this level of packet loss well was Amazon Prime. Netflix couldn't even load its browse screen until the past two weeks, where something changed, and suddenly Netflix could handle the high packet loss as well as Amazon Prime. Thank…

Seperate annecdote - I worked on an inflight satelite wifi project and I was surprised at how well both Youtube and Netlifx worked over a medium-bandwidth/high-latency connection. Granted, we had specific QoS/traffic shaping to improve reliability without gobbling up all the bandwidth (stream Netflix was an advertised feature of the wifi service), but it still seemed like magic.

YouTube has gotten way better in the past couple of years. When they first launched DASH streaming, it was terrible on high-latency international connections. If a US-based content creator uploaded a video and you were the first to view it in your region, you could actually notice how it was populating the CDN and it was unwatchable without disabling DASH and using the old-fashioned buffered player. These days it's flawless for me in nearly every situation.

Re: Keeping Netflix Reliable Using Prioritized Load Shedding

#75

Totally anecdotal evidence, but I was in a rural NY house served by DSL for the past 6 months. The DSL has consistent packet loss between 4 and 6%. The only video service that could handle this level of packet loss well was Amazon Prime. Netflix couldn't even load its browse screen until the past two weeks, where something changed, and suddenly Netflix could handle the high packet loss as well as Amazon Prime. Thank…

Any chance there weren't any line filters on the POTS equipment? I haven't had DSL in years but when I did I had to have filters on any telephone devices connected to the same line.

Re: Keeping Netflix Reliable Using Prioritized Load Shedding

#76

Earlier quoted context omitted.

This sounds like an MTU issue. TCP takes care of mere (eg probabilistic) packet loss ok. MTU issues have actually crept back up because TLS exacerbates any underlying MTU problems. IPv6 doubly so (when any hops - especially yours - don’t follow path MTU detection requirements).

TCP doesn't take care of packet loss. What TCP does is make sure your packets are not lost, even if you have 99% packet loss. On the flip-side, that means that if TCP can't deliver a single packet (say out of a billion), the whole stream stops at this one packet... Which is why TCP is a horrible choice for any streaming service and a horrible choice for lossy connections, and I would be quite surprised if Netflix rel…

You'd only allow packet loss without re-transmission (e.g. pure UDP) if you really need low latency, like for a video call.

Netflix is pure TCP I'm sure - look up HLS and DASH.

Re: Keeping Netflix Reliable Using Prioritized Load Shedding

#77
post #59

great, now shitty connections can also watch cuties, the pedo movie

Someone please stop these spammy people that post once and then change account to a brand new one, over and over again.

If that were easy, we’d have solved email/comment/Twitter/Reddit spam and trolling back in the 1990s.

Anyone who has run a service that allows user content of any type knows that the miscreants are endlessly creative and you can expend infinite resources but some will slip through.

I still see the daily spam and phishing email in my Gmail, despite the tens/hundreds of millions Google has invested in filtering.

Post reply on HN