[LARTC] interesting expert problem - shaping over VPN

[LARTC] interesting expert problem - shaping over VPN

[lartc]

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/

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

[lartc]

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/

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

[lartc]

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/

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

[lartc]

hi trevor,

well, if you're controlling whats going over the vpn then there are
several options:

i've been playing with racoon lately (well longer then with freeswan) so
i'm not so sure with ipsec, but ... it appears that the meta-data ( i.e.
packet marking) is perserved on packets that have not yet been encrypted
but are going to be.

as a general strategy, i would mark packets with different marks
depending on what the payload is -- maybe something like 0x1 for voice,
0x2 for smtp, etc.

then use these marks on the public interface to egress them towards the
internet in the highest priority.

mark the inbound packets coming off the internet (once they've been
decrypted) and place them in highest priority (depending on their type)

this wouldn't be too bad -- in fact it's about all you can do.

Alternatively, and with more complexity, open up several tunnels with
different spi's -- pass traffic into tunnel by type -- this would allow
you to know what an encrypted packet was carrying without having to
decrypt it. cool, but i'm not sure that it would help much.

anyone else done this??? tcng files are great (hint :-)

cheers

charles

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