Why is Comcast Using Self-driving Cars To Justify Abolishing Net Neutrality? (theverge.com)
Earlier this week, Comcast filed its comments in favor of the FCC's plan to eliminate the 2015 net neutrality rules. While much of the document was devoted to arguments we've heard before -- Comcast believes the current rules are anti-competitive and hurt investment, but generally supports the principles of net neutrality -- one statement stood out. The Verge adds: Buried in the 161-page document was this quirky assertion (emphasis ours): "At the same time, the Commission also should bear in mind that a more flexible approach to prioritization may be warranted and may be beneficial to the public... And paid prioritization may have other compelling applications in telemedicine. Likewise, for autonomous vehicles that may require instantaneous data transmission, black letter prohibitions on paid prioritization may actually stifle innovation instead of encouraging it. In other words, Comcast is arguing for paid prioritization and internet fast lanes to enable self-driving cars to communicate better with other vehicles and their surrounding environment, thus making them a safer and more efficient mode of transportation. The only problem is that autonomous and connected cars don't use wireless broadband to communicate. When cars talk with each other, they do it by exchanging data wirelessly over an unlicensed spectrum called the Dedicated Short Range Communications (DSRC) band, using technology similar to Wi-Fi. The FCC has set aside spectrum in the 5.9GHz band specifically for this purpose, and it is only meant to be used for vehicle-to-everything (V2X) applications. That includes vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-pedestrian (V2P) -- so cars talking to other cars, to traffic signals, to the phone in your pocket... you name it. Soon enough, all cars sold in the US will be required to include V2V technology for safety purposes, if the Department of Transportationâ(TM)s new rule goes into effect.
What else can they do when their position has no rational defense?
That doesn't need a high priority channel. High priority channels should be for emergencies. A self driving car should be able to handle emergencies without an internet connection, otherwise the technology isn't ready.
It's not like Comcast is well known for their truthfulness and transparency. To them, the best way to destroy NN is pile on "alternative truths" via PR like this. They know it's a sound idea on the technical side, so using a false pseduo-technical argument against it is the best way to confuse "the masses". We all know they started with some boiler-room with "destroy NN" on the whiteboard, and the marketing drones have a long list of potential knock-downs, focus groups, test campaigns, etc. Comcast knows full well that NN has nothing to do with V2V, but are just throwing everything to the anti-NN wall to see what sticks.
We all know that, especially with the current administration, "public comments" really have little affect. The real "voice" is the lobby money behind the scenes. This is just a "reason" for the FCC to overturn, so they won't seem to be too corrupt to "the public".
You're suggesting that we should allow for the possibility that vehicle safety will come to depend on a paid service from a cable company. And calling other people morons.
Interesting.
No, I got your point; you still seem to be missing mine, though.
If your traffic is only measured against your other traffic, your QoS headers have no effect on anyone else's traffic. Follow?
It's a simple implementation, actually; your ISP already splits its aggregate bandwidth into rate-limited streams (or buckets, if you prefer) based on the speed you pay for. They can just as easily apply QoS rules defined for each stream on an individual basis.
Hell, my consumer-grade router can do that. I can assign vnets a fixed amount of bandwidth and each vnet can have its own QoS rules; one vnet having rules that set every packet to high priority doesn't affect the other vnets (of course, it also doesn't benefit that vnet, either).
In other words, your QoS rules decide which of your packets get dropped or delayed if one or more of your packets need to be dropped or delayed; they don't, in this hypothetical (and easy to implement) scenario, determine whether your packets or someone else's get dropped or delayed. That latter determination would need to be made by the ISP's own traffic management system and a fair way to determine that is to determine what percentage of the aggregate bandwidth belongs to each user (e.g. we've sold 100Tb/sec and you pat for 100Mb/sec, you "own" 0.0001% of available bandwidth) and ensure that each user gets that percentage of whatever aggregate bandwidth is actually available during times of congestion.
Then, you can set all of your QoS rules to high priority all day long and your rules don't affect me in the slightest.
To put it another way, call me when you've implemented this and know what you're actually talking about. I have and I do or I wouldn't be repeating it.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.