[ previous ] [ next ] [ threads ]
 
 From:  "Michael" <zlinda1002 at cox dot net>
 To:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  RE: [m0n0wall] Inbound (downloaded) traffic is not being shaped at all
 Date:  Mon, 29 Jan 2007 17:20:32 -0700
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
 

-- 
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