[loup-vaillant]

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 server at home, with many advantages for choice, control, privacy… You could argue it's impractical for a lambda user (and it is), but that's not the problem. If someone try to sell a simple server with a fantastic UX that host e-mail, blog, vlog, social network, and distributed encrypted backup, all out of the box, it would still suck because of the damn bandwidth —and firewalls in some cases. So, this business model is dead in the water, which is why it is still so dammed difficult to install one's own mail server.

You want net neutrality? Start with a neutral bandwidth. Stop treating users like consumers, and they may stop acting like ones. With any luck, it should kill YouTube, Blogger, Facebook, Twitter, Gmail, Skype… except the users will still do what these "services" offer.

[Timmmmbob]

To be fair that was for technical reasons, and I think it will change soon with fibre. They tend to have sane upload speeds, e.g. 10 Mb/s.

[loup-vaillant]

In France, the cheapest fibre is Gb, symmetric. Yet they want to sell us 100Mb download, 10Mb upload. Also, many are reluctant to give us a decent IPv6: many give us a /128, instead of the recommended /48, or just the bare minimum /64. The technical reasons are long gone by now.

The whole debacle may have started for technical reasons, but I suspect now they're just addicted to centralization. Maybe tighter control of the end user leads to more money down the line?

[mindslight]

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.

[loup-vaillant]

No you don't disagree. Re-read my post.

I know the UX is terrible right now (as in so unusable I don't even dare touch the server I set up myself). I know centralized solutions work out of the box, while distributed solutions barely work at all.

Of course bandwidth wouldn't solve our problems overnight. But if our ISPs were suddenly giving us the bare minimum, meaning symmetric bandwidth and a fixed public /64 IPV6 with no firewall, then at long last, we'd have a business model for distributed stuff. It would get more people working on that UX problem, and that would solve the problem.

Eventually.

That said, I don't see how we can claim a decent internet connectivity in the first place, since there is no usage to justify it. Looks like a chicken & egg situation.

[mindslight]

Sorry for my lead in being needlessly confrontational. I do agree that asymmetric connections aren't a good thing, but disagree on the "chicken" versus "egg" as you put it. I don't think there will be any demand for greater upload bandwidth until using that bandwidth isn't an event that totally swamps your connection and requires manual coordination with other users.

Upload traffic is theoretically able to be precisely prioritized, where a long-term file upload uses any extra bandwidth but adds no latency to other traffic (besides unavoidable pktsize/linerate). But easy/standard configs provide best effort shaping even if you go out of the way so that it is able to discern interactive ssh from uploading ssh. (And nevermind download shaping, which really requires application-level involvement to get predictability).

Static IPs could help as a nice crutch, in that they would enable us to start with current server-authoritative protocols and patch/configure them to deal with one-nine uptime. But conditions here are set, and static IPs are not a panacea - I have the option for $6/mo, but don't take it. And I deal with the same fundamental undistributed service problems between my own machines on tinc.

So I don't see much point trying to lobby ISPs for larger upload (esp when it goes against their technical constraints. I do have to wonder how the world would be different if digital computers had been invented before radio, causing p2p to be dominant over broadcast), without the software to make it useful. And I think that software has to be developed with the current conditions and the understanding that most people don't want to have caring for a home server a prominent part of their lives.

(Now, maybe my tune would change if instead of 12M/1M DSL, I were on GigE where my upload throttling would be done by "the cloud" ;))

[loup-vaillant]

The way I see it, it's a package. The internet is supposed to be a network of peers. Keeping this property is important for a number of reasons, both technical and political.

To be a peer on the internet, you need to be able to be server as well as client. With current protocols, this means a public static IP (or range thereof), symmetric bandwidth, and no spurious restrictions. The network must also be "clean". No deep packet inspection, no transformation of payload, no NAT, no nothing. Just a dumb pipe, who treats packets equally —for some definition of "equal". And if you have difficulty handling a particular kind of data, then just install bigger pipes. Congestions should be few and far between.

