tserv15.lax1 utilization...

[jsterck]

Is there a way to determine the overall utilization of a tunnel server?  I see the number of tunnels per tunnel server in the chart (LAX1 has 4000+), but I am trying to determine IPV6 related performance issues.  I am seeing 9 megabits on my V4 stack, but on IPV6, we're seeing 3-4 megabits.

Now that more sites are using V6, the performance issue is making it less than pleasant.  Disabling V6 stack on the NIC shows a very noticeable difference.

Jeff

[jsterck]

Also, my youtube experience is dodgy at best.  Sometimes I can get a video to play, but I have to jump around in the video then eventually it might play.  Switch the nic to drop the IPV6 support, loads instantly.

Hmm

[kasperd]

Did anybody try to log and replay an HTTP session with one of the youtube streaming servers? If it is possible to replay the exact same HTTP request against both the IPv4 and IPv6 address without the play applet getting in the way, it might provide some clues and more accurate performance measurements.

[jtcloe]

Testing at different times of the day, are the results consistent, or does it work significantly better at 3:00 AM?

[jsterck]

Its hard to say.  It seems somewhat consistent.  I cant say that Ive gotten up at 3am to test it, I suppose I should try it out sometime.  I know at some times I simply cant get any videos to work, others times, I can, or it takes a good 30-40 seconds before it even starts to stream.  Sometimes I have to click around the progress bar at the bottom will sometimes initiate a stream but I havent really noticed it being affected by time of day.

I do notice that at times I see "transferring data from s.ytimg.com".. so If I look that up, I get the following:

Server:  dns-sj.cisco.com
Address:  171.70.168.183

Non-authoritative answer:
Name:    ytstatic.l.google.com
Addresses:  2001:4860:4001:800::1001
          74.125.224.33
          74.125.224.34
          74.125.224.35
          74.125.224.36
          74.125.224.37
          74.125.224.38
          74.125.224.39
          74.125.224.40
          74.125.224.41
          74.125.224.46
          74.125.224.32
Aliases:  s.ytimg.com

Could it be that since there is only one IPV6 record for this, that its possible that there is a bottleneck there?

Even on my android phone, I can tell when its connecting via ipv6 and it will do app downloads in single digit kb/s vs the usual 300-400kb/s.

Ultimately, its functional, but at times it can be painfully obvious that certain sites are dialup speed.  When I look it up, its always an IPV6 site.  And if I disable ipv6 on the nic, instantly faster.  I can even do it mid stream of a youtube video.

I can initiate a video and wait.. it might get the first 2 seconds then sit at the hourglass/circle icon waiting for more data.  If I open my nic controls, disable v6, it will stream immediately.  Re-enable v6 and it stops again.  Without closing a browser, or restarting a request.

[jtcloe]

Could it be that since there is only one IPV6 record for this, that its possible that there is a bottleneck there?

Not saying its the case here, but I think you're going to start seeing a lot more use of anycast with ipv6 instead of a long list of ipv4 servers.

As with any new technology, there will be pain in implementing it correctly.

[kasperd]

I think you're going to start seeing a lot more use of anycast with ipv6 instead of a long list of ipv4 servers.

There are problems which can be solved by using multiple A records, which you cannot solve by using anycast. If a connection to one of the IPs fail, the client can try another. If you think anycast will give you automatic failover, you are mistaken. In order for that to work you'd need to reliably detect when one replica goes down and ensure no traffic goes there. Not going to work.

Even the HE anycast DNS sometimes suffers from that problem. The anycast address will go to the closest DNS server, which might not respond. I actually put the unicast address of another of the servers as secondary.

Another problem with anycast is that as traffic does get shifted around between replicas, all TCP connections will break. Solving that is complicated.

Of course it is possible that Google uses different loadbalancing mechanisms for IPv4 and IPv6, but any loadbalancing method that works with one can also be done with the other.

But right now I think each of those IPv4 addresses handle more traffic than the IPv6 address.