Technology for Mortals

Using an aftermarket firmware/etc you can observe the number of active connections. Even though the data only comes to and from a few points, your network equipment will leave old connections open numbering from the 100′s to the low 1000′s depending on how many peers youve contacted. One possible solution ive seen is to greatly reduce your connection timeouts, but this seems to be impossible with most home router firmwares. (DD-WRT and openwrt firmwares are also good for people looking to learn more about the networking equipment they use)

It’s NOT a problem with Bittorrent. The problem is at _your_ end. Really.

You don’t have access to the modem, but you have access to the router.

Configure the router to assume the uplink is 400kbps or lower. Pick a value slightly less than your actual uplink speed – actual not what the ISP claims they give you. Basically you saturate the link, then reduce the router uplink speed till your QOS stuff starts working properly. If your router can’t do that, get one that can.

The narrowest part of the straw controls the flow. So make your router the narrow point.

If a 20+ms (the time it takes to send one 1500 byte packet out your uplink) latency hit is too high, then you will have to get your router to assume the wan uplink can only support say a max packet size of 500 bytes or something small. Your router must also be able to insert online game packets between the 500 byte fragments of the large packets. With this your max latency hit will be reduced to a third. Naturally this will hurt P2P and HTTP download throughput, and cause other problems (paranoid/clueless sites/people might drop IP fragments etc). So I don’t recommend this last bit – it’s only for people who are desperate and know what they are doing.

"Configure the router to assume the uplink is 400kbps or lower. Pick a value slightly less than your actual uplink speed – actual not what the ISP claims they give you"

Already did that on DD-WRT link. Didn’t seem to work.

"It’s NOT a problem with Bittorrent. The problem is at _your_ end. Really."

Why assume that? Why assume that only a network based solution can fix this? I can certain agree that a good network based QoS solution can fix this, but why must that be the only way? I’m saying that it’s possible to fix this on the application side and that could serve a marge larger market share of people who don’t have network based solutions in place.

I stand by the former comment that routers around the world (not just home routers) would get CPU load problems if all the packets in bandwidth-heavy transmission suddenly were cut to half size. This would mean twice as many routing decisions per time unit, and could clog up networks around the world worse than the initial problem you’re describing.

P2P applications could just space out their 1472 or 1464 byte packets evenly and that would help a lot. As for CPU loads, I believe the existing router infrastructure should be able to handle it. With the growth of BGP tables, routers are constantly being upgraded.

I’ve noticed that utorrent is not very strict with upload limits, it will happily send more KB in a second than the limit according to two bandwidth meters (Windows graph thingy, Everest home), and on two different computers. When there’s a download going on as well, the limit somehow becomes a lower limit, not getting below it, instead of not going above it. So my guess bittorent uses the worst possible combination for a stable internet connection.

If you have 1024kbs download and 512ksb upload bandwith,

doing 50kb/s download causes the the same latency than doing 25kb/s upload. When combined (uplink and downlink) the latency is more.

math.

from my expirience, uploading while gaming causes pl and latency *

What you’re chasing is H-FSC. Build a Net or Free BSD box and insert it between your switch and router.

http://www.cs.cmu.edu/~hzhang/HFSC/

Already tried HFSC in DD-WRT, it did something but actually made things worse

