TarPit

ec2-3-140-188-16.us-east-2.compute.amazonaws.com | ToothyWiki | RecentChanges | Login | Webcomic

In computing terms, a tarpit is something that is deliberately designed big and sticky that you get caught in and drown. Rather than all the other things that just end up that way.

Rather than going off on a predictable rant about the quality of software, I will instead ask:
Does someone have a network layer that will allow me to throttle outgoing and incoming connections arbitarily? Preferably for both win32 and 'nix.
Iptables claims to be able to do it, but apart from being 'nix only it isn't the easiest thing in the world to configure. (I just about managed to work out how to poke holes in it, that's about it.)

If iptables is the answer, can anyone point me at resources for using it that a naive google doesn't find? --Vitenka

There's a very terse overview at http://snafu.freedom.org/linux2.2/iproute-notes.html, and http://lartc.org/ seems to have quite a lot of useful stuff. I personally use iproute with the CBQ scheduler to ratelimit outgoing traffic to keep the latency down (cable modems tend to have ten-second queues, which is great for making a single outgoing connection go fast, but tragic for anything else). --Admiral

Well, I've not had a problem with outbound traffic. Pretty much everything I use is either low rate (IRC) has built in rate limiters (BitTorrent) or I want to use all remaining bandwidth (Apache WebServer) It's the incoming rate that I want to download. I know how TCP/IP works (well, ok, few people indeed understamd the intricacies, but I can talk about NAK and window sizing) so I know that you can't throttle download speeds perfectly, but you can do a decent job and that's all I want right now. I'll look at those sites. Thank you. --Vitenka

: So, are you wanting to limit incoming to get around a large queue at your ISP? In any case, for Linux I would look at the "WonderShaper?" http://lartc.org/wondershaper/ - particularly the last few lines, which say:

Not quite. The main problem is that when my down is saturated, new requests can't get in. Which leads to retries or outright failures. At least I think that's what the problem is. --Vitenka

: Actually, that is a very common symptom of a large queue - the existing TCP connection will be very happy, because it has worked out that it is getting data in at a certain rate, with a certain fairly constant latency, and a certain percentage of packets dropped. When you try to establish another connection, it doesn't have all that information, and it will probably have retransmitted the setup packets several times before the first one even makes it through the queue, if it does at all. If you can move the queue from your ISP/modem into your computer, then you can control it properly (eg prioritise packets, etc). --Admiral

########## downlink #############
# slow downloads down to somewhat less than the real speed  to prevent 
# queuing at our ISP. Tune to see how high you can set it.
# ISPs tend to have *huge* queues to make sure big downloads are fast
#
# attach ingress policer:

tc qdisc add dev $DEV handle ffff: ingress

# filter *everything* to it (0.0.0.0/0), drop everything that's
# coming in too fast:

tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \ 
   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1

: That should limit the incoming data to ${DOWNLINK} on the device $DEV. I find that on my cable modem I get almost exactly the maximum theoretical download speed, while at the same time retaining full low-latency interactive response. --Admiral

CategoryMonster | CategoryPlace | HomePage? | WorkItOut? ;)