[ previous ] [ next ] [ threads ]
 
 From:  David W. Hess <dwhess at banishedsouls dot org>
 To:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Re: [m0n0wall] Inbound (downloaded) traffic is not being shaped at all
 Date:  Tue, 30 Jan 2007 00:37:27 -0600
Sounds like you did much the same research I did back when I was learning the
details of ALTQ but your summery is better then anything I produced.  I
originally switched to pfsense to take advantage of the ability of ALTQ to
borrow bandwidth from alternate queues but it supports ECN which I usually try
to use.  As you posted, ALTQ uses ECN to adjust traffic rates before packets
would normally need to be dropped for traditional flow control and then drops
packets if that fails.  Comparing m0n0wall to pfsense when limiting incoming
traffic showed the best performance with pfsense closely followed by monowall
followed by having no incoming traffic shaping at all in which case my VoIP
connections were completely useless.

I never tried controlling the outbound ACKs to throttle incoming traffic.

The biggest problem I currently have is that ALTQ under pfsense tends to put a
fraction of my incoming bittorrent traffic into the default queue instead of the
bittorrent queue.  I suspect a rules generation issue but have not tracked it
down yet.

On Mon, 29 Jan 2007 17:20:32 -0700, "Michael" <zlinda1002 at cox dot net> wrote:

>I think I found the answer why inbound transmissions cannot be regulated.
>This write up would be thanks to Fred Wright. I believe the article states
>that the only efficient way to do it would be ECN which is not impletmented
>and the only option to control inbound tcp with m0n0wall is by dropping
>packets (as long as it's controlled) I have stuck with what Chris suggested;
>using the outbound ack to control the inbound. Any suggestions on what I can
>do to limit ftp, bittorren, etc so that voIP maintains highest priority.
>
>The TCP window was designed for *application* flow control, not
>network flow control.
>
>1) TCP doesn't provide reliable delivery of control information, such as
>window updates.  In the original RFC793 version, the *only* means of
>restarting transmission previously blocked by a closed window was
>timeout-based retransmission of the window probe.  Most modern TCP
>implementations send one "free ACK" when the window opens, but if that ACK
>gets lost for any reason it falls back to timeouts.  Thus, the performance
>of receiver-limited TCP tends to be very fragile on lossy networks.
>
>2) The window specifies an *amount* of data, not a rate.  In order to
>translate between the two, it's necessary for the receiver to know the
>round-trip time of the path (in effect, the window size limits the
>delay-bandwidth product, not the bandwidth per se).  But the receiver is
>in no position to determine that in the absence of "ACKs of ACKs".
>
>3) The receiver is never allowed to "reduce" the window, in the sense of
>moving the window limit backward in the stream (the *size* of the window
>can decrease as the ACK point moves forward, but the *sum* can never
>decrease).  This puts a greater constraint on the throttling possibilities
>than one would like.
>
>TCP's congestion control (that regulates its send rate) also suffers from
>the "too little information" problem like #2, but the other way - i.e. it
>knows the RTT (sort of) but not the bandwidth.  It "probes" the bandwitdh
>by continuing to increase the congestion window until it sees packet loss,
>whereupon it reduces it.  At best this causes the rate to oscillate with
>the *peaks* being the theoretical maximum, and hence the average is always
>lower.
>
>Note the stability problem:  TCP's only measure of RTT comes from time
>from send to ACK, and its only throttle is by limiting the amount of
>outstanding data.  If it doesn't increase the window when it's not
>utilizing all the bandwidth, it will *never* utilize all the
>bandwidth.  But if it increases the window after the bandwidth is
>saturated, it just increases the queue length which increases the measured
>RTT, which increases the delay-bandwidth product, which increases the
>window needed to get the *same* bandwidth, etc., etc.  There is research
>going on into rate-limited sending rather than window-limited sending, but
>nothing in "production" AFAIK.
>
>There are a few ways a router can tell a sending TCP to throttle back:
>
>1) Drop packets.  This is the most common method, and not *too* bad if
>done sparingly and *before* the choke point.  Doing it after the choke
>point works, but wastes bandwidth where it's scarce.
>
>2) ICMP Source Quench.  For some reason this never really caught on,
>though it could provide feedback before getting to the point of dropping
>packets.  I think this was partly due to the lack of standards for exactly
>when to send them and what to do when receiving them.
>
>3) Early Congestion Notification (ECN).  This is probably the best
>approach in principle, but it's quite new and not widely supported.  The
>idea is that a router can tweak flags in a packet to say that congestion
>is becoming an issue, and this is reflected back to the sender along with
>the ACK.  Properly supported, transmission could be throttled *before* it
>becomes necessary to drop packets, and there's no problem doing this
>downstream of the choke point.
>
>-----Original Message-----
>From: Michael [mailto:zlinda1002 at cox dot net] 
>Sent: Monday, January 29, 2007 4:10 PM
>To: m0n0wall at lists dot m0n0 dot ch
>Subject: RE: [m0n0wall] Inbound (downloaded) traffic is not being shaped at
>all
>
>So pretty much I might as well remove all the inbound rules set to wan since
>they aren't doing anything. 
>I have ack set to high priority 0-128 now, below that small packets, ah,
>esp, gre, dns
>
>-----Original Message-----
>From: Chris Buechler [mailto:cbuechler at gmail dot com] 
>Sent: Monday, January 29, 2007 2:48 PM
>Cc: m0n0wall at lists dot m0n0 dot ch
>Subject: Re: [m0n0wall] Inbound (downloaded) traffic is not being shaped at
>all
>
>On 1/28/07, Michael Brown <knightmb at knightmb dot dyndns dot org> wrote:
>> Well, I think there is a mis-understanding here. You can traffic shape
>> inbound traffic, but it's not possible to make it "instant".  When you
>> traffic shape outbound traffic, you already know your "limits" and
>> m0n0wall responds to this accordingly.  With inbound traffic, even when
>> you know your "limits" inbound, you can't account for limits that exist
>> outside of your connection.
>>
>
>This is correct, but much more detailed than I had time to get into
>(or have time to comment much on now). Shaping incoming traffic from
>the Internet is complex. You don't shape the traffic that's coming in
>on the WAN because that's not helping you any - you need to shape
>outbound ACK's appropriately to have any sort of control on incoming
>traffic. The easiest way to limit your NNTP traffic is to use a NNTP
>client that allows you to limit its speed.
>
>-Chris
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>
>-- 
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.5.432 / Virus Database: 268.17.14/658 - Release Date: 1/29/2007
>2:49 PM
> 
>
>-- 
>No virus found in this outgoing message.
>Checked by AVG Free Edition.
>Version: 7.5.432 / Virus Database: 268.17.14/658 - Release Date: 1/29/2007
>2:49 PM
> 
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>
>
>-- 
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.5.432 / Virus Database: 268.17.14/658 - Release Date: 1/29/2007
>2:49 PM
>