Not mentioned here as of yet is the excellent pfsense (http://pfsense.org) which utilizes openbsd’s pf. Their QoS may have something to offer in this situation.

Queueing is not something you can just ‘turn on’ and have it work I’m not usre how much configuration you gave queueing before, but you could try as below. The beneift of HFSC is that it decouples latency and bandwidth. Normally a low bandwidth queue (such as voice) gets starved by a higher bandwidth queue. THe HFSC latency priority ‘realtime’ essentially allows your voice packets to jump the queue up to their configured bandwidth limit during contention. I note the packet size issue you mentioned above as well – you could try changing your voice packetization from 20ms to 30ms which will make it slightly less sensitive to jitter at the expense of greater susceptability to packet loss.

HSFC gives you 5 latency priorities to go with your bandwidth definitions. If you can give it another go, ensure that your voice traffic is marked EF (DSCP 46) from the device generating the voice traffic (ATA, IP handset etc – most will allow you to set this). Set your link bandwidth according to your upstream sync speed (eg 420kbps). Define EF traffic to get realtime priority on your HFSC queue and define the minimum guarantee according to your codec (eg 10% or 42kbps for G.729) and typical concurrent call limit. This should help your outbound stream (People hearing you). There’s not a heck of a lot you can do for the incoming stream except to really try to limit the torrent download to keep bandwidth available for voice. Throttle your torrent client download bandwidth and limit the number of connections per torrent and / globally. This should help to smooth out your individual connections and soften any peaks.

It’s not the job of the application to queue the packets – thats normally the job of the edge device as its only the edge device that has knowledge of all traffic from all applications and clients on the LAN sending out to the WAN. The router is ideally placed to queue and decide in what order the packets should go out to the WAN based on some means of classification of traffic (in this case DSCP values).

We all know that once P2P gets going on one computer, seems that on a second computer – the processor feels like it even takes a hit.

I am a network guy and need my home network for work testing. I mean sometimes I need to log into my home computers and hit my work network and test OWA, web sites, and ftp sites. I have to log in and shutdown Azureus in-order to work.

Thanks George, for pointing this out to the community as we all exist to make technology better and to make it work with as little resources as possible. Otherwise, multi-tasking is pretty much obsolete.

The issue here can be explained simply by a well-known queueing theory idea, captured as "Little’s Theorem" or "Little’s Lemma".

If you have a queue that can handle requests (packets) at a fixed "service rate", the queue length as a function of "request rate" grows asymptotically to infinity at the point where the request rate = service rate. (this is strictly true for poisson arrivals of requests, but many random arrival processes cause the same behavior).

That is, trying to use up the full capacity of a router, link, etc. causes a queue to build to infinity. Since buffers are only finite, this will cause dropped packets, and long latencies.

The solution is to avoid behavior that fills the queues. The KEY IDEA is that the ONLY reason that queues should ever be a "good thing" is if there are random gaps on the outgoing link that could be filled if there were elements in the queue. This gives better throughput, but longer latency. Thus there is a REAL tradeoff – throughput gets better only when latency gets long – a decreasing returns situation. In most cases, having an average queue length of *one* is the best state for a bottleneck router to be in. The observation you see is that the modem/router does not complain until a HUGE queue backs up, and then it drops packets.

Two proposals have been made in IETF congestion control groups to fix this: RED (random early drops) and ECN (early congestion notification). Sally Floyd and Van Jacobsen showed how they work with thorough analysis.

TCP stacks that support ECN are available, but they are not turned on in most cases by default. RED does not require any modification of endpoints, but does require router support. You can fix this by implementing RED in your router today.

There is some interesting background as to why router vendors are not eager to do either ECN or RED. In general, router vendors get measured on *throughput* not on latency. Thus, in "bake offs" such as those sponsored by folks like the computer press in reviews, a system that implemented ECN or RED would *lose* by a few percent in comparative benchmarks.

The media (George – this means you) could make a difference by rating routers (home routers) on latency in overload cases. A linux PC based router implementing ECN and RED could be used
as a benchmark. This would move the industry to helping with latency, rather than meaningless hot-rod-engine-revving comparisons.

"It’s not the job of the application to queue the packets – thats normally the job of the edge device as its only the edge device that has knowledge of all traffic from all applications and clients on the LAN sending out to the WAN."

And how many home users have good QoS routers or know how to configure QoS? I would submit that it’s lower than a few percent. That being the case, there is a real market out there where people are so fed up with bad house mates that they want to take a baseball bat to their roommate’s computer. What do we do about this mass market? Tell them to buy new and expensive router gear and/or learn about poorly documented and unfriendly Linux projects and learn how to be a network engineer?

BitTorrent or P2P applications are a very competitive field. The question is whether there is a demand for a network latency friendly P2P client or not and I would suggest there is a huge demand.

David Reed says: "There is some interesting background as to why router vendors are not eager to do either ECN or RED. In general, router vendors get measured on *throughput* not on latency. Thus, in "bake offs" such as those sponsored by folks like the computer press in reviews, a system that implemented ECN or RED would *lose* by a few percent in comparative benchmarks.

The media (George – this means you) could make a difference by rating routers (home routers) on latency in overload cases. A linux PC based router implementing ECN and RED could be used
as a benchmark. This would move the industry to helping with latency, rather than meaningless hot-rod-engine-revving comparisons."

I agree with you David. This would be a much better way to benchmark.

I see there’s a lot of discussion on this already, but i thought i’d add my 2c anyway.

Using OpenWRT w/ X-Wrt admin interface did wonders for HTTP and Skype latency for me, and was very easy to set up. Here’s a screenshot: http://wiki.x-wrt.org/index.php/Image:Wrp_network-qos.png

Just make sure you limit the bandwidth to a value below the actual speed so that the queue on the DSLAM never fills up.

I stopped reading when I got to "Unfortunately, these types of QoS services may never see the light of day if poorly conceived Net Neutrality legislation gets passed that ban the sale of packet prioritization." By that time I had already come to the conclusion that you do not understand the technical details behind your arguments, and that statement convinced me that you don’t understand what Network Neutrality is about either. This quote from the Net Neutrality bill currently in the House of Commons here in Canada does a very good job of summarizing what it is.

"Network operators shall not engage in network management practices that favour, degrade or prioritize any content, application or service transmitted over a broadband network based on their source, ownership or destination."

Notice that it does NOT attempt to unilaterally ban all network management – in fact it has exceptions specifically to allow prioritization of packets for things like VOIP, IPTV, etc. (it does not list every exception, so that future latency-sensitive protocols may also be prioritized).

With your anti-net-neutrality point of view, I can’t help but think you’re in bed with the big telecom companies somehow. Shame that you’re fattening your own wallet by giving out bad advice to your readers.

I have a Linux based router. Check out http://ipcop.org/, It has an easy traffic shaper tool to help prioritize traffic.

You don’t need much speed to route and prioritize . I’m running my router on a 233Mhz and 64mb of RAM.

I’ve used IPCop, but haven’t tried the QoS feature in it yet. I may have to dig that box out again to test it. The problem is that when most people talk about a particular QoS solution, have they actually done a detailed quantitative analysis on the before and after?

Rob says: "I stopped reading when I got to "Unfortunately, these types of QoS services may never see the light of day if poorly conceived Net Neutrality legislation gets passed that ban the sale of packet prioritization." By that time I had already come to the conclusion that you do not understand the technical details behind your arguments, and that statement convinced me that you don’t understand what Network Neutrality is about either."

Rob, I think you stopped reading much sooner than this. Sounds like you stopped reading before you actually read the Net Neutrality legislation. So let me make it easy for you, I’ll give you the actual text right here.

Markey proposal (2006):
SECTION 201. NETWORK NEUTRALITY.
(b) IN GENERAL.-Each broadband network provider has the duty-

(3) if the provider prioritizes or offers enhanced quality of service to data of a particular type, to prioritize or offer enhanced quality of service to all data of that type (regardless of the origin of such data) without imposing a surcharge or other consideration for such prioritization or enhanced quality of service;

Snowe-Dorgan proposal (2006):
(5) only prioritize content, applications, or services accessed by a user that is made available via the Internet within the network of such broadband service provider based on the type of content, applications, or services and the level of service purchased by the user, without charge for such prioritization;

When I said "ban the sale of packet prioritization", I said it based on what the facts and what the actual legislation says. So Rob, try and read a little more than you flame out of sheer ignorance.

Rob says: ""Network operators shall not engage in network management practices that favour, degrade or prioritize any content, application or service transmitted over a broadband network based on their source, ownership or destination."

Notice that it does NOT attempt to unilaterally ban all network management – in fact it has exceptions specifically to allow prioritization of packets for things like VOIP, IPTV, etc. (it does not list every exception, so that future latency-sensitive protocols may also be prioritized)."

Um Rob, did you notice that YOUR OWN cited text says that you can’t prioritize applications? It’s also interesting that you claim their are exceptions for "VoIP or IPTV, etc" when there is no such language and you fail to cite any actual text. You are straight up misleading the public on the legislation when you claim these exceptions.

The only exception in some of those Net Neutrality bills are for 911 emergency services. But how does the ISP determine that you’re calling 911? Even "DPI" Deep Packet Inspection doesn’t go as deep as the application layer to figure out what phone number you’re dialing. Now you want the Government to mandate that the ISP dig deeper in to your packets to determine what phone number you’re dialing before you get to prioritize the VoIP traffic?

No Rob, you failed miserably.

BT can be a pain in the rear end but its all we got so we just gotta deal with it. Either that or go back to actually buying CDs and games and nobody wants that now do they? LOL

JT
http://www.Ultimate-Anonymity.com

I had high latency while bit torrent was running. So much so that I basically couldn’t even browse the web. It helped to throttle my upload to almost nothing, but it seemed pretty ridiculous for not even coming close to my potential bandwidth. I tried changing settings on my home router and my torrent client, upping the buffer sizes in my os and the max connection limit. Nothing really had an impact, until I swapped out my home router for an old box running linux setup as a router with iptables. I can now just about max my connection speed with torrents, and have an increase of about ~10ms latency pinging various sites. I can browse the web and even play games with torrents going with no noticeable latency problems. Sorry, I don’t use VOIP, so I can’t speak to that.

QoS…. duh

What about TCP vs UDP issues? This might simply be a matter of changing your torrent client over to TCP so that it isn’t clogging up the channel with spastic packets. This may reduce your roommates download rates a little, but it should decrease the flooding that’s probably causing your latency.

I didn’t read this anywhere in replies or in your article yet, but you do know that P2P traffic is not the same at HTTPD traffic? You do realize that P2P connection number in the hundreds, that stay open, where httpd traffic is "socket open/ socket send / socket close"..

It’s not the traffic that is killing you alone, it’s the fact that your "home" router cannot handle hunderds of open and concurrent connections at a time..

Lession of the day… get a Cisco PIX or better hardware for routing and you wont have this issue.

I looked into it, IPCOP uses something called WonderShaper. I couldn’t find any analysis/benchmarks using it. I remember doing a half-ass test when I first enabled it and notice a huge improvement in my uploading, but I didn’t test latency issues.

link: http://lartc.org/wondershaper/

So you’re against Net Neutrality? You want others to price you out of home access? You don’t need the provider to prioritize the traffic you are sending it. How about you don’t step on your own traffic via one hop QoS at your egress point? This and TCP are 99% of the puzzle. If your VoIP sounded great before and you added P2P, guess what? You just need to make sure the VoIP is prioritized at your node, the whole internet does not need to be divided up. That’s what leased services are for, and you can contract out what traffic you want prioritized and exactly how.

Informative overall, but please don’t knock net neutrality with this simplistic an argument. It won’t even help you, so please take that off your page.

Also, while you’re editing this, you spelled their incorrectly. It should be "there" -> "So despite the fact that *their* is plenty of remaining bandwidth"

Props to the author for trying to figure out a way to fix this. People may not want to hear this, but if you find a solution for this problem, market it. Just remember to sell it cheap or people will reject it. Thanks for your work, I appreciate the time you have put into this!

Easy answer. One connection vs multiple connections. While the download is the same, the network card works harder and has more to manage for the same effect.

I more or less agree with Prof. Reed regarding RED and ECN. Microsoft has finally implemented ECN in Vista, but has it turned off by default because they fear old-timey Internet routers will choke on packets with ECN code-points set to non-zero values. ECN uses the two bits in the old TOS field that aren’t used by DSCP. Home router companies can reverse Microsoft’s recalcitrance by doing ECN in their NATs, fortunately. This illustrates the trouble with End-to-End architecture, of course: it means, in effect, that Microsoft controls the Internet (because it clearly controls the end points.) But middleware comes to the rescue, and allows consumers to have some choice.

Regarding RED, it’s my understanding that routers do tend to implement it, since it avoids the cycling problems that are the inevitable result of Jacobson’s Kludge. They also look inside packets in order to avoid discarding UDP and such things as TCP ACKs, because the first don’t care about Jacobson and discarding the second increases congestion.

The Intelligent Network is looking better all the time.

The problem with P4P is that it still allows content providers to set up servers on ISPs’ networks without permission and without compensation. This is simply a nonstarter for any ISP. As for the comment that this article is "anti-neutrality propaganda:" that’s just silly. What George has ably demonstrated is that it is BitTorrent that is non-neutral, and that throttling or blocking it is an effort to RESTORE neutrality, not to harm it.

Finally, as for David Reed’s comment above: I think that it’s very interesting that he suggests ECN as a solution, because ECN violates the "end-to-endian" principle. (It requires intelligence in the middle.) But I’m for anything that intelligently deals with congestion. The harder problem is the economics: Content providers wanting to take ISPs’ bandwidth without paying, and users wanting every last bit they can hog.

I looked into it, IPCOP uses something called WonderShaper. I couldn’t find any analysis/benchmarks using it. I remember doing a half-ass test when I first enabled it and notice a huge improvement in my uploading, but I didn’t test latency issues.

link: http://lartc.org/wondershaper/

DLSAM connectivity is a Layer 1 OSI reference model technology. You cannot apply Layer 3 OSI QoS markings to a Layer 1 technology. Layer 1 (physical) is terminated at the DSLAM, Layer 2 is carried to the aggregation router, and out to the internet on a provider router.

The DSL connection, depending on the type of connection, may already be doing some of the proposed packet jumbling. If the connection is PPP, the network is perhaps already chopping up all the packets into neat ATM cells instead of packets for physical transmission in 53 byte cells, (ideal for QoS already!)

Article had great intent, but some of the information is wrong.

[Moderator response from George Ou]
First of all, the DSLAM is a Layer 2 device
Second, DSLAMs do support QoS technologies like DiffServ and priority queues
Third, ATM cell sizes used in DSL doesn’t change the order of the packets at layer 3

John says "So you’re against Net Neutrality? You want others to price you out of home access?"

John, before you make such simplistic and kneejerk comments, read what I actually say about net neutrality.

A rational debate on Net Neutrality | George Ou | ZDNet.com
http://blogs.zdnet.com/Ou/?p=512

Revived Net Neutrality bill cripples Internet for real-time applications
http://www.formortals.com/Home/tabid/36/EntryID/34/Default.aspx

John says: "You don’t need the provider to prioritize the traffic you are sending it. How about you don’t step on your own traffic via one hop QoS at your egress point?"

Oh you’re a genius John. Let’s stop BitTorrent usage altogether while we use VoIP or online gaming. Or lets just take a baseball bat to our roommate or brother’s computer. Or let’s just buy a second DSL line. No John, we want the Internet to work for everyone simultaneously and we want all the applications to coexist in peace and every applications flow as quickly or problem free as possible. This is why we have traffic engineering.

I agree with ruggy and noname — I think the author’s understanding of the issue is weak. I also agree with leongmz — most people who set up router-based QoS and don’t see any difference don’t have their settings right.

For most router-based QoS schemes, you want to set your bandwidth at 10% less than your actual (not advertised) speed. Author, if you can’t get DD-WRT or some similar software to fix your problem, you’re doing it wrong. I can have two people torrenting and a skype call will never skip a beat. Your admission that software could fix the problem but that you weren’t satisfied with that solution betrays your ultimate purpose — to turn people against network neutrality.

I agree with you that any bill that would block packet prioritization carte blanche is a bad one, but the core tenet of network neutrality — that networks shouldn’t discriminate against traffic because of its source or destination — is a good one. Just because some members of congress can craft a bad bill out of a good idea doesn’t change anything and shouldn’t surprise anyone.

Back to the article… the reason one HTTP download doesn’t have the same negative affect on latency as bittorrent is not because it’s using smaller packets. A single TCP connection — with the built-in flow-control of TCP — will throttle itself to leave room for other traffic. Multiple connections constantly being negotiated, started, and stopped will lead to spikes in latency regardless of the application creating them. The solution is to implement multiple priority queues for outgoing traffic on the gateway router. No ISP QoS or revamping of the bittorrent protocol is required.

Not capping your upload speed is the biggest reason others on the internal network experience problems.

[Moderator note from George Ou] Try and at least look at the pretty little graphs next time.

Maybe BitTorrent Inc. should start certifying routers with good QoS support. As we can see from this thread, some of them work better than others.

BTW, to all the people suggesting Linux/BSD: This site is called Technology FOR MORTALS. I’m a Linux hacker and I don’t even use a Linux router.

George, great post! But I have a question. I’ve observed an effect on my cable modem that when I do a bandwidth unrestricted upload (like your ftp upload, but usually I’m using ssh), ping times can go through the roof, much worse than in the tests you ran. This seems to be because of an issue you have not discussed: many cable modems have large (I would say vastly overprovisioned) uplink queues, and most tcp congestion control (Reno) only backs off when packets are dropped. As a result, ping times can get enormous because the queues have much much more than the ideal one packet mentioned by David Reed, and so the ICMP packets wait a long time behind queued tcp packets. However, your test did not exhibit this phenomenon. Do you know why? I would speculate that either your DSL modem is not overprovisioned with buffers, or you’re using a more modern tcp congestion control algorithm.

Wes, I don’t think that telling the customer to buy new hardware or software is ever a good solution. VoIP vendors tried to get the network changed for years with little success. Skype came along and built an application with non-conventional approaches and made their VoIP software "just work".

The vast majority of customers won’t buy the high-end gear and they don’t understand traffic engineering. The real opportunity here is for a P2P client vendor to write their software in such a way to be friendlier to the network rather than asking the network to make changes for the software.

Again, this isn’t to say that I’m against network-based solutions at all. I just think that there is room for an application-based solution.

Wes, I don’t think that telling the customer to buy new hardware or software is ever a good solution. VoIP vendors tried to get the network changed for years with little success. Skype came along and built an application with non-conventional approaches and made their VoIP software "just work".

The vast majority of customers won’t buy the high-end gear and they don’t understand traffic engineering. The real opportunity here is for a P2P client vendor to write their software in such a way to be friendlier to the network rather than asking the network to make changes for the software.

Again, this isn’t to say that I’m against network-based solutions at all. I just think that there is room for an application-based solution.

Really now? Straight out of Cisco’s CCNP learning exam material why does it say that DSLAMs are a Layer 1 technology? You can feel free to argue with all the CCIEs that wrote the book if you’d like…..but again you are completely wrong.

TOS/COS bits are the only thing you have to mark a packet with at Layer 2. You can also fragment and interleave frames at layer 2. If you cared to listen, I’d explain that serialization delay can cause your VoIP packets to be dropped before being sent if you have giant data packets plugging your lines…but I think I am wasting my time explaining reality.

A DSLAM is pretty much like an Ethernet Switch operating at layer 2 when we’re talking about it in the general context. Like the Ethernet Switch which supports multiple copper CAT-5 ports, the DSLAM connects and switches multiple copper phone-line ports. Ethernet switches support QoS and so do DSLAMs. Most newer switches have routing support but that’s beyond the classical definition of a switch. 802.11 Access Points for example are also layer 2 devices in general.

Sure, there are layer 1 technologies in a Switch and DSLAM, but they at the very least go up to layer 2. A device that operates purely at layer 1 for example is an optical transceiver.

And as a response to those people questioning my technical knowledge, I built and designed very large network for Fortune 100 companies.

Our ISP uses GRED for most traffic management, because it interacts well with Van Jacobsen’s awful hack (er, I mean his AIMD algorithm). However, any variant of RED drives UDP-based VoIP crazy as you reach the limit, so we bypass GRED for packets that are clearly VoIP.

Good research. This is old news to me, although more from a casual measurement perspective. I solved the latency issue by using TorrentFlux on a dedicated server in a colo facility and just downloading files as they complete with an rsync script.

"Already did that on DD-WRT link. Didn’t seem to work."

You should get it to prioritize your gaming and other latency sensitive packets over everything else (in addition to the uplink rate limit mentioned earlier). It will work, you will not have (as you say) 3 torrent packets in front of your game packet at the modem. The router will be assuming a slow uplink, so packets will be queued up at the _router_ not the modem. And if configured correctly when your game packet arrives while the 3 torrent packets are queued up at the _router_ the router will send your game packet out _first_.

As long as the router is the narrowest straw, there will not be a long queue of packets at the modem (unless there is a problem with the uplink).

"Why assume that? Why assume that only a network based solution can fix this? I can certain agree that a good network based QoS solution can fix this, but why must that be the only way?"

Because your stated problem scenario was multiple users. It is easier to fix it at a single device than to fix it on multiple different users using multiple and disparate applications. If your scenario is actually single user then the solution is the trivial one that the semi literate here keep suggesting to you .

Even if you manage to convince Bittorent et all to change the way they do things, and manage to get ALL the users (behind the modem) to use the same client and also configure them "properly" (rate limit as per the uplink and max number of users), the users’ bittorent clients won’t be aware of each other. Every so often they will end up sending their packets at about the same time, even though they are putting gaps in them, and those packets will end up queued at the modem in front of your gaming packets.

I doubt it will be easier to get all P2P clients behind the modem to cooperate and synchronize their packet sending than to fix it at the network device end. If you want efficiency you would even need the clients to rate limit depending on how many active clients there are – otherwise your torrent uploads will be really slow even if you are the only user online.

Better to fix it the proper way .

As for network neutrality (or not). I think one should aim for fairness and truth. If people don’t know what’s fair and true, then they should not be in charge of maintaining it. Seems there’s so much greed, deceit and deception involved, so good luck to everyone.

————————————–
What I am talking about is that YOU the user should have the right to tell your ISP that you want a particular source or traffic type to be prioritized over other traffic for throughput and/or low-latency. T

"So with that said, why would Google oppose this them offering (for free or fee) QOS services to the the subscriber?"

You’d have to ask Google for their exact motivations. When I ask them in public forums and debates, Google pretty much back away from it just like Tim Wu refuses to talk about the actual legislation. Then you have guys like Rob who simply lie about what Net Neutrality legislation is claiming that there are exceptions for IPTV and VoIP traffic when there is no such thing. The Net Neutrality advocates don’t want to debate on the technical merits of their legislation because they know they can’t defend it. So their strategy is to represent the issue as a free speech issue and never debate the actual technology.

Google wants that prioritization service to be provided for everyone or no one, which effectively means no one. When you prioritize everyone, you are in effect prioritizing no one. Even if certain types of application prioritization is allowed provided that it’s given to every customer, that still means that those who don’t need prioritization (don’t game or VoIP) would subsidize the bundled service for those who do need the prioritization.

Google is getting in to the video delivery business and they want every advantage they can get. If that means they can kill a competitor like AT&T or any FTTN IPTV provider by lobbying, they will do it and that’s precisely what they’re doing. Google’s Vint Cerf pretty much tells AT&T that they should get out of the video business. But the reality is that you can’t compare Video on Demand services which can be buffered to IPTV services which have to be real-time. The FTTN provider’s only incentive to spend billions of dollars on FTTN infrastructure is to be able to compete against Cable TV and Satellite TV.

Google can talk about how wonderful a big dumb pipe is but they won’t spend a dime building it. Google gets to monetize their own technology that they invested in and they data mine people’s email accounts making them one of the richest corporations in the world and they’ll fight legislation that regulates them. Their CEOs pay lip service to symbolic hybrid cars gladly while they fly around in the world’s biggest private jet with king sized beds and they talk about doing no evil while they cooperate with the Chinese government. Here’s an example of what I’m talking about.

http://online.wsj.com/public/article/SB115222788536400097-i72SXBBTMX_EPvtfDIn9uNjtiss_20070707.html
“Mr. Jennings says Messrs. Brin and Page "had some strange requests," including hammocks hung from the ceiling of the plane. At one point he witnessed a dispute between them over whether Mr. Brin should have a "California king" size bed, he says. Mr. Jennings says Mr. Schmidt stepped in to resolve that by saying, "Sergey, you can have whatever bed you want in your room; Larry, you can have whatever kind of bed you want in your bedroom. Let’s move on." Mr. Jennings says Mr. Schmidt at another point told him, "It’s a party airplane."”

I’m no gray-bearded networking expert, but the whole idea of using small and evenly-spaced packets to reduce jitter sounds a lot like reinventing ATM’s cells and adding time-division multiplexing. How well could this really work with many (maybe hundreds) of TCP connections? Suddenly you either need to perfectly sync all your peer activity, or put up with massively reduced bandwidth. And you can forget managing downstream bandwidth this way, there is no way latencies will stay consistent enough.

This also seems like a gnarly layering violation. Since when is it the job of the application to micro-manage the TCP stack? Microsoft did something similar by allowing its media layer to throttle the networking layer (to keep HD content playback predictable by way of reducing interrupt latency, IIRC), and I think everyone remembers the reaction when some Gigabit users realized they couldn’t even use 30% of the link…

QoS could be much easier for the average user to setup, I agree. However, the state of the art is pretty well advanced and works well for many. Just ask any university who can cram thousands and thousands of individual users onto an undersized link, and keep latencies low enough for VoIP, gaming, etc. (Sustained download speeds are awful, of course, but the sky doesn’t fall.)

Maybe I just don’t get it…

Nick, ATM QoS works within the context of ATM; it does not work in the context of running IP over ATM. Multiple ATM cells make up a single IP packet and you can’t just go reshuffling ATM packets to see an effect on IP flows. You need to intelligently shuffle the IP packets either at the network end or you try to engineer the application to spit out an even flow of periodic traffic.

Universities have hundreds of megabits per second and they do manage their flows with very expensive flow-management gear and/or they limit BitTorrent traffic. Their hundred megabit links are much better suited for the students hundred Mbps LAN clients and the queueing dynamics is much different.

Try setting up QoS on both WAN and LAN ports on your “router” device this has definetly fixed the issue for me. I am using the open source firmware for a linksys wrt54g called dd-wrt. Prioritizing http, xboxlive and counterstrike ports has fixed the issue for me, ive done hours of testing and the gameplay and web browsing usage has dramatically changed over non QoS prioritization. Great article, i agree this should be fixed at the application layer not at the networking layer.