Dear Internet: Let’s Demo The Slow Lane • Hacker News Board

Re: Dear Internet: Let’s Demo The Slow Lane

#151

Post by mindslight » Wed, May 07, 2014, 6:54 PM UTC

loup-vaillant wrote: post #113

But we already have such a slow lane. And it already made the internet less free and less useful. It's the upload bandwidth. Weak upload effectively killed peer to peer. File sharing is slower than it could be, and e-mail, chat, blogs… are all in the "Cloud". Very convenient, but also dangerous (insert random EFF or FSF argument here —they all apply). With a worthy upload bandwidth, all these things could use a serve…

I wholeheartedly disagree - more upload bandwidth would be nice, but it would only lessen my inconveniences, not actually solve them. The real problem is bad UX/software, fueled by underlying protocols that assume relatively stable and authoritative server hosts.

I used to run email/dns/web/etc off of Speakeasy (and college before that, and dialup before that), but I switched to Linode (like 8 years ago) and haven't looked back. It really sucks when your home server has a hardware issue/power outage/changing things around/etc, and you feel like you need to fix it ASAFP lest your emails/etc start getting bounced/etc (yes, smtp is supposed to queue. no, that doesn't alleviate the concern).

What I really want is my home server to act as the primary contact, but when that is down, Linode to serve on my behalf seamlessly, obvious to message contents. And of course I could set something like that up per-protocol (modulo incoming ports being firewalled, etc), but the more complex setup one makes for themselves, the more likely things are to just decay over time.

We're not even at the point where having a distributed file store is straightforward. The best I've found is running Unison across multiple hosts/disks, and I still find myself spending way too much time dealing with administration and overcoming its limitations (cycle-intolerant topology, lack of access levels, etc). Anything else I've seen assumes a reliable central host, constant network connection, would need to be babied in different ways, or is just not robust enough to trust.

Meanwhile with these centralized solutions, they just work out of the box. There are occasional or hidden issues like service outages, vendor dependence, lack of flexibility due to arbitrary restrictions, planned obsolescence, anti-features like ads, abdicating your computing to opaque code you don't control, supporting the destruction of the Internet (what prompted this slew of articles? Netflix setting a terrible precedent..), etc. But the effort required to initially get them working is basically nonexistent. I personally refuse to give in and support (hopefully) dead-end centralized technology. But you can't deny that their user experience is quite compelling, especially for people without preexisting sysadmin skills.

Re: Dear Internet: Let’s Demo The Slow Lane

#152

Post by zo1 » Wed, May 07, 2014, 6:56 PM UTC

marcosdumay wrote: post #73

err4nt wrote: post #30

Earlier quoted context omitted.

I don't know how to say it without being blunt, but I mean no offense, I'm just curious. I've heard of this mythical type of user (no-JS) but never heard their side of the coin before. I dislike ad tracking, information culling, and I think that JavaScript underpins and makes possible many of the things I dislike about the modern web. We agree on that I'm sure. But so does a web browser. So does the operating system…

Once in a while Firefox has a bug, and I have to reset its data in one environment. Almost without exception, I forget to install NoScript after that, and experiment the "fully functional" web. That experience is so disastrous that I always put NoScript back, and make notes to not forget it again (that I obviously do not follow next time). The web with Javascript enabled is simply broken. Sites take ages to load, ref…

"[..]throw overlays all around the screen" They've adapted. I've seen sites in the wild that do the opposite. Use CSS to hide all the content, and then use JS to enable proper viewing.

Re: Dear Internet: Let’s Demo The Slow Lane

#153

Post by mhandley » Wed, May 07, 2014, 6:59 PM UTC

wmf wrote: post #105

exelius wrote: post #103

Earlier quoted context omitted.

Packets get dropped when links are saturated as they often are during peak hours. I know a network admin would think "well the links should never be saturated" but the economics of that just don't work in the consumer ISP space. You aim for a target level of service that means certain portions of the network will be saturated, and use QoS to ensure things like DNS and HTTP remain responsive. Regardless, the point is…

the economics of that just don't work in the consumer ISP space A citation is needed here. Somehow consumer ISPs got along for 15 years without "permanent congestion".

