Update: clarified the point about IPv6 (see the comments)
Our old friend Curt Monash has a think-piece about net neutrality up on his weblog. In it, he argues for ISPs to sell a premium service tier for high-bandwidth/latency-sensitive applications:
The current Internet [can't] well support … communication-rich applications such as entertainment, gaming, telephony, telemedicine, teleteaching, or telemeetings.A bold assertion. Certainly if t’were true the anti-neutrality camp would have a point.
I’m not 100% in either camp, but my gut tells me that today’s IP routing technology is holding up well. It’s the lack of investment in sufficient peering bandwidth and router horsepower that’s letting the side down. That and the criminally glacial progress towards RSVP-TE (RFC3209) with label switching and IPv6, a combination that would allow much better traffic prioritisation.
He later clarified his assertion:
I think that in a high fraction of applications that amount to real-time communications, good quality will entail seriously sub-second latency. I don’t think it will soon be affordable to provide that kind of QOS for all traffic. Ergo, tiering. Until we get to unmeteredly-cheap, just-like-being-there transmission of full-room-sized sounds and images, there will be a place for differentiated QOS.Here's the thing... Those of us that live the other side of the Atlantic live with 250ms latency every day, when we connect to services hosted in North America. I dare say the same is true for those on the other side of the Pacific. There's not much getting around the speed of light.
Yet stuff still works just fine. TCP is designed to get the best out of a latent connection. Even if that latency is unpredictable/chaotic (as is often the case with latency caused by congestion).
I recently ditched my old ISP. It got taken over by a company that appear to be running into the ground. Typical latencies over the first hop grew from 20ms to 500ms (often higher). But even though there was severe network congestion, stuff still worked fine.
Of course, if an application writer makes assumptions that ignore realities such as the speed of light or temporary congestion, their application's going to behave badly. But no premium QoS in the world is going to help that.
My sense is still that the ISPs that are complaining about net neutrality are simply being greedy and don't want to invest money to cope with the growth in usage.
There are perhaps some lessons to be learned from the experience of UK ISPs when many users' connection "suddenly" jumped from fixed-rate DSL connections in the 512Kb/s - 2Mb/s range to an "up to 8Mb/s" service that offers the highest speed that the phone copper can support. How the various ISPs coped with the associated jump in demand makes for a salutary tale.
But that's the subject of another post, some other day...
Update: clarified the point about IPv6 (see the comments)
4 comments:
IPv6 has absolutely nothing to do with traffic prioritisation - it uses DiffServ traffic classification and priorities to deliver QoS in the same ways as IPv4. There is an IPv6 feature called the flow label that was intended for use with a now-obsolete QoS technology known as RSVP that went beyond class of service style QoS but was never actually deployed even in private IP networks aimed at business services.
I jumbled two thoughts together, well spotted. I was also thinking about RSVP-TE (RFC3209) with label switching. This allows end-to-end control of priorities, rather than the nasty, blunt instrument known as traffic shaping inflicted on customers by some UK ISPs.
But IPv6 improves the experience, in the sense that the consumer end doesn't need to do NAT. This again allows better control of the priorities.
RSVP-TE is about engineering large aggregate virtual pipes (Traffic Engineered tunnels using MPLS) within IP/MPLS core networks (i.e. MPLS label switching). You can use it to deliver efficient CoS/QoS in the sense of "10 Mbps of Gold CoS goes this route" and "20 Mbps of best effort CoS goes that route" via the RVSP-TE signalled MPLS TE tunnels - however, that too has nothing to do with IPv6, as it is used with v4 and v6 and doesn't depend on the IPv6 flow label.
So RSVP-TE isn't end to end at all, in fact it's designed for the core. You may be thinking of RSVP without the TE suffix, which was host to host but never really deployed apart from a few cases where it can signal per-flow QoS for VoIP - but there are other VoIP call admission control and QoS solutions, mostly based on marking the traffic with DiffServ priority and then doing CoS within the network.
Traffic shaping seems to have a bad name, but it's just another form of CoS. The real issue in the UK is that BT's legacy ATM-based aggregation network (which links the DSLAMs to the IP core) is expensive, and charged per Mbps to ISPs, so the ISPs need to carefully shape traffic to manage usage by ultra-heavy users (e.g. P2P filesharing). This goes away when BT upgrade their entire network as part of 21CN, as you then get faster and cheaper Ethernet-based aggregation onto a new MPLS/IP core. I'd expect their bandwidth charges would then go down reducing the need to traffic shape heavy users of DSL.
I didn't say that either depends on the other. I said that the combination would allow much better traffic prioritisation.
Agreed on your comments about IPstream pricing, but I think you're smoking something if you think 21CN is going to fix the pricing issue, absent OFCOM growing a pair.
Post a Comment