Re: [LARTC] interesting expert problem - shaping over VPN

["lartc@manchotnetworks.net" <lartc@manchotnetworks.net>]

hi trevor,

On Fri, 2004-09-24 at 05:44, Trevor Cordes wrote:
> On 18 Sep, lartc@manchotnetworks.net wrote:
> > hi,
> > 
> > there was a thread on this recently -- please search the archives for
> > 
> > "traffic queueing and ipsec vpn"
> 
> Ya, I had seen that.  I just reread the thread and it doesn't really
> help me with my problem.  It's all conceptual with no specifics, and the
> concepts appear to agree with my knowledge and current configuration
> attempt.
> 
> The only thing that puzzles me a bit is this talk of INGRESS and EGRESS,
> which I don't recall being in the HOWTO's and I'm not really sure of
> what signifigance they are.
basically, ingress is more difficult to control and to granularly
regulate traffic as we have no control over what's coming in and in what
order. i have seen studies that indicate RED as an effective way of
handling ingress.
I just wish I could be sure that that really is the case as I feel like
> I'm real close to a solution.  The filtering is working great, passing
> packets into the proper QDISC.  It just doesn't appear to help the VoIP
> at all.
> 
> Of course, it doesn't help that there's that kernel panic bug in HTB
> into ipsec (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id\x130172)
> 
> Thanks for your help.
egress on the other hand is completely under your control as you select
in what order and with what speed packets are dequeued to the hardware.
in slowing packets to be dequeued, tcp's AIMD comes into play --
Additive Increase Multiplicative Decrease, that is, tcp ramps up speed
until a packet is lost or until an ACK takes longer than the congestion
window. at that time, tcp multiplicatively decrease speed (cuts it in
half) and then starts to ramp up again until such time as tcp feels that
it has obtained optimum throughput.


> I'm starting to think perhaps my problem is not necessarily in shaping
> stuff into the VPN, it's shaping everything out over the ADSL
> connection.  I read somewhere that a 128k upload ADSL connection will
> take 40ms to transmit a max-size packet.  So shaping becomes pointless
> if 40ms is too long for the VoIP to handle as a delay.
i think that you may be getting a bit confused -- in a simple lan/adsl
environment, there are two ingresses and egresses: ingress coming in on
ppp0 for example, and egress leaving eth0 towards the lan. similarly,
there is ingress on eth0 as packets come in from the lan, and egress on
ppp0 as packets are dequeued towards the adsl. i think that you should
try placing egress on your ppp0 to classify packets and priorities in
such a way that they are dequeued in a manner that corresponds with your
needs.

<snip>

cheers

chalres

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/