When looking for articles about switching operating systems, most describe the Windows to Mac OS X change. Rarely there's a recent article that describes the opposite. This blog post is the first in a series of posts telling the adventures and challenges of a hardcore Mac OS X user who is forced to do the opposite. I'm not going into the rationale behind the switch, nor the reason, but rather focus on the user experience of hardware, operating system and software.
Some background: the source system is a 15 inch mid-2010 Macbook Pro (manufacture date 2010-05-24 as shown by the excellent CoconutBattery) running MacOS X Yosemite 10.10.5 with 8 GB of RAM, a dual core i5 @ 2,4 GHz, a 500 GB SATA drive and a 15,4 inch 1680x1050 display. If it wasn't for the failing NVidia GeForce GT 330M, which causes random spontaneous reboots, replacing the SATA drive with a 500 GB SSD drive would easily extend the life of this laptop with 4 years. Professionally I use productivity tools like MS Office, OmniGraffle, FileMaker Pro and all Apps that come with Mac OS X. The systems is Active Directory integrated and talks to our company MS Exchange environment. As a power user in an Internet organisation, I tend to heavily rely on Mac OS X's Terminal and love the Unix system under the hood. Since security is my primary activity, the laptop does have some other tools installed like "zenmap", "wireshark", "gpgtools" and Parallels. My user account allows me to elevate permissions when needed but only when the machine is connected to the office network and "sees" the AD severs.
The target system is a Dell XPS 9343 running Windows 8.1 Professional with 8 GB RAM, a dual core, dual threaded core i7 @ 2,6 GHz, a 250 GB SSD, and a 13 inch 3200x1800 Infinity touchscreen display. It is obviously Acitve Directory integrated and I have a normal user account. Traditional productivity suites are installed and some replacements for the software I used on the Mac.
I do have experience with pre-Windows 8 systems, unfortunately the Metro interface is brand new to me as is Windows 8.1, but as the interface has been built for tablets and ease of use I assumed it wouldn't be too hard to get used to it.
Before diving into the Operating System and the User Experience, let's first have a look at how the hardware performs and presents itself. The Dell XPS 9343 is comparable to a MacBook Pro 13 inch Retina. The MacBook will still be more expensive, but it has better hardware when doing a side by side comparison.
The first thing I noticed when using the laptop, was the apparent lack of a camera. The Infinity screen reaches out to all sides of the display and as a result, there is seemingly no room for a camera. Well not in the conventional location that is. There is a camera, in the lower left corner, which results in an extremely odd and unnatural perspective that feels like you're being watched by a bug.
The Infinity screen has a resolution of 3200x1800, which is a 16:9 ratio. 16:9 is acceptable for viewing media like one would do on a television, but makes no sense on a laptop. With a 16:10 ratio one has more screen estate on the Y-axis. Especially when using productivity apps like Excel and Word, this lack of screen estate becomes quickly annoying.
The Infinity display is Dell's answer to Apples Retina display. Unfortunately Retina is a bit more than a high resolution panel. Windows 8.1 insists that the optimal resolution is 3200x1600, but this results in dialog boxes and icons that are barely readable, text that is disproportionately fine, anti-aliasing that is simply wrong and the inability to handle high density and normal density screens at the same time. Some examples of this odd and disturbing behavior are illustrated in the picture gallery below.
As a result I need to lock my laptop resolution to 1600x900 and refrain from using an external monitor as the anti-aliasing simply makes most applications hard to read.
The display is a touchscreen, which is in my opinion a completely useless gadget on a laptop. Especially with a high glare display, the only thing a touchscreen does is getting a smudged screen. I had it disabled after I had adjusted the glaring screen for the umpteenth time and had all kinds of silly things happening.
As a security conscious person I don't like wireless connections to be active without any purpose. To my surprise the Dell XPS laptop has its Bluetooth on by default. No problem, I'll just click or right click the icon in the task tray and disable the thing. Huh? Nope... no possibility to disable the radio and even worse, there is no hard switch either to do it. That is until I pressed the Windows key and started to type Blue... and tadaah, there's a different Bluetooth settings app, which not only looks completely different with its Metro look and feel, but had the switch I was looking for.
And then there are some minor annoyances like a laptop that goes to sleep and doesn't wake up unless I actually close and open the display, or a pop-up headset selector whenever I insert my headphones and which make me go "WTF?! really???", or a touchpad that is completely ignorant of the extensive gestures I use(d) on the MacBook Pro.
First impressions and conclusions?
Remember my "happy eyeballs" post? Well, it looks like it's causing issues with YouTube clips both on MacOS X (Mountain Lion) as IOS (6). The symptoms? Clips that refuse to launch and result in a black screen filled with pseudo static and a "An error has occurred. Please try again later." Even worse, some clips actually start to play and stop after a while. BTW, the error message is very helpful Google, thanks. The issue exists on Safari and Firefox; Chrome seems to immune.
I was quite sure it had to do something with the dual stacked IPv4/IPv6 set-up we use at home as disabling IPv6 on my MBP made the issue disappear. But what is causing the problem? And is there a fix?
Googling quickly pointed to "happy eyeballs", which confirmed my findings after some observations and a good deal of TCPdumping. But why would this happen as "happy eyeballs" was created to prevent bad user experience on IPv6 in the first place.
To understand what happens while viewing a YouTube clip, I used HTTPfox on Firefox. HTTPfox is basically a local proxy which shows all the requests generated by the page you're visiting. The following screenshot shows a clip I was viewing and that stopped halfway...
Digging into the output of HTTPfox one can easily retrieve the URLs that deliver the actual video stream. Google has its own Content Delivery Network (CDN), which presumably tries to deliver data as close as possible to the end user.
In the above example the content cache was:
And now it becomes interesting as this host resolves to:
How and where the actual caching node is defined in the HTTP exchange is not really clear to me, but typically this is "somewhere" defined through geoIP lookups of the source IP of the requester. The obvious issue here is that my geo-location is completely different over IPv4 and IPv6 as I use a Hurricane Electric tunnel for my IPv6 connectivity. And even if my provider would deliver native IPv6 connectivity, it will still show a very different routing path.
While one is looking at a YouTube clip, multiple HTTP GETs are send out to the content cache to retrieve gradually the content. And here lives the culprit! As "happy eyeballs" kicks in and tries to deliver connectivity over the "best path", it might actually change its decision during the session. In other words, one HTTP GET can go out over IPv4 but seconds later, the next HTTP GET would go over IPv6. In theory this shouldn't be a problem if all caches are equal, but it depends heavily on how the caches actually operate and the application works. If sessions are involved i.e., are we sure that the IPv4 and IPv6 are actually the same machine(s); if not how is the system supposed to stitch the IPv4 and IPv6 session together? I believe this is exactly what happens with Safari and Firefox on YouTube. The fact that my IPv4 and IPv6 routing is completely different and the likelihood that the IPv4 and IPv6 infrastructure is not the same on the CDN side, might very well result in lost, unknown and zombie sessions.
For a pseudo streaming application like HTTP-based QuickTime streams or YouTube clips, "happy eyeballs" is very dangerous. Pseudo streaming applications send chunks of media data and rely on the fact that the network is faster than the realtime stream. For this specific clip it sends packets of 1,6 MB according to the HTTPfox output.
Conclusion: the browser should not only rely on the OS implementation of "happy eyeballs" as it could change IP stacks during a session or HTTP conversation with potential undesired side effects. It should stick to one IP stack after the initial decision handler to preserve session integrity.
As to view YouTube clips, I think I'll stick with Chrome until Apple and Mozilla engineers have figured out a way to fix this issue.
While digging into IPv6 support for the iPad, I stumbled on some unexpected results on my MBP. For starters, the default behavior I knew from a Snow Leopard MBP (10.6.8) is very different from what I observed on my Lion MBP (10.7.3).
To understand what follows, here's a brief description of my home network.
Regular IPv4 internet access is provided through VDSL over a b-box2 IAD. This multipurpose internet access device is part from the tripple-play offered by my ISP. It's a modem, router, firewall, dhcp server, dns proxy, etc... the box doesn't support IPv6 and neither does my ISP.
On my internal network (RFC1918 address space), I have an Apple Time Capsule, which has this odd feature that it can work as an IPv6 tunneling devices, and once configured, it will become the IPv6 router in the network. It takes the hassle out of IPv6 by taking the role of a Router Advertisement daemon and doubles as an IPv6 firewall and proxy name server. A /64 IPv6 network is assigned by Hurricane Electric to my Time Capsule and it's this prefix that is offered on the LAN through the Time Capsule.
Snow Leopard MacOS X 10.6.8 IPv6 behavior
Snow Leopard support for IPv6 is basic and straightforward. It will automagically configure itself when there's a Router Advertisement daemon on the LAN as shown in the following screenshot.
The IPv6 address is typically composed of the v6 prefix + the MAC address of the host. Besides auto-configuring its IP address and figuring out where the router is, there's nothing more to do to get the Internet6 at the doorstep. It's the most basic implementation of the Neighbor Discovery Protocol.
A dual stacked Snow Leopard will then default over IPv6 as per RFC3484. This means that if an application like Safari is asked to go to a site like http://www.ripe.net, it will go over IPv6 if it runs on a dual stacked system.
From a technical perspective and in a perfect world RFC3484 could be the desired behavior for a quick adaptation of IPv6. Unfortunately, the IPv6-world is not perfect and this has a negative influence on user experience.
Lion MacOS X 10.7.3 IPv6 behavior
Whilst writing my blog entry on IPv6 support on iDevices I noticed that Lion was behaving very differently from Snow Leopard. One of the most important differences is that Lion no longer defaults over IPv6 on a dual stacked system. While looking into this, I first believed to have bumped into a bug as Lion would often go over IPv6 first and fall back later to IPv4 for no apparent reason.
It took me quite some digging and googling to have a better understanding of Lion's IPv6 implementation.
For starters, Lion support RFC6106 DNS extensions on IPv6 router advertisements, this completes the auto-configuration features for both IPv4 and IPv6.
In practice Lion will use mostly the IPv4 address unless it is not available.
Secondly Lion supports the privacy extensions as described in RFC3041 which results in 2 IPv6 addresses per interface. One is still based on the MAC address, the other is based on a randomized value.
On the LAN, it will use the IPv6 MAC generated address, beyond the LAN it will use the randomized address.
The behavior that puzzled me the most is Lion's unwillingness to default over IPv6 like Snow Leopard does. I noticed this while visiting the ripe.net website. The first time it shows my IPv6 source IP address:
When the page is reloaded, it will no longer show my IPv6 address, but the source address is now my IPv4 address:
It took a while before I finally found what's causing this. It has nothing to do with the name servers and their order (the IPv4 DHCP configured name server is always taken before the IPv6 name server, simply because of the order in the /etc/resolv.conf file), although it does help to flush the DNS cache to reproduce the behavior.
For your information, the DNS cache can be flushed with the following command in a terminal window: dscacheutil -flushcache.
After quite some Googling I stumbled on an excerpt of a mailing list explaining the Lion behavior: http://lists.apple.com/archives/ipv6-dev/2011/Jul/msg00020.html. In short, Lion measures the round trip time over IPv4 and IPv6 and the fastest wins. It's an implementation of an algorithm called "Happy Eyeballs" which is described in a draft IETF standard: http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-07.
To understand the reason for "Happy Eyeballs", have a look at "Dual Stack Esotropia", an article written by glh at APNIC labs. The "Hampering Eyeballs" article on the RIPE Labs website by Emile Aben clarifies the challenge even more. In short, the algorithm is used in the application layer and was designed to handle optimized protocol selection (IPv4 versus IPv6 on dual stacked set-ups). It helps increasing user experience by monitoring which connectivity works best, not in throughput but in responsiveness.
Lion does this by by keeping track of RTT for every destination that was asked. This information is visible through the nettop -n -m route command on the cli. The command is interesting as it gives a dynamic view on the OS's routing table.
As a net result, in my set-up IPv6 looses under Lion, simply because the tunneled set-up is always slower.
According to the little literature available on the subject only very few applications and Operating Systems have deployed a version of "Happy Eyeballs". MacOS X Lion is the only operating system with the algorithm deployed. Chrome and Firefox have also an implementation which works very nicely.
From a user's perspective, "Happy Eyeballs" is a blessing in a dual stacked world. Under the hood, the applications figure out which connectivity works best and use it accordingly.
But from a technology point of view it's a bad thing, as it confirms there are issues with IPv6. The v6 network is not yet up to par and there are still some major peering problems, dividing the v6 network effectively in multiple Internets. Remember the Hurricane Electric versus Cogent issue? Cricket Liu had a blog post on the issue last year; one year later, it's still a problem.
Thanks to "Happy Eyeballs" I don't notice this issue under Lion. Thanks to "Happy Eyeballs" fixing the real challenges in the v6 cloud are minimized for an end user and pressure is reduced to get the v6 Internet as reliable and meshed as the v4 Internet.
In the end, "Happy Eyeballs" are a necessary evil to get IPv6 working on a dual-stacked end-user device. Being so user centric; no wonder Apple implemented it in Lion.
IPv6... we're not there yet.
About this Blog
IT Technology, networking, Apple, iDevices, Android, IPv6, DNS.