> > > > > Queuing doesn't make sense inbound anyway; once you've received the > > > packet, it has already consumed your bandwidth, and thus queuing won't > > > change anything. > > > > queueing could delay ACK reply being sent and then whole connection > > would get throttled. > > > > it works really fine with freebsd's ipfw, i had no problems regarding > > queueing incoming packets. > > > > What you propose can be compared to repetitively telling a ADHD child to > behave, or try to ignore him. Either way, your fucked. If he does listen > to you however, he probably don't have ADHD. Good for you. ;) > > As long as you don't control the the remote host, or a router close to > it, you have no "real" control over the bandwidth throttling from that > host to your gateway(or whatever).
be careful to distinguish between two situations. 1) maliciously sent incoming data meant to flood your connection 2) non-malicious incoming data that is part of a stream destined for a LAN host behind the firewall. inbound queueing has no jurisdiction over situation 1, but it *does* create the potential for usefulness in situation 2. if you are throttling the rate at which data is forwarded back to a host behind the firewall, you can provide benefit to yourself; i do this to make it very unlikely that LAN hosts consume my entire downstream ( from ISP ) bandwidth capacity. if i'm eating all my download, my latency goes from ~11ms between me and my "default gateway" to about 400-600ms. -- jared [ openbsd 3.8 GENERIC ( oct 15 ) // i386 ]
