And Furthermore, Bill...
In fact, it’s something that the whole telecom/Internet industry needs to get its act together on, and it relates to a topic that’s high on the agenda of a lot of service providers: Virtual Private Networks.
In a nutshell, vendors need to come up with some standard ways of ensuring that their equipment can be configured to ensure that packets carrying streaming media won’t be dumped while they traverse a VPN tunnel. And in order for this to happen, service providers also need some rules on how to configure the hosts, switches, and routers so they all work in harmony when handling big packets.
I guess you may be wondering why I’m writing to you about this issue, if it concerns a whole host of other folk as well as Microsoft.
There are two reasons. First, it's folk using host software that experience the problems this creates, so you’re likely to get the blame even if it isn’t your fault. Second, someone needs to encourage the networking community to get its act together on streaming media, and I think you're just the hombre with the cojones to do this.
In the study that I cited in my original letter, the Cooperative Association for Internet Data Analysis (CAIDA) found that 16 percent of traffic flows were fragmented by tunneling technologies.
The basic problem here is that edge equipment sets maximum transmission units (MTUs) that are too big for the equipment at intermediate points in the tunnel. As the equipment typically can’t fragment packets in the middle of a tunnel, it drops the packets altogether.
One reason for this is that Path MTU Discovery – the protocol used to establish the MTU of a tunnel – sometimes doesn’t work. This may be because the host software or routers implement Path MTU Discovery in different ways.
The requirements for host software in this respect are laid down in a couple of ancient Internet Engineering Task Force (IETF) Requests for Comments – RFCs 1122 and 1123 – which date back to 1989! (I know there’ve been partial updates to these RFCs, but they don't address Path MTU Discovery.) The requirements for IP version 4 Routers (RFC 1812) are eight years old, and there’s no RFC at all covering IPv6 routers.
With such out-of-date or absent requirement RFCs, it’s hardly surprising that vendors end up implementing inconsistent approaches to Path MTU Discovery, which cause problems in practice. They’re often problems that drive service provider support staff wild, because “pings” in small packets can get through, while streaming media, contained in larger packets, can’t.
Another reason for Path MTU Discovery not working is that it’s often blocked by service providers anyhow. It’s part of the ICMP (Internet Control Message Protocol) family of protocols, and some service providers configure their equipment to block all ICMP packets because of security threats sometimes associated with the protocol family (for example, ping of death and smurf).
These Path MTU Discovery problems can happen with any VPN protocol, but there’s an added complication with Multiprotocol Label Switching (MPLS) VPNs. In some circumstances, intermediate routers can add an extra label to a packet, so that it becomes too big for the tunnel. (For an explanation of why this happens, see Note 2.)
The MPLS VPN problem is being addressed in an IETF Draft dealing with consistent MTU reporting for the Label Distribution Protocol (LDP). Work is nearly complete on this draft, being written by Ben Black of Layer 8 Networks and Kireeti Kompella of Juniper Networks Inc. (Nasdaq: JNPR). Work is already complete on the same feature for RSVP-TE (Resource Reservation Protocol – traffic engineering).
Many of the readers on the message board attached to this letter have urged increasing the Internet MTU to solve these issues. See, for example this message from celebrity poster Tony Li, Procket Networks Inc.’s chief scientist.
You can’t simply wave a magic wand and convert all Internet devices to larger MTUs. But by correct operation of the host software, routers, firewalls, load balancers, and all the other IP devices in the packet path, at least we can make the best of the MTUs that are supported today.
By the way, Bill, I really appreciate Microsoft’s David Caulton responding to the points made in my original open letter. In his post David raised a number of valid questions that I’ll respond to in due course, when I’ve got some feedback from various people. In other words, I haven't finished yet! (That's a promise, Bill, not a threat...)
Again, Microsoft (and, of course, any interested readers) may respond to these suggestions by either emailing me at [email protected] or contributing to the message board linked to this article.
And Bill? Bummer about that fine. Those Old Europeans just don't understand American Free Enterprise.
— Geoff Bennett, Director, Light Reading University