This one time, at band camp, Adam Nellemann said:

> Hi Joey,
>
> Just currious (always wanting to learn more about the shaper): Is there
> any particular reason why you are shaping on the LAN interface?  (I
> would have thought WAN would be the obvious choice, but..?)
>
> Adam.

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.

shaping ACK packets with heavy weight fixes both these problems.


This one time, at band camp, Eric Shorkey said:

> This one time, at band camp, I answered an email for Joey. ;)

cute.  i suppose it's time for a new reply lean-in.  it hasn't changed in
ages...

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

anyone have any thoughts on the matter?

jj