Networking: April 2008 Archives


April 18, 2008

At the FCC hearing yesterday, there was a lot of talk about metered Internet. (See also Rob Malan Rob Malan arguing that net neutrality legislation will inevitable result in metered Internet service). It's certainly true that metered Internet is one possible outcome of network neutrality regulation, but I'm not convinced that it's the only one. It's interesting to note that at the same time as we're arguing about this, all the major wireless service providers (which have historically been incredibly stingy about per-minute charging) have recently rolled out unlimited voice offerings.

Now, you could certainly argue (as Rob's argument implies) that there's an upper limit on how much bandwidth can be used by voice and so as the technology has improved, it's become cost effective to offer unlimited voice service, but that the bandwidth consumed by video will be much greater. On the other hand, just last year Apple pushed Cingular/AT&T into offering an unmetered data plan for the iPhone, and apps like YouTube for iPhone clearly encourage users to consume larger amounts of bandwidth than they would if just checking their email. Now, obviously the cell providers have a lot of latitude to manage the data portions of their network, but it still seems to me that there are a lot of factors in play here and that metered Internet is not the only possible outcome, even in a more highly regulated regime.


April 10, 2008

UK ISPs say that the the BBC's iPlayer video service is "threatening to bring the network to a halt":
The success of the BBC's iPlayer is putting the internet under severe strain and threatening to bring the network to a halt, internet service providers claimed yesterday.

They want the corporation to share the cost of upgrading the network - estimated at £831 million - to cope with the increased workload. Viewers are now watching more than one million BBC programmes online each week.

The BBC said yesterday that its iPlayer service, an archive of programmes shown over the previous seven days, was accounting for between 3 and 5 per cent of all internet traffic in Britain, with the first episode of The Apprentice watched more than 100,000 times via a computer.


The whole reason I get Internet service is so I can download stuff off the Intertubes, which means that whenever I find something cool and want to suck it down I don't want my ISP complaining that I'm using too much bandwidth. Now, it's true that it's true that when there is a lot of data flowing from a server on ISP A to ISP B, it's a bit confusing whether A should pay B, B should pay A, or whether money should change hands at all. Note that these aren't networking issues, but pure economic issues—issues like this have been relevant ever since the days of paper mail. (In the Internet world, a lot of this is social. The amount of money you have to pay in settlements sort of scales with bandwidth until you get big enough that people want to peer with you, at which point you don't pay). And I'm not saying there isn't a need for the ISPs to upgrade their infrastructure and figure out who's rates to jack up in order to pay for it. But these issues aren't really effectively solved by every ISP trying to hold up any service that gets popular.


April 8, 2008

A group in Colorado recently reported that Comcast had introduced a new traffic shaping mechanism which was blocking even non-P2P TCP connections:
Recently, it has been observed that Comcast is disrupting TCP connections using forged TCP reset (RST) packets [1]. These reset packets were originally targeted at TCP connections associated with the BitTorrent file-sharing protocol. However, Comcast has stated that they are transitioning to a more "protocol neutral" traffic shaping approach [2]. We have recently observed this shift in policy, and have collected network traffic traces to demonstrate the behavior of their traffic shaping. In particular, we are able (during peak usage times) to synthetically generate a relatively large number of TCP reset packets aimed at any new TCP connection regardless of the application-level protocol. Surprisingly, this traffic shaping even disrupts normal web browsing and e-mail applications. Specifically, we observe two different types of packet forgery and packets being discarded.


We synthetically generated TCP SYN packets at a rate of 100 SYN packets per second using the hping utility [3]. The packets were destined for the reserved IP address, on which no host is present. We simultaneously collect network traces using tcpdump [4]. This data collection process was repeated at various times throughout multiple days. In addition, we could monitor a destination host to determine if outgoing packets reached their destination, and to determine if responses are generated by the destination host or by a third-party. Finally, this data collection was conducted from multiple Comcast accounts, all within close geographical proximity.

My initial reaction was that 100 SYN packets per second is a pretty pathological load, especially when these packets are being sent to a bogus net block (2/8 is unallocated by IANA) and that this sounded a lot more like some sort of anti-DoS measure, not really traffic shaping. The answer seems out to be even simpler:

A note regarding our findings: Further experiments have led us to believe that our initial conclusions that indicated Comcast's responsibility for dropping TCP SYN packets and forging TCP SYN, ACK and RST (reset) packets was incorrect. Our experiments were conducted from behind a network address translator (NAT). The anomalous packets were generated when the outbound TCP SYN packets exceeded the NAT's resources available in it's state table. In this case, TCP SYN, ACK and RST packets were sent. We would like to thank Don Bowman, Robb Topolski, Neal Krawetz, and Comcast engineers for bringing this to our attention. We sincerely apologize for any inconvenience that this posting may have caused.

This sounds pretty plausible to me; NATs often have fairly small state tables and 100 cps could definitely overload a residential NAT pretty quickly, and it's certainly easy enough to forget that the NAT box you're sitting behind is anything other than transparent. One thing that surprises me a bit is that the researchers claim to be seeing two kinds of anomalies: RSTs and spoofed SYN/ACKs. One would generally expect to see only one kind of response to overload. Maybe they have more than one NAT, though. It would certainly be interesting to hear what exact network gear they are using.