6 ms·

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 vid

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 you to the engineers and developers!

tyrust 6y ago
I'd believe it. When you know that there is going to be packet loss (whether from the user's spotty internet or from internal load-shedding), building your applications to be as resilient as possible to it makes sense. The infrastructure experimentation platform mentioned in the article is probably helpful for sniffing out potential trouble-spots in applications.
timhaak 6y ago
Slightly unrelated but does the packet loss happen all the time or when close to maximum of the line. Used to have similar problems with an ADSL line but found if I limited the line (Both up and down) I could find a magic number where the packet loss went away. (Well most of the time :)) Though it did need to be tuned for different times of they . ie high congestion times need it to be lower. Though technically it shouldn't be your problem :(
- baq 6y ago
  This is normal if your router doesn’t prioritize control traffic. A rate limit allows all the ACKs to normally leave your network instead of getting queued up.
  - WorldMaker 6y ago
    Or your router isn't responding correctly to traffic controls or the ISP isn't sending them correctly? I know with one provider I had in the deep past the allowable packet size was smaller than what most devices default to and they weren't correctly sending the maximum size their routers supported in the appropriate ICMP requests. Eventually I figured out that I could force my router to a smaller allowed packet size and that at least decreased packet loss substantially going upstream, even if whatever misconfiguration of the ISP was still confusing and eating downstream packets.
- bklyn11201 6y ago
  It happens nearly all the time. We use very little DSL bandwidth but are quite rural (miles from primary telephone infrastructure)
- fkskdkgif 6y ago
  Dropped packets are often a symptom that the MTU value is set too high. That would be uncorrelated to congestion, though.
madeofpalk 6y ago
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.
- seized 6y ago
  When Plex rolled out it's auto quality/auto bandwidth adjustment it actually worked very well over airplane satellite wifi as well. I watched a few things from my own server. I'm amazed that service allowed streaming though...
  - ketzo 6y ago
    For a good few years, a lot of airlines had Netflix and Hulu throttled on their free WiFi services, but not Twitch, so I’d just watch videogames on all my flights. My theory (which I really believe is true) is that they just hadn’t heard of it, and hadn’t blacklisted it!
- closeparen 6y ago
  Wow! You actually stream Netflix to an airplane? I always guessed that inflight VOD services had the movies stored in a server on the plane.
  - judge2020 6y ago
    Things like the Delta “gogo in-flight entertainment” do store their movies on the plane, but people will want to watch their Netflix/Prime/etc content on the plane as well.
  - madeofpalk 6y ago
    Both. There’s “inflight entertainment” where all the movies/shows are indeed stored locally on the plane, with either seatback or custom/white label streaming app for BYOD. But in addition they were advertising streaming Netflix and YouTube over the satellite WiFi.
crazygringo 6y ago
> 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?
- kevincox 6y ago
  If I had to guess they probably had timeouts that were too aggressive. Client timeouts are a very hard problem because it is difficult to tell the difference between "working, but slowly" and "something went wrong, the best bet is to try again". Back in the day we used to have timeouts based on individual reads/writes which will often better answer "is this HTTP request making progress". However the problem with these sort of timeouts is they don't compose well so most people end up having an end-to-end deadline.
- deleted 6y ago
  [deleted]
- ReactiveJelly 6y ago
  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.
ComputerGuru 6y ago
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).
- ikiris 6y ago
  ... no it doesn't. Like not even close.
- stingraycharles 6y ago
  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?
  - tyingq 6y ago
    "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/ https://blog.cloudflare.com/path-mtu-discovery-in-practice/
    - stingraycharles 6y ago
      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.
  - alaties 6y ago
    It's not unusual for a server to also be a router in a layer 3 link aggregation setup. It's extremely common for IPs to be load-shared amongst servers using ECMP. If each server is connected to 2 Top-of-rack (TOR) switches and advertises the route to the shared IP through both TORs, you can very easily have ICMP probes used for PMTU take the wrong route and be dropped. The result is a TCP session with a default MTU that may not work along all traversed paths and will suffer from fragmentation.
gameswithgo 6y ago
there has been the good kind of capitalism going on between the video streaming services before. earlier on I remember netflix was way better than amazon, but amazon upped their game since.
umbs 6y ago
How did you measure 4 to 6% packet loss? Do you have scripts to ping some server and you are collecting packet loss data? I would like to collect such data for my home network and am curious.
- lostmsu 6y ago
  Simple ping command actually prints statistics
- wtallis 6y ago
  Smokeping is one of the better-known tools for tracking latency and loss over time: https://oss.oetiker.ch/smokeping/ https://oss.oetiker.ch/smokeping/
