On 4/17/15 07:55, Ca By wrote:
On Thu, Apr 16, 2015 at 11:24 PM, Lorenzo Colitti <lore...@google.com
<mailto:lore...@google.com>> wrote:
And in the meantime, accept that the users of that operator's
network cannot reliably reach our services?
If you were a user of that operator, I suspect you wouldn't like
that. I suspect you especially wouldn't like it if you called the
operator and they told you there were no problems, and most websites
work fine. Unfortunately, in our experience, both happen routinely.
Often operators will contact us and claim there is no problem in the
network, and most of the time it turns out that there was a problem
they didn't know about. Once the claim was made that "this is an
IPv6-only network, so IPv6 must be working". Unfortunately that
wasn't true either.
If an operator is monitoring IPv6 traffic levels, it will be pretty
clear if Google stops serving AAAA records to their resolvers. If
they're not monitoring IPv6 traffic levels, then chances are they're
not monitoring reliability, because it's much easier to monitor
traffic than to monitor reliability.
There's also the question of how whether it's reasonable to expect
websites to to reduce the reliability of their services in order to
fix problems in other networks that they have no control over.
Remember, IPv6 brokenness was one of the main reasons it took so
long for popular websites to enable IPv6.
I agree with Google's approach for now.
But eventually it will have to be re-visited since Google represents a
huge amount of traffic, pulling back AAAA and sending that huge amount
of traffic to a CGN that is not dimension for it.... you are going to
have a bad time.
And, AFAIK, these measurements and adjustments are not real-time... so
they blow up a CGN ... they wont automagically roll back for a while.
So, Google AAAA magic becomes a DDoS of sorts.
Speculation weakens your argument.
I'd like to point out that the microscope Lorenzo and Erik were under to
justify, implement, and instrument IPv6 inside Google was tremendous.
Very few people would've put up with all the roadblocks, and IPv6 would
be much less further along industry-wide, without those two dealing with
vast numbers of vendor bugs, poorly thought out protocol features, and
writing much of the code to get things going themselves. I'm proud to
say I helped Lorenzo get his IPv6 pilot going, but then I looked away
and when I looked back it was a train hurtling along. I doubt very much
the continued success of IPv6 will cause Google to start doing stupid
things.
Neither Lorenzo nor Erik should ever have to buy their own beer ever
again IMO.
-Scott
Maybe i am wrong.
CB
On Fri, Apr 17, 2015 at 12:28 PM, Brian E Carpenter
<brian.e.carpen...@gmail.com <mailto:brian.e.carpen...@gmail.com>>
wrote:
On 17/04/2015 15:17, Erik Kline wrote:
> On Thu, Apr 16, 2015 at 7:41 PM, Phil Mayers
<p.may...@imperial.ac.uk <mailto:p.may...@imperial.ac.uk>> wrote:
>> On 16/04/15 01:57, Lorenzo Colitti wrote:
>>
>>> For the avoidance of mystery: Google performs measurements
of IPv6
>>> connectivity and latency on an ongoing basis. The Google
DNS servers do
>>> not return AAAA records to DNS resolvers if our
measurements indicate
>>> that for users of those resolvers, HTTP/HTTPS access to
dual-stack
>>> Google services is substantially worse than to equivalent
IPv4-only
>>> services. "Worse" covers both reliability (e.g., failure to
load a URL)
>>> and latency (e.g., IPv6 is 100ms worse than IPv4 because it
goes over an
>>> ocean). The resolvers must also have a minimum query
volume, which is
>>> fairly low.
>>
>>
>> Lorenzo,
>>
>> Thanks for the response.
>>
>> Do you know if Google have given any thought as to how long
they might find
>> it necessary to take these measures? Years, indefinitely?
>>
>> Just curious.
>
> It seems to keep on finding things, so...
But the incentive is wrong. Forcing users to drop back to IPv4
offers
no incentive to fix the IPv6 problem. The correct incentive
would be to
tell an operator that they will be blacklisted unless they fix
{X and Y}.
Brian
