

Eric Schmidt on the Verizon Deal (et al) - moultano
http://gigaom.com/2010/08/05/google-ceo-dishes-on-google-wave-verizon-social-strategy/

======
moultano
_We have been talking to Verizon for a long time about trying to get an
agreement on the definition of what net neutrality is. We’re trying to find
solutions that bridge between the hardcore net neutrality view and the telecom
view. I want to be clear what we mean by net neutrality. What we mean is if
you have one data type like video, you don’t discriminate against one person’s
video in favor of another. But it’s OK to discriminate across different types,
so you could prioritize voice over video, and there is general agreement with
Verizon and Google on that issue. The issues of wireless vs. wireline get very
messy because of the issue of Type I vs Type II regulation and that is an FCC
issue not a Google issue._

~~~
roc
> _"What we mean is if you have one data type like video, you don’t
> discriminate against one person’s video in favor of another. But it’s OK to
> discriminate across different types, so you could prioritize voice over
> video"_

Which sounds good, but completely falls apart upon examination.

E.g. Is a video-call _video_? or voice? Is it a new type altogether? What if a
new videochat service uses a new protocol with different
encryption/compression/etc? Is that a distinct "type" with distinct
'management' profile?

Given the largely arbitrary distinction of bits into "types" of communication,
being able to decide what is or is not a discrete "type" and priority
essentially gives the power to decide whether a new service sinks or swims.

And, as many new service types are effective competitors against old service
types, getting to decide whether the new type is discriminated against is
functionally equivalent to deciding whether to discriminate against arbitrary
competitors _within_ a service type.

The only improvement of discriminating by type over discriminating by source,
is that you can still have competition among those who use an entrenched
protocol -- to the extent that competitors are free to use said protocol.

Because --to be perfectly clear-- there's absolutely nothing stopping that
sort of "compromise" being followed by a patented, proprietary google/verizon
video chat protocol that they will not license, while they simultaneously
throttle FaceTime/Fring/etc.

EDIT: (some punctuation/grammar)

~~~
jonknee
We're quickly going to be in a world where all phone calls are VoIP and I
don't think it's unreasonable to allow QoS tiers. I don't want to have my
phone not work because my neighbors are torrenting. Hell, I already do this on
my home network. Google just wants to make sure you don't have to pay to get
in a QoS tier.

~~~
roc
Again: that sounds good, until you think it through.

What happens when an upstart wants to compete with Verizon on VoIP? Say they
roll out an innovative new protocol that offers far better quality in a still-
reasonable footprint. Or offers some sideband feature that existing VoIP
doesn't. (say, streaming file transfer, letting you send data bits during a
call while on the call directly to the person you're talking to. no need to
open a mail client or sftp and negotiate a second connection)

Why wouldn't Verizon decide that this new competitor is a new flavor of VoIP
that needs to be in its own QoS tier? It will have a different traffic
profile, so you can't very well argue that they shouldn't be able to
"optimize" it separately on technical grounds.

But now it's a new "type" and Verizon is free to kick it into the QoS round-
file tier to either blackmail payment or simply hamstring adoption.

Maybe they only do that until they catch up and offer similar features. Or
maybe they launch their own next-gen VoIP protocol in _yet-another_ QoS tier,
where the upstart is still not allowed.

Once you open the door to QoS by type --and leave type classification in the
hands of the ISPs who directly profit from how these largely arbitrary lines
are drawn-- there's a vanishingly small difference between QoS by type and by
source.

~~~
haberman
Your example doesn't make any sense. For purely technical reasons there would
be no reason to send a VoIP call along with the "sideband feature" over the
same connection.

Even if your VoIP application offers a feature like streaming file transfer,
you wouldn't actually implement that by sending that data over the VoIP
connection, because the VoIP data requires real-time performance (the call
starts breaking up if packets are delayed) but your streaming file transfer
does not. It would be silly to let your multi-gigabyte file transfer DoS your
VoIP call.

If you simply opened a second, non-VoIP connection for the file transfer,
everything would work fine.

Would Verizon have an incentive to cheat by favoring its own services? Maybe,
but that seems to be what these Google talks are all about in the first place.
I think Google is aware that any agreement would need more teeth than trusting
the goodness of Verizon's heart to comply.

