Better Bandwidth Utilization

jtorin writes "Daniel Hartmeier (of OpenBSD fame) has written a short but interesting article which explains how to better utilize available bandwidth. In short it gives priority to TCP ACKs over other types of traffic, thereby making it possible to max both upload and download bandwidth simultaenously. Be sure to check ot the nice graphs! Also note the article on OpenBSD Journal. OpenBSD 3.3 beta is now stable enough for daily use, so why not download a snapshot from one of the mirrors and try it out?"

Comments

This will be of most use to ...

[adzoox]

I think this may be of most use to two way satellite connections and maybe to service providers - however; I don't see how one can get much faster than a cable modem or DSL connection - the internet comes through at the same bandwidth and speed whether I am wireless or T1 or cable modem/DSL - this is the majority of network traffic nowadays

Corporate networks are already optimized under 100 or gigabit ethernet with Cisco routers which automatically handle collisions and error corrections.

Very nice solution!

[Anonymous Coward]

Of course, the effectiveness of this technology depends on both networks which handle the ACK to have the service implemented.

Still, a very simple and effective solution to an age-old problem. I like.

Note the article is all about low bandwidth setups

[jj_johny]

Daniel has done some good work in micromanaging the available bandwidth to make sure that ACKs get through to minimize retransmits due to drops as well as other causes. When you look at low bandwidth links the time in queue and to transmit can be much bigger than the near instananious transmission times that you expect on high capacity lines.

A little off topic but I always find it interesting that people with hicap gear (Foundry, Cisco, etc.) are always talking about QOS when it really only makes sense most times on low bandwidth lines. So his work is really important when you look at where it is in scheme of things - out at the end users line.

Better Bandwidth Utilization...

[Anonymous Coward]

Less pr0n and warez?

Broadband implications

[Arethan]

Seems to me that this could really help broadband providers supply a better service if this was implemented in the firmware of the modems and the headend equipment.

Then again, since when have most broadband providers really ever cared about supplying good speeds when the user maxes out the outrageously capped upstream...

Slashdotting and DOS

[Anonymous Coward]

True enough.

rule 2: Have a backup plan in case someone sends you a bunch of ACK ACK ACK ACK ACK ACK to cause a denial of service.

Re:Linux solution

[grub]

Who needs BSD?

People that love UNIX. The Finnish hack is for people that hate Microsoft.

Re:We figured this before

[Anonymous Coward]

we had no idea how to actually do it on a windows based machine, anyone with a idea?

run openbsd inside vmware on the windows machine, have it queue your packets as described in the article.

Working Link

[bill_mcgonigle]

Honest, I'm not Karma-whoring, it just ticks me off.

link

Re:Uh, no, I don't think so

[anthony_dipierro]

If you're only sending a single UDP packet, sure. But if you're exceeding the end to end bandwidth of the network, then clearly packets need to either be queued or dropped. If you're exceeding the maximum bandwidth by more than just a little, then you're going to fill up the buffers, and packets will get dropped.

Without seeing the quote I'd only be speculating on what the textbook was talking about. Could be LANs, but it could be that they were talking about single UDP packets, rather than pounding a few megs of HTML and images all at once. Or maybe the quote was that UDP packets rarely get dropped for reasons other than congestion. Perhaps they could have been talking about packets that are mangled en route? That is something which could happen in theory but in reality rarely (if ever) happens.

Of course, maybe I'm just wrong. It does happen from time to time :).