epc 6y ago
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.

tyrust 6y ago

I'd believe it. When you know that there is going to be packet loss (whether from the user's spotty internet or from internal load-shedding), building your applications to be as resilient as possible to it makes sense. The infrastructure experimentation platform mentioned in the article is probably helpful for sniffing out potential trouble-spots in applications.

timhaak 6y ago

Slightly unrelated but does the packet loss happen all the time or when close to maximum of the line. Used to have similar problems with an ADSL line but found if I limited the line (Both up and down) I could find a magic number where the packet loss went away. (Well most of the time :)) Though it did need to be tuned for different times of they . ie high congestion times need it to be lower. Though technically it shouldn't be your problem :(

baq 6y ago
This is normal if your router doesn’t prioritize control traffic. A rate limit allows all the ACKs to normally leave your network instead of getting queued up.
- WorldMaker 6y ago
  Or your router isn't responding correctly to traffic controls or the ISP isn't sending them correctly? I know with one provider I had in the deep past the allowable packet size was smaller than what most devices default to and they weren't correctly sending the maximum size their routers supported in the appropriate ICMP requests. Eventually I figured out that I could force my router to a smaller allowed packet size and that at least decreased packet loss substantially going upstream, even if whatever misconfiguration of the ISP was still confusing and eating downstream packets.
bklyn11201 6y ago
It happens nearly all the time. We use very little DSL bandwidth but are quite rural (miles from primary telephone infrastructure)
fkskdkgif 6y ago
Dropped packets are often a symptom that the MTU value is set too high. That would be uncorrelated to congestion, though.

madeofpalk 6y ago

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.

seized 6y ago
When Plex rolled out it's auto quality/auto bandwidth adjustment it actually worked very well over airplane satellite wifi as well. I watched a few things from my own server. I'm amazed that service allowed streaming though...
- ketzo 6y ago
  For a good few years, a lot of airlines had Netflix and Hulu throttled on their free WiFi services, but not Twitch, so I’d just watch videogames on all my flights. My theory (which I really believe is true) is that they just hadn’t heard of it, and hadn’t blacklisted it!
closeparen 6y ago
Wow! You actually stream Netflix to an airplane? I always guessed that inflight VOD services had the movies stored in a server on the plane.
- judge2020 6y ago
  Things like the Delta “gogo in-flight entertainment” do store their movies on the plane, but people will want to watch their Netflix/Prime/etc content on the plane as well.
- madeofpalk 6y ago
  Both. There’s “inflight entertainment” where all the movies/shows are indeed stored locally on the plane, with either seatback or custom/white label streaming app for BYOD. But in addition they were advertising streaming Netflix and YouTube over the satellite WiFi.

crazygringo 6y ago

> 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?

kevincox 6y ago
If I had to guess they probably had timeouts that were too aggressive. Client timeouts are a very hard problem because it is difficult to tell the difference between "working, but slowly" and "something went wrong, the best bet is to try again". Back in the day we used to have timeouts based on individual reads/writes which will often better answer "is this HTTP request making progress". However the problem with these sort of timeouts is they don't compose well so most people end up having an end-to-end deadline.
deleted 6y ago
[deleted]
ReactiveJelly 6y ago
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.

ComputerGuru 6y ago

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).

ikiris 6y ago
... no it doesn't. Like not even close.
stingraycharles 6y ago
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?
- tyingq 6y ago
  "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/ https://blog.cloudflare.com/path-mtu-discovery-in-practice/
  - stingraycharles 6y ago
    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.
- alaties 6y ago
  It's not unusual for a server to also be a router in a layer 3 link aggregation setup. It's extremely common for IPs to be load-shared amongst servers using ECMP. If each server is connected to 2 Top-of-rack (TOR) switches and advertises the route to the shared IP through both TORs, you can very easily have ICMP probes used for PMTU take the wrong route and be dropped. The result is a TCP session with a default MTU that may not work along all traversed paths and will suffer from fragmentation.

gameswithgo 6y ago

there has been the good kind of capitalism going on between the video streaming services before. earlier on I remember netflix was way better than amazon, but amazon upped their game since.

umbs 6y ago

How did you measure 4 to 6% packet loss? Do you have scripts to ping some server and you are collecting packet loss data? I would like to collect such data for my home network and am curious.

lostmsu 6y ago
Simple ping command actually prints statistics
wtallis 6y ago
Smokeping is one of the better-known tools for tracking latency and loss over time: https://oss.oetiker.ch/smokeping/ https://oss.oetiker.ch/smokeping/

epc 6y ago

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.