Bandwidth Hog (quick concept draft)

Post date: Mar 17, 2013 4:34:06 PM

Just some random thoughts about bandwidth hogging protocol. Actually this kind of app would have been most useful back in early days when international connections were totally jammed.

TL;DR; Main goal is to as aggressively as possible to utilize available bandwidth. Including robbing it from other applications using TCP.

Hotel Wifi, great Internet connectivity is something you keep as granted, until you don't have it. Sigh! Then it's absolutely horrible.

ProtoObfs with Bandwidth Hog UDP module. Large streaming window, fast retransmits, absolutely own quick protocol which aggressively resends data, in case of communication failures. Main connection timeout long, data packet level timeout very short. Use fixed packet size for speed!

Can be used to tunnel TCP streams, but I would better suit for file transfers, because chatty protocols which do not buffer enough data, could still be slow.

We could also allow simple NAT hole punching etc. Then protocol could be used even in situations where both ends are behind NAT etc.

Questions, how to correctly tune protocol so that packet loss isn't a problem, how to correctly set packet size, max rate, etc.

Skype / UDP worked surprisingly well, but TCP streams were extremely hopeless and dropping connectivity (due sub protocol timeouts).

Sending packet already several times even before acknowledgment, base rate, max rate, loss estimation etc. Different more aggressive modes. Auto rate based on loss etc.

Bandwidth Hog, that's the name. It doesn't add bandwidth, it doesn't work more efficiently, but it hogs bandwidth from other fair protocols by being way more aggressive than traditional TCP options.

Well, it seems that I don't have time to write article about this, nor I have time to write implementation. But this would have been fun. I have been thinking about this option from 90's, because back then network connectivity was usually much worse and using protocol like this would have given proportionally bigger share of bandwidth.