Tuesday, February 28, 2006
Why is QoS only one way?
I was thinking about VoIP, and the state of VoIP technology. I got to thinking about QoS on routers, used to ensure the integrity of the VoIP stream.
As far as I know, QoS on current broadband routers is one-way. They only manage OUTGOING bandwidth. This is true of current "gaming" QoS on routers, I'm uncertain if it also applies to VoIP, but it would follow.
The excuse given for not doing QoS on incoming bandwidth is that the router has no control over incoming bandwidth, since somebody else is sending it. But this is not true! The receiving router has complete control over how fast the remote computer sends data. This is the entire point of the TCP sliding window.
So, why doesn't the router doing QoS simply lower the window size slightly on incoming TCP connections until it has some spare bandwidth to receive the important data (VoIP)? Yes, this method doesn't work for UDP, but as far as I can tell, most consumer bandwidth use is going to be from stuff like HTTP, P2P, and other TCP-based protocols. Games don't produce much incoming bandwidth, and VoIP is the thing we're trying to maximize.
So, am I missing something? Is there a reason why routers don't alter the window sizes to control the speed of incoming data to make room for stuff like VoIP?
As far as I know, QoS on current broadband routers is one-way. They only manage OUTGOING bandwidth. This is true of current "gaming" QoS on routers, I'm uncertain if it also applies to VoIP, but it would follow.
The excuse given for not doing QoS on incoming bandwidth is that the router has no control over incoming bandwidth, since somebody else is sending it. But this is not true! The receiving router has complete control over how fast the remote computer sends data. This is the entire point of the TCP sliding window.
So, why doesn't the router doing QoS simply lower the window size slightly on incoming TCP connections until it has some spare bandwidth to receive the important data (VoIP)? Yes, this method doesn't work for UDP, but as far as I can tell, most consumer bandwidth use is going to be from stuff like HTTP, P2P, and other TCP-based protocols. Games don't produce much incoming bandwidth, and VoIP is the thing we're trying to maximize.
So, am I missing something? Is there a reason why routers don't alter the window sizes to control the speed of incoming data to make room for stuff like VoIP?
Comments:
<< Home
TCP is an end-to-end protocol. The size of the window is somewhat controlled by the rate at which ACKs are sent back, if I remember. By managing your upload bandwidth, you are already doing that (although a common thing is to prioritize ACKs). I might be mistaken, though, and there might be something to fiddle with in one of the TCP headers, but it could be a trickier manipulation than what routers are used to do.
# posted by 
: 1:34 p.m., February 28, 2006
: 1:34 p.m., February 28, 2006
The bottom line is that while you can choose not to send a packet, you can't really choose not to have received a packet. Once you receive it there's not a lot you can do about it even if you really wish you had received another one instead.
Actually if you have a router you can pretty much implement downstream QoS by limiting the outgoing bandwidth from the router to your side of the network to just slightly less than your slow link's maximum bandwidth. Essentially this moves the bottleneck from the far side of your slow link to your side and puts it under your control.
You're still controlling the outgoing direction of an interface though. Just the outgoing interface facing your internal network.
Post a Comment
Actually if you have a router you can pretty much implement downstream QoS by limiting the outgoing bandwidth from the router to your side of the network to just slightly less than your slow link's maximum bandwidth. Essentially this moves the bottleneck from the far side of your slow link to your side and puts it under your control.
You're still controlling the outgoing direction of an interface though. Just the outgoing interface facing your internal network.
# posted by : 2:15 p.m., March 06, 2006
: 2:15 p.m., March 06, 2006 << Home
