LARTC - Sep 2004 - interesting expert problem - shaping over VPN

Here''s a challenging problem for you experts to tackle:

I''m trying to shape traffic going into an IPSEC interface which then
goes
over a DSL PPPoE interface.  I figure I need to shape the DSL interface to
keep it''s hardware queue mostly empty, and to prioritize between IPSEC
and
non-IPSEC traffic.  I also have to shape going into the IPSEC, which
carries VoIP (high pri), VNC (med pri) and other (email, etc, low pri).

I have it all set up and working, except that the IPSEC shaping doesn''t
seem to do any good whatsoever.  Even if I allocate 99% of the bandwidth
to the VoIP and 99% to IPSEC over PPPoE I still get break-ups in the VoIP
signal when I do some heavy VNC.  I tried such drastic things as reducing
the "ceiling" to half of what the DSL line was spec''d (and
tested) as
supporting.  I played with the numbers until they were really skewed (99%)
in favor of VoIP, but still no joy.

So my question is, am I missing something fundamental conceptually
regarding shaping traffic into an IPSEC/VPN interface and then shaping
that along with non-VPN traffic out over the single internet connection?
Is there some buffering/queue stuff in IPSEC or PPPoE that would prevent
me shaping properly?

I am using FreeSWAN IPSEC on Fedora Core 1.

Thanks for your help.

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

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=130172)
> 
> 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/

whoops,

oh yea -- ipsec and that whole eth0 thingy :-/   no wakeup on sundays.

are you running your tunnel exclusively for voice, or are there other
protocols as well ( i.e. contention).

cheers

c


On Sun, 2004-09-26 at 11:36, Trevor Cordes wrote:
> On 26 Sep, lartc@manchotnetworks.net wrote:
> > hi trevor,
> > 
> > perhaps others can chime in on their experiences and configs that have
> > shown promise for voip.
> 
> OK, I''ll keep watching/posting.
> 
> > i would think that you would want to egress on both interfaces to
insure
> > that the packets you want pass first. i thought that you had both
> > already.
> 
> I have egress on ipsec0 and ppp0 but not eth0.  It''s actually 3
> interfaces total, which is why I hate PPPoE... it''s so over
complicated.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/