~~~
roc
> _"It would be silly to let your multi-gigabyte file transfer DoS your VoIP
> call."_

1\. _I_ think it would be silly to assume a reasonable person would propose
sending _multi-gigabyte files_ down a VoIP connection. You might want to
consider _asking_ people if there was a miscommunication before _assuming_
they're unreasonable or ignorant.

2\. I thought the qualifier that it would remove the need to _open a second
app_ was sufficient to indicate that I was talking about _opening a second
app_. Ergo "connection" meant the human-process of mapping a VoIP contact to a
data-transfer app/credentials, opening second app, sending file, etc.

3\. No, a second physical connection for the file stream doesn't necessarily
mean "everything would work fine". Anything that requires a new
protocol/extension would make classification of the product/feature/service
game to be, well, _gamed_ , by the ISP, for profit.

As the VoIP connection itself would need to _at least_ be modified to
signal/establish the physical data connection, you'd necessarily have a
protocol variant - even if the file transfer itself was, say, ftp.

4\. The whole point of the example is just "New product that extends old
protocol, thereby giving ISP chance to QoS-round-file new product rather than
compete". Focusing on the example itself is just wasting our time.

> _"I think Google is aware that any agreement would need more teeth than
> trusting the goodness of Verizon's heart to comply."_ I think Google is
> doing nothing more than hedging against the possibility that legislation
> will undercut the FCC's net neutrality kick; particularly given legislative
> power being likely to tip back to the strongly pro-corporate side.

I sincerely doubt they're negotiating with Verizon over treatment of any
traffic that does not come from Google.

~~~
haberman
> You might want to consider asking people if there was a miscommunication
> before assuming they're unreasonable or ignorant.

Your entire argument is based on the assumption that Google is being
unreasonable or ignorant. You're posing completely trivial scenarios of
Verizon gaming the system, and assuming that Google is negotiating an
agreement that is vulnerable to such trivial gaming.

Furthermore, your only evidence whatsoever about these non-public negotiations
is an extremely vague and misleading NYT article, and a paragraph blurb from
Eric Schmidt. You know next to nothing about these negotiations (as do I), but
you're completely confident in asserting that it "completely falls apart upon
examination."

> I sincerely doubt they're negotiating with Verizon over treatment of any
> traffic that does not come from Google.

Did you even read what Eric said? "What we mean is if you have one data type
like video, you don’t discriminate against one person’s video in favor of
another." If what they're negotiating only applied to Google, it would be the
opposite of the principle Eric is describing.

~~~
roc
> _"Your entire argument is based on the assumption that Google is being
> unreasonable or ignorant."_

Absolutely not. It's based solely on Verizon and Google operating in their own
financial best interests. In fact, as far as my argument goes, Verizon and
Google are placeholders for any ISP and any content company. The argument
would be the same if we were talking about Verizon/NBC, Sprint/Microsoft or
AT&T/Time Warner.

I'm not arguing against some hypothetical secret terms of a specific rumored
agreement. I'm arguing against the line of logic I quoted in my original
reply. Who it came from is irrelevant. It's a very common justification for
QoS-by-type and it's a wholly misleading simplification.

I only referred to Google's interests because you brought it up. It's not in
their best interests for them to argue for terms from Verizon that benefit
more than Google itself, because that would necessarily weaken any concessions
they could get for themselves. It would be _un_ reasonable to expect Google to
go toe-to-toe with Verizon behind closed doors and sign a binding agreement
for the benefit of the entire internet.

------
jedc
I also thought this was interesting (re: Android)

"Remember we make the majority of our money on advertising and the powerful
browser that is in Android when people search — they click on ads and that
revenue goes to Google. _And trust me that revenue is large enough to pay for
all of Android activities and a whole bunch more._ "

------
brk
It's funny that a lot of this would not be an issue if Verizon, et al,
actually had the ability to deliver the speeds they quote you on any sort of
consistent basis.

Most consumer-grade networking problems can be solved with "QoS via excessive
bandwidth". But, what the carriers want to do is oversell their backbones by
10,000%, and then charge extra to deliver the kind of service you would have
expected to receive in the first place.

Wholesale bandwidth to a Tier 1 provider is ~$15/Mb these days (monthly). This
doesn't include loop charges of course. But still Verizon, Comcast, etc.
should be able to deliver a symmetrical 5Mbs pipe to an average residence (ie:
in a populated suburb) for $60/mo. without the end user every really worrying
about running up against capacity for any practical application.

The ISP's are worried about being reduced to "dumb pipes", yet they could
easily differentiate based on speed, uptime, customer service and other things
that don't rely on packet tagging and prioritizations.

~~~
ergo98
>Most consumer-grade networking problems can be solved with "QoS via excessive
bandwidth". But, what the carriers want to do is oversell their backbones by
10,000%, and then charge extra to deliver the kind of service you would have
expected to receive in the first place.

While this argument sells to the crowd, it's facile and doesn't hold up to
scrutiny.

~~~
oostevo
Can you be more specific?

I'm really quite a layman in this area, but I've heard the overselling
argument quite a lot, and I'd be interested in hearing why it might not be a
valid one.

~~~
ergo98
Look at the prices of unmetered commercial connections to understand the
economics of overselling and burst connectivity.

I have a 15Mbps home connection, which serves me brilliantly when I need to
grab an ISO or watch a couple of videos. I have no illusions that this is
equal to a business 15Mbps connection, which would be significantly more
expensive. A T3 runs $3000 a month, best case. I pay $45 a month.

The original point that I disagreed with was the assertion that everyone
should have a unmetered 6Mbps connection. Firstly, I don't want a 6Mbps
connection -> I want a 15Mbps burst connection that best accommodates a normal
user. Secondly that's enough bandwidth that if you filled it at Amazon's AWS,
you'd be paying some $240 a month, and Amazon is at the crossroads of a number
of primary connections, pretty much the cheapest place to possibly origin
data.

Joe Homebody is many nodes down, through a lot of infrastructure and choke-
points, and the cost for throughput is significantly higher: My neighbourhood
has a large number of cable modem subscribers, and to aggregate the total sum
up through each junction would lead to enormous bandwidth potential.

In the mobile space the situation is vastly uglier. I don't think most people
realize how incredibly crowded the data space is.

~~~
nostrademons
The price of unmetered commercial connections has more to do with competition
(or lack thereof) among broadband ISPs and willingness to pay than technical
reasons. Broadband in Japan costs 15x less and runs about 6-7x faster than in
the U.S:

<http://news.bbc.co.uk/2/hi/technology/6900697.stm>

~~~
ergo98
[http://www.ibtimes.com/articles/39209/20100728/internet-
spee...](http://www.ibtimes.com/articles/39209/20100728/internet-speed-
akamai.htm)

I would love to know how much of the Japan rhetoric is actually based in
reality.

------
moultano
Related:

 _Verizon has also moved to dismiss the story. "The NYT article regarding
conversations between Google and Verizon is mistaken," the company said. "It
fundamentally misunderstands our purpose. As we said in our earlier FCC
filing, our goal is an internet policy framework that ensures openness and
accountability, and incorporates specific FCC authority, while maintaining
investment and innovation. To suggest this is a business arrangement between
our companies is entirely incorrect."_

[http://www.guardian.co.uk/technology/2010/aug/05/gogle-
denie...](http://www.guardian.co.uk/technology/2010/aug/05/gogle-denies-
verizon-deal-net-neutrality)

------
invisible
Sure sounds completely and utterly different from "Google and Verizon in Talks
on Selling Internet Priority." Thanks for failing us NYT.

~~~
sprout
>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.'

~~~
invisible
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."

Does that sound like what Schmidt said at all?

~~~
sprout
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.

~~~
invisible
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.

~~~
sprout
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.

------
jonknee
So the sky isn't falling, Google isn't evil [yet]. Amazing how quickly people
jump to conclusions.

------
Ardit20
Doesn't anyone think that we elect politicians to decide precicley such things
as whether there should be net-neutrality or not, rather than leave it to
massive corporations to decide in their own interest.

All it takes is one sentence

No content should be prioritized by any internet service provider.

Hmm, maybe someone should make a Facebook page with that sentence. I hardly
use Facebook myself, but seeing as this issue is quite in focus, it would
probably get traction with some promotion and then you can get a newspaper
saying 24,000 people have joined a facebook group called...

