On Wed, May 27, 2009 at 12:02 PM, SJP Lists <sjp.li...@flashbsd.net> wrote:
> Thanks Lars and Johan, > > I was trying to highlight to irix that once traffic is received, it is > too late to alter the bandwidth it already used coming in. > > In other words, doing it on the incoming is pointless. Thus, as in > your examples, the logic behind shaping only on the outbound. You can always inform the other end that your window is smaller than it is (pf.conf(5) red/rio/ecn on the queue). Or, simply randomly drop some incoming packets for that protocol to force retransmission (see pf.conf(5) "probability" flag for a given line) which should cause the remote end renegotiate its link to you as unreliable, and retransmit. A probability of 5% would prevent inbound connections from fully saturating. > i.e.You can easily delay sending something you have, but you have > little to no control over the ingress traffic of a link where only the > local host you have control of. Bingo.