Some people would go even further, arguing that you also need an Autonomous System number. I believe this is less important, though I tend to agree. People should be their own ISP if possible (hint: it's difficult). One way to do it is set up a non-profit, and be a member.

---

Now let's get more technical. The main reason why consumer upload should match consumer download is this:

  Worldwide upload = Worldwide Download
  (Modulo lost packets and multicast.)

> I don't think there will be any demand for greater upload bandwidth until using that bandwidth isn't an event that totally swamps your connection and requires manual coordination with other users.

Actually there's already a huge demand for upload right now: YouTube. Every time someone watches a video, Google must spend that much upload —without requiring the attention of the account owner. This makes the network unbalanced: lots and lots of data are pouring out of Google's network to the consumer networks, and little ever goes back.

This has economic repercussions. Basically, ISPs connect with each other in two ways. The first is Alice and Bob having a peering agreement: when Alice can send data to Bob, and Bob can send data to Alice, and no one charges for anything. Then you have transport ISPs, which charge for the data you send through them. That would be Eve charging Bob for transporting a packet he wants to send to Alice. (When Alice and Bob aren't directly connected.)

Normally, an ISP wouldn't charge for any data for which it is the recipient, because that's data it wants, after all. But that's not exactly the case of consumer ISPs, whose purpose is to transport the data to the consumers. So they charge the consumers themselves. Now here's the problem. If the bandwidth was evenly distributed, the ISP would send roughly as much data as it receives. Perfect for peering agreements. Instead, they keep receiving more and more data. So they're tempted to act like a transport ISP, and begin to charge for the data they receive. Except that won't fly, since their network is the destination of that data! Which is probably why they try the "middle ground" of merely slowing down data that isn't paid for, destroying any illusion of Net Neutrality in the process.

There is also a technical reason: a really peer to peer network would have the data travel shorter distances, instead of say, going back and for the capital even when two neighbours are talking to each other. That means less Tbm (TeraBytes multiplied by meters), which is ultimately cheaper.

---

> I have a static IP option for $6/mo

Your ISP is a crook. Static IP cost them nothing: most people are connected at all times anyway.

> So I don't see much point trying to lobby ISPs for larger upload (esp when it goes against their technical constraints. […])

It doesn't go against their technical constraints. If it ever does, it is because of constraints they put in place years ago with the advent of this infamously asymmetrical DSL. It's their fault, and the onus is on them to update.

---

Overall, try to step back from your own situation, and watch the big picture. This often yields different answers. (Example: if Joe Random wants more money, a way to get it is to become "more competitive". But if everyone gets more competitive, Joe Random will rank just as before.)

So, regarding the Chicken and egg problem… Sure, if you suddenly had a static IP and smoking fast upload, you may not behave any differently. But if everyone gets that, you may have a market, and it may change things. If anything, it would make overlay networks more practical, and goodness knows what innovation could come out of that.

[mindslight]

I'm coming from a similar place and think it very important to preserve the peer-oriented nature of the Internet, so you don't have to convince me. But I disagree on the prescription, because in the long term, economics wears down regulations (and here in the good ole USSA it's short-circuited right from the start!)

I don't see the way forward being based on IP addressing (+dns) as identity, which is ultimately what you're talking about. First, the end to end principle arose out of engineering concerns, and IP does nothing to preserve data opaqueness against a network that wishes to categorize traffic. And given that there is little money in transporting commodity bits, yet some of those bits are quite valuable (work VPN session..), there is an ever-present economic incentive for discrimination.

Referencing UL=DL doesn't really make sense. Even with an ideal buildout of multi-homed homes mesh-connected through each other, there's still going to be a network "core" that has more long-haul bandwidth than the outskirts. If I wish to publish a file to many people, it makes more sense to send that data once to the core, and fan out through there (whether by a server, multicast, or some new method).

My ISP is Sonic.net - I wouldn't call them crooks, and given the competition wouldn't begrudge them an administration fee on a static IP. I said that to point out that it is not even worth $6/mo to me, and combined with their deletion of logs after two weeks, having a fixed address is actually a net-negative from my perspective.

So back to the real topic.. I'm definitely trying to analyze the big picture, and I've come to the conclusion that IP-as-identity is a complete red herring. I don't particularly see how it would encourage overlay networks, when the whole idea of an overlay network is to deprecate the underlaying network protocol to layer something better on top. Overlay networks work just fine over dynamic IPs, and only need a few underlying long-lived identities for rendezvous.

The way I see it, the real root of the problem is protocols based on authoritative servers which place undue importance on the reliability of individual hosts, and therefore their network links and administrators. As long as we're reliant on these, then the benefits of locating them closer to the core and having them cared for by a third party is going to outweigh the downsides.

[at-fates-hands]

>>> But we already have such a slow lane. And it already made the internet less free and less useful.

I'm pretty sure you can still get ISDN lines from your local telecom provider. I know a long time ago there was talk of binding ISDN lines to together to increase upload and download speeds. This was right around the time DSL was blowing up so I'm sure it got lost in the wave of DSL hype.

Of course compared to DSL. GigaFiber, or any of the current technologies, it's downright pathetic.

[exelius]

Bonded ISDN lines are called a PRI (also known as a T1). A normal ISDN BRI consists of one D-channel and two B-channels. A T1 was one D-channel and 24 B-channels. You could also bond multiple T1s together; it was effectively a long-distance serial link that operated off the telephone network.

Technically you could also bond multiple BRIs together, but pretty quickly it made more sense to just provision a PRI with some of the B-channels disabled (also known as a fractional T1).

[nobleach]

I used to know this stuff back in my Net+ certification days.... like 15 years ago. Now I can't remember what BRI and PRI are - Basic Rate something?

[jlgaddis]

Basic/Primary Rate Interface