« Wireless HD on the horizon; YouTube to make money?; Usage meters and caps | Main | Flash to use P2P to deliver video; malware threatens Facebook users; NFL in 3D »

Thursday, December 04, 2008


Feed You can follow this conversation by subscribing to the comment feed for this post.


The UDP thing is a non-issue. Chris described the TCP/UDP protocols pretty well above. It is NOT "made for VoIP", and as long as it's not using a dedicated VoIP port number (which it isn't), ISPs can choose to block it very easily. Also, I think that UDP has been an option for BitTorrents since the standard was around.

Also, I think doing this to try to prevent TCP RST packets is a bit of "too little, too late". Comcast has already dropped that model, due to the EFF lawsuit, and most MSOs have moved to a usage-based system in response to it, anyway.


I have no clue wat this is. I need to upgread on my tech info,

Chris Buechler

To clarify UDP vs. TCP - the standard for UDP is dated August 1980, many years before VoIP, online gaming, etc. existed. The difference between the two is TCP provides reliable delivery and UDP does not. If a TCP packet is lost, the protocol knows that and it is retransmitted. A lost UDP packet is just gone. Applications that use UDP have to use other mechanisms for loss detection and correction, if such a thing is needed. The reason UDP is used for time sensitive traffic is because you don't want that traffic being retransmitted if it's lost - a VoIP packet that comes in a fraction of a second late because of a retransmission is completely useless. So to avoid wasting bandwidth for something that will be useless if it doesn't arrive the first time, you use a connectionless protocol like UDP.

TCP is different in that it ensures reliable delivery, so the applications using it do not need to be concerned with network reliability. Part of the functionality of TCP is the ability for a host to tell another host that the connection has been closed (a TCP RST (reset)). What "network management" of ISPs will commonly do is spoof TCP RST packets to their customers, looking like they came from the remote P2P endpoint. This is an effective way of limiting TCP communications because it provides a means of killing the active connection.

UDP makes doing that impossible, because there is no concept of a session with UDP, and no means of telling a host the connection is closed. It'll just keep sending traffic no matter what the ISP does. The ISP can drop it somewhere upstream in their network, but the effectiveness of that is much more limited.

ISPs will be fighting a losing battle until going to usage based billing. It's more fair for the customers (if done reasonably), and easier to handle for the ISP than trying to keep up with the changing traffic on the network.

Steve Huff

If people's bandwidth was to be limited, there would need to be a easy way to monitor what they have used so far.


Love will always find a way.


I've always found it a bit disturbing when P2P applications have been painted as the black horse. These applications aren't created with the intent to crash the internet or cause global nuclear war. They are created as a legitimite way to transfer large files with a limited amount of bandwidth.

Now limiting ones usage of bandwidth to something reasonable I am for. I currently have an ISP with a monthly bandwidth limit, but a limit that is quite generous.

The comments to this entry are closed.