Well, the goal of a properly designed transport protocol is to transfer X bytes in 0 seconds. TCP doesn't quite achieve that, but that is its goal. This pretty much dictates †hat for any reasonable sized download, somewhere on the path is congested. If that congestion isn't at the server (it usually isn't), and isn't in the backbone (it usually isn't), then it's either your consumer ISP or your computer (it usually isn't). ISP's tend to oversubscribe backhaul to make the economics work, so if you're not getting your full linkspeed, then it's likely the backhaul that's congested, and everyone else is seeing congestion too.

There are exceptions of course. Older OSes have ridiculously small TCP receive windows, and older TCP congestion control algorithms have trouble filling the pipe. But these shouldn't really be the main problem these days. It doesn't apply so much for streaming either, because modern streaming protocols such as MPEG-DASH will select a lower bitrate stream if they sense congestion.

Re: Dear Internet: Let’s Demo The Slow Lane

#154

Post by lvs » Wed, May 07, 2014, 7:02 PM UTC

ihsw wrote: post #27

Why stop at the slow lane? There is nothing preventing ISP gatekeepers from wholeheartedly denying access. Slowness is just the beginning -- the end-goal is making the internet into multiple competing walled gardens where users are treated as silos that require permission to access. The global reach of the internet is at risk here. Imagine if Netflix wasn't accessible to Comcast users from the beginning because they…

It's a retrograde step back to the days of AOL and CompuServe, when access to off-network services was a premium feature.

Re: Dear Internet: Let’s Demo The Slow Lane

#155

Post by keithpeter » Wed, May 07, 2014, 7:07 PM UTC

"Algorithmically, all sites could slow themselves down dramatically, demonstrating what performance might look like over a 1/1 pipe. Or even a 0.5/0.5 pipe."

If the former, it would make precisely no difference to me. Openreach (UK) provide adsl over copper via an older phone exchange in my immediate area. This is one mile from the centre of a major city. The local authority actually took Openreach to court and lost.

To put this into perspective the government is about to spend around UKP60 Billions over 20 years to provide a high speed train link to London so the journey time drops from 1h30 to 45 min...

Re: Dear Internet: Let’s Demo The Slow Lane

#156

Post by AnthonyMouse » Wed, May 07, 2014, 7:16 PM UTC

JoeAltmaier wrote: post #81

hamai wrote: post #79

Earlier quoted context omitted.

Wouldn't prioritizing packets at routers create slower queues for low priority packets? Murphy's Law tells me there's a good chance these low priority queues will slow down exponentially at random times. Routing nightmare if you consider DDoS and what not.

Not that simple. Queues can manage the latency of packets, not just by priority but by time-stamping packets and sorting them. Priority is a sucky way to do anything - queues, threads, even email. What we usually want is control over latency.

Latency isn't really the problem. Latency has three causes in practice: The speed of light, router packet buffers, and (generally congestion-related) packet loss. The first isn't usually a problem and there is nothing to be done about it anyway. The second and third aren't actually latency issues at all, they're latency as a side effect of a bandwidth shortfall. The only way to actually fix that is to add more bandwidth. The best you can do otherwise is to choose who gets screwed over by the lack of bandwidth, which is exactly the thing you don't want the likes of Comcast doing.

Re: Dear Internet: Let’s Demo The Slow Lane

#157

Post by lutorm » Wed, May 07, 2014, 7:45 PM UTC

jonlucc wrote: post #62

shubb wrote: post #36

Can anyone think of any advantages to a non-neutral internet? I can think of a few - Netflix and Skype would work better. Most likely, we'd be able to pay for priority traffic, just like we pay for a large AWS instance. Non-priority traffic might be cheaper than current bandwidth. It would be crazy to suggest all sites be forced to use the same size AWS instance... Some types of traffic are bandwidth sensitive, like…

The problem is that most places don't have choices. I have only one option (ATT) for ISP and when I move in a couple months, I will have 2 choices (Comcast and ATT).

I feel so much better about my situation now: I have 3 choices: TWC, dialup, and some guys providing microwave links for $100/month. ;-)

Re: Dear Internet: Let’s Demo The Slow Lane

#158

Post by rubbingalcohol » Wed, May 07, 2014, 8:04 PM UTC

I am working with Fight for the Future on a JavaScript code snippet (called 'Slow Lane') to simulate a slow loading process + rip the FCC a new one. This project needs to launch next week to make the maximum impact and we need help to make it superb! If anyone with web skills is interested in helping out, please email team@fightforthefuture.org or me directly at jeff@rubbingalcoholic.com ...

Re: Dear Internet: Let’s Demo The Slow Lane

#159

Post by orthecreedence » Wed, May 07, 2014, 8:18 PM UTC

exelius wrote: post #136

devcpp wrote: post #122

Earlier quoted context omitted.

>Companies like Comcast have no interest in slowing down web site traffic Yeah? How about money? As a comms engineer, I too think about the technical implications of this. But you have to remember that the people who push for the abolition of net neutrality are mainly the finances guys, i.e the ones responsible for bringing as much money as possible to the company. And when you put yourself in their shoes, all of a s…

Well, in short, any web site with any money to pay the ISPs is likely already running on a CDN that's been paying the ISPs for a decade. The portion of that market that's not yet monetized is likely very small. Besides, slowing down general-purpose web traffic makes it look like your service just totally sucks ass. But more generally, slow-loading websites make the ISP's service look shitty. There's almost no cost fo…

> But more generally, slow-loading websites make the ISP's service look shitty

Exactly, so people will just leave that ISP and sign up with one that doesn't throttle traffic. Except most people have only one ISP in their area. Yay free market!

Re: Dear Internet: Let’s Demo The Slow Lane

#160

Post by JoeAltmaier » Wed, May 07, 2014, 8:19 PM UTC

AnthonyMouse wrote: post #156

JoeAltmaier wrote: post #81

Earlier quoted context omitted.

Not that simple. Queues can manage the latency of packets, not just by priority but by time-stamping packets and sorting them. Priority is a sucky way to do anything - queues, threads, even email. What we usually want is control over latency.

Latency isn't really the problem. Latency has three causes in practice: The speed of light, router packet buffers, and (generally congestion-related) packet loss. The first isn't usually a problem and there is nothing to be done about it anyway. The second and third aren't actually latency issues at all, they're latency as a side effect of a bandwidth shortfall. The only way to actually fix that is to add more bandwi…

Latency is the issue in routers when they categorize traffic, that was the idea. They don't simply prioritize packets; they age them and sort to try and ensure latency constraints. So its more complicated than priority.