11 ms·

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 p

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.

mindslight 13y ago
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 13y ago
  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 13y ago
    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" ;))
at-fates-hands 13y ago
>>> 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 13y ago
  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 13y ago
    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 13y ago
      Basic/Primary Rate Interface
Timmmmbob 13y ago
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 13y ago
  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 13y ago

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 13y ago
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 13y ago
  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" ;))

at-fates-hands 13y ago

>>> 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 13y ago
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 13y ago
  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 13y ago
    Basic/Primary Rate Interface

Timmmmbob 13y ago

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 13y ago
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?