Joey Morin wrote:

> as i mentioned, i didn't write the ruleset, but from what i understand the
> reason for shaping on the LAN side is two-fold:
> 
> 1) an un-shaped, saturated upstream link can seriously throttle DOWNSTREAM
>    connections.
> 
>    this is because many connection types (like HTTP) employ a scheme
>    whereby acknowledgement packets (ACK) are returned for each packet or
>    group of packets received.
> 
>    so, an HTTP server won't send you the next packet in your huge download
>    until it has received an ACK packet for it's last burst.
> 
>    if your upstream pipe is saturated due to an upload (such as with
>    bittorrnet), those ACK packets can't get through in a timely fashion,
>    and i becomes impossible to use your full downstream bandwitdh (at
>    least for connections that employ frequent ACKing.  UDP connections
>    such as those used by most video conferencing software should not be
>    affected).  this is especially true for asymetrical links such as most
>    cable and DSL services.
> 
> 
> 2) an upstream link saturated by other traffic (like a mail transfer,
>    upload, or bittorent process) leaves little room for small packets
>    generated by keystrokes in an SSH session, so you see some latency.
>    this is compounded by the fact that every keystroke packet solicits a
>    downstream ACK, followed by a downstream echo packet which requires a
>    responce with an upstream ACK packet.  with all of this to-ing and
>    fro-ing over a saturated link can produce a lot of latency.
> 

Uhm, I'm probably being a bit "thick" here, but could you elaborate on 
how shaping on LAN instead of WAN will make any difference to the 
above problems? (Since if it does, I will certainly want to change my 
shaper setup!)


> shaping ACK packets with heavy weight fixes both these problems.

I'm currently allowing (small) ACK's to go directly to my pipe, under 
the assumption that this will amount to an "effective weight" somewhat 
higher than sending them through a weight 100 queue, but perhaps this 
is all wrong? (If so, what then is the idea behind rules being capable 
of going straight to a pipe?)


>>You have to bind your shaper rules to an interface. It really doesn't
>>matter which so long as the traffic you wish to shape passes through
>>that interface at some point. Looks like Joey picked the lan interface.
>>That's really all there is to it.
> 
> i hadn't thought of it.  seems reasonable.  my sense is that with just two
> interfaces it wouldn't make any difference, as long as any restrictions
> included in a given rule take into account the directional nature of a
> given interface.  however, what if you have more than one interface?  and
> what about PPTP, IPSEC, Captive Portal, etc...?  wouldn't the choice of
> interface be important?

Huh, now I'm lost again, didn't you just argue that the interface DID 
matter, even with only two interfaces?!?


Adam.