>But it’s OK to discriminate across different types, so you could prioritize voice over video
Sounds like selling Internet priority to me. In fact, if you can prioritize voice over video you can likewise prioritize http over bittorrent, smtp, or xmpp. And if a competitor's video is going over xmpp while yours is going over FaceTime, that sounds like it's legit depending on how you define 'data type.'
You're arguing that they consider video types different when you have no idea what their talks entail - it may be so general as video, voice, web, mail, and other. Schmidt's comments were ambiguous to protocol and yet you're adding xmpp, smtp, FaceTime, and bittorrent. What NYT was suggesting was that Google be given priority over Bing, for example - grossly different from this situation. QoS is already in place for most major large corporations (and small!), but most ISPs have not gone down the avenue of implementing quality of service for their networks.
Here's the headline on NYT's site: Google and Verizon Near Deal on Web Pay Tiers
And a quote from the article: "...allow Verizon to speed some online content to Internet users more quickly if the content’s creators are willing to pay for the privilege."
The way I see it, there are only two possible ways to implement that kind of speed throttling:
1. Protocol filtering. This is basically the status quo with wireless. Voice/Text is separate from Internet data.
2. Deep-packet inspection. I'm sure that Schmidt wasn't advocating this, for a variety of moral and practical reasons.
How exactly do you do what Schmidt is describing without favoring a protocol? How do you favor a protocol without locking out third-party protocols? ISPs have no way of classifying the data sent on a third party protocol.
You are prescribing to one protocol versus another though. Whereas Schmidt is saying ALL video protocols be treated one way and ALL voip protocols be treated another way. For example, RTMP+MMS+RTSP+others may be considered "video," whereas SMTP+SMTP SSL+POP3 SSL+IMAP+IMAP SSL+others would be "mail," H.323+SIP+others will be "voice," and HTTP+HTTPS+FTP+FTPS+SFTP would be treated as "web." That is very different than pitting MMS against RTSP and saying MMS wins because Microsoft pays more.
From a legal standpoint that makes sense, but from a technical standpoint I just tunnel whatever I want over $SECURE_PROTOCOL and at that point all they've done is specified data latency/speed tiers.
Unless they're specifically looking at discriminating based on protocol, I don't see why they just don't talk about realtime vs. streaming vs. download data priority tiers, which seems a lot simpler from an implementation standpoint, and a lot easier to stomach from a net neutrality standpoint. Maybe that's all they're talking about. But the way it's phrased it sounds very dependent on protocol, which I would say is very non-neutral, because it's only possible to implement if you have a whitelist of protocols, and it's pretty much impossible for the established players to fairly arbitrate which protocols are which. What is streaming video over http? https? What if I've got a VOIP app running over https? Web-based email? Pigeonholing a protocol into a data priority tier just doesn't make sense.
Unless you're deliberately trying to lock out innovative protocols.
Sounds like selling Internet priority to me. In fact, if you can prioritize voice over video you can likewise prioritize http over bittorrent, smtp, or xmpp. And if a competitor's video is going over xmpp while yours is going over FaceTime, that sounds like it's legit depending on how you define 'data type.'