
Chrome Data Compression Proxy for Carriers and ISPs - luu
https://developer.chrome.com/multidevice/data-compression-for-isps
======
616c
Interesting, I was expecting to see something about QUIC/UDP and was
pleasantly disturbed by something different entirely.

First takeaway: SSL is optional? Let's the games begin! Better pay your ISPs
on time, or God knows what they will accuse you of, extralegally or not, to
get encryption turned off here.

Second takeaway: our company had major problems with upstream link from a
local ISP to VPN across the Atlantic to the link on the other end and egress
traffic out of our main office. It is really more than one, but you get the
idea. The ISP in the US mentioned "caching problems" when we had many users
with irritably high latency for Google servers: slow page loads, terribly
syncing, crappy IMAP, but only for Google services we use. This data
compression stuff seems limited. Does Google have boxes on-prem for ISPs a la
Netflix that do the same thing or is improperly configuring this for an ISP
enough to do damage?

[https://openconnect.netflix.com/](https://openconnect.netflix.com/)

~~~
pavs
Yes its called GGC.
[https://peering.google.com/#/](https://peering.google.com/#/)

We got ours delivered about 6 months ago. It usually works fine but once in a
while google services will act up, but most of the time the issue is at ISP
end because even the GGC nodes needs BW to pull non-cached content, but if
your ISP is overselling BW it will really hamper the performance on the GGC
nodes. The GGC nodes themselves have capacity limitation, our 3 nodes has a
total capacity of 19gbps, I am guessing if we were to saturate that throughput
then the services will be affected.

~~~
sofaofthedamned
That's interesting, mind expanding on your problems?

I know that as a BT (uk) ISP customer mostly I can ping google.com and it
returns in 6ms from a BT IP, which would indicate they're using GGC. Sometimes
it resolves to a Google IP in 12 ms.

Last month however it started resolving all the way to Amsterdam and
subsequently to the US with a corresponding increase in ping time. Was this
their way of saving energy by shutting down DCs, or was it a bigger problem
like capacity or an outage? Either way despite the latency issues the fact it
always works in a plus for their infrastructure team.

~~~
pavs
I am sorry I cant get in to specifics. But Routing for GGC is controlled by
Google, it is not out of ordinary for your google traffic to not come directly
from the GGC node of you ISP. Any internal routing change by your ISP might
also cause your Google traffic not coming from your ISP GGC node.

There are too many variables its hard to tell what exactly caused your issues.

But generally speaking GGC nodes are very reliable, their support is
responsive and knows what they are doing very well and most importantly it
saves us insane amount of money (cause BW is expensive here), and our users
are getting better service.

~~~
voltagex_
Are you able to disclose if it caches/proxies YouTube?

~~~
pavs
Yes of course, the main traffic is youtube bw, which I think its 95% of the
total traffic going through ggc nodes. But the don't have a breakdown of their
traffic on GGC dashboard. We know it because we know our traffic before we had
GGC and after we had GGC.

------
caleblloyd
"Because requests to destination websites are sent from Google's servers, the
IP address of the client making the connection will reflect the location of
Google's servers, not the user. The DCP sends the IP address of the client in
the X-Forwarded-For header with each request, for example: X-Forwarded-For:
74.125.239.111"

Web servers shouldn't blindly respect this X-Forwarded-For header coming from
any random server.

~~~
dantiberian
_Websites should use the X-Forwarded-For header to determine the IP address of
the client for the purpose of IP geolocation._

I don't think they're suggesting you just assume that the IP is correct, only
that if you are doing some kind of regional customisation that you can use
that X-Forwarded-For header to help.

------
aorth
In an increasingly end-to-end encrypted world, wouldn't services like this be
going away eventually?

~~~
mindslight
Yeah honestly. You'd naively think that with increased bandwidth, we'd be
playing fewer backwards games. But you'd be wrong, because more traffic
actually means it's more enticing for providers to engage in such
"optimization".

We're at the point where the end-to-end principle really _requires_ strong
crypto to resist economic attacks such as this one.

------
ikeboy
So how hard would it be for a user to bypass a network block on encryption?
Just redirect the URL given to a server that returns the right page (or
doesn't exist)?

~~~
cm3
Same thought here, wondering if it's deliberately easy to circumvent and they
only implemented this due to force of hand.

------
anc84
I would like to self-host something like this (plus ad-blocking) to minimise
my mobile traffic consumption, any recommendations for a lightweight Linux VPS
system?

~~~
jedisct1
mod_pagespeed: [http://modpagespeed.com/](http://modpagespeed.com/)

[https://00f.net/2012/06/02/mod-pagespeed-as-a-proxy-for-
your...](https://00f.net/2012/06/02/mod-pagespeed-as-a-proxy-for-your-phone/)

~~~
goombastic
No security. Maybe binding it to localhost and using squid as a frontend with
authentication would work?

------
homero
Wow Google is screwing encryption, nsa honey pot

~~~
mwfj
No. According to this document, there is always _at least_ as much encryption
with this proxy enabled as it is without.

