Forums | MacLife

resedit wrote:

Speaking of paranoia what specifically about these bills before congress is bad?  Specifics not paranoia

I gave specifics.
According to the bills, if example.net wants to use bt as their content distribution distribution model, then ISP's may not throttle bt unless they are able to maintain a white list of trackers, which is not realistic.

There already are businesses that use bt as a distribution model. Many of those businesses (IE CentOS, Red Hat, Ubuntu) also make their content available via http and/or ftp - but net neutrality bills do not make that a necessity, and some do not (when they really should).

Thus even though the claim is that NN laws will still allow bandwidth throttling for P2P - the reality is that they can't, because those who write the laws don't understand the tech and how it is used.

With the exception of "on demand" streaming, the burden should be on content distributors to make their content available by standard http or ftp (hence my solution of specified ports that are neutral) but the way the bills are written, that's not the case, they put the burden on the ISP to have to know the content is not legitimate legal traffic before they can use a bandwidth shaping tech.

Most ISP's currently do not allow servers as part of their agreement, and by that policy, they can outright block P2P if they wanted to.
But with P2P as a content distribution model they can't even do that under NN.

There's a good reason for them to block servers. Remember Code Red?
That largely spread as fast and furiously as it did, bringing down entire networks all over the place, because of SQL servers running on consumer broadband. MS had patched it ages before the worm but a large number of idiot home users who didn't even know they had it installed had unpatched installs and the result was routers crashing right and left.

Specify ports for standard web/email as neutral, specify a range of ports for on demand services where P2P can still be blocked, specify a range of ports for VOIP where anything not VOIP can be blocked, and let the ISP's manage all the other traffic however they see fit.

This is the kind of thinking that brought us mandatory sex offender registries. There are simpler ways to deal with the problem - you deal with the people who actually offend.

If an ISP sees a group of users using an obscene amount of bandwidth, regardless of the application, you deal with those users. You don't punish everyone on the network. Besides, this is just the red herring the ISP's are trotting out.

What they really want to do is turn their networks into walled gardens, AOL-style - but they can't quite get away with it yet. Believe me, though; they want you to only use their services, and no one elses. The fact that those "elses" have access to "their" customers pisses them off mightily. That is closer to what this is all about.

Ultimately, allowing ISP's to choose what services you may access, and at what quality of access, is harmful to the whole network.

Some1 wrote:

JakeTheTall wrote:

RatFink wrote:

Limiting to ports would be a best useless and at worse damaging to the internet as developers write apps out of spec using those ports so their content should be treated neutrally.

This too.  There's a significant number of existing applications that are not browsers and not serving HTML and they tunnel through port 80.

Ex: My newsprovider sends binaries SSL over port 443.

Here's how it works in Canada, ISPs provide okay speeds at high prices with extremely low bandwidth caps. I calculated that if I were to download at full speed for 8 hours I would hit my cap. At which point I can get surcharged $50 for about 7GB. Or I just shell out an extra $12.50 a month for an extra 30GB.

Now the ideal throttling system shoud be entirely non-biased. If a person reaches their monthly data-cap then they should have their connection throttled, they shouldn't be charged ridiculous  fees, and this way the network remains neutral, and isn't clogged by heavy data-users.

How ISP's charge their own customers for access to the network isn't really an issue. The industry standard is "unlimited" where unlimited is defined differently by everyone. This is a lousy way to do business, but it has nothing to do with net neutrality.

Frankly, I have no problem with ISP's offering staggered pricing plans that charge heavy users more than light users. I don't even really have a problem if such a plan were arranged such that it only kicked in when you used more than your allotment - in fact,  I think that would be the most customer friendly way of doing it. If you only check email in March, you pay less than when you download DVD ISO's in April.

I'm worried about ISP's blocking or charging other entities on the Internet who are NOT their customers for access to their subscribers, creating a situation that protects their own interests to the detriment of an open Internet - and in the process, creating a system that could easily be abused.

Some1 wrote:

The ISPs' rational for packet control is that it would be impossible to provide stable service to everyone if too many people used P2P.

This would solve the problem and maintain a neutral net.

There is already a solution to that problem, and it doesn't require all the bull crap they want. It's called warn, then disconnect, users who abuse the network.

Not to mention this kind of crap:

Turns out that the DROID does support multitouch after all -- it's just not as baked as the MILESTONE's, and it's certainly not the kind you'll see out of the box. The DROID's European cousin features multitouch right in the phone's core software load (most notably pinch-and-zoom in the browser, which we've seen demoed on video) whereas the DROID itself still features multitouch capability in APIs but doesn't expose it through any built-in app. Translation: the apps you use every day -- Google Maps and the browser, chiefly -- get left out in the cold for some reason that neither Google nor Motorola (nor Verizon) have thus far been willing to adequately justify.

Footnotes are oh so important in these sorts of documents.

113 See, e.g., Madison River Order, 20 FCC Rcd 4295; Comcast Network Management Practices Order, 23 FCC Rcd 13028; Marcel Dischinger et al., Detecting BitTorrent Blocking (2008) (Dischinger, Detecting BitTorrent Blocking), .