From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Wed, 11 May 2005 22:02:21 +0000 Subject: Re: [LARTC] vlan traffic shaping. Message-Id: <428280ED.9060503@dsl.pipex.com> List-Id: References: <1115613474.14194.25.camel@chidori.cephiro> In-Reply-To: <1115613474.14194.25.camel@chidori.cephiro> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org Robert Denier wrote: > I couldn't find anyone who had actually made it work via google so I > guess I'll ask here. > > My setup is a VPN point to point link. The VPN is a modified version of > Openvpn where I'm using zlib compression to improve the compression a > bit. > > The goal is to shape traffic coming from a routing server through the > vpn to the endpoint of the vpn and in such a way maximize the usefulness > of a limited bandwidth connection. > > You can shape the vpn tunnel just fine, but that has a problem since you > shape the traffic _before_ any of it is compressed and thus cannot > really deal with compression in an ideal manner. > > The ideal thing to do is to shape traffic after the VPN software > processes it and sends it to the real interface. Of course, now that > I'm taking the time to explain the problem, an answer becomes somewhat > obvious and that is to add shaping just on the source/dest path used by > vpn packets on the real interface. > > What I was trying to do was to create a vlan interface like eth0.5 and > then use that interface to run the VPN link, and thus have a nice > intermediate point where I can do all the shaping. Unfortunately when > one actually tries to do this, the shaping seems to set itself up > normally, but in fact does absolutely nothing with the vlan interface. > > I suppose some more analysis of my idea is in order. I may be a little > wrong on some things so feel free to correct me. > > 1) You can shape all traffic correctly on the VPN link, except > compressible traffic which changes in size after leaving the VPN > software. It would be nice if a netfilter mark would carry over from before to after VPN - maybe the software could be hacked to do this. Then you could classify/mark traffic before encapsulation and shape it on eth0 - I have never tried, but don't think shaping on virtual eth0.x will work. > > 2) You could shape raw VPN packets based on source/dest type marking. > Now what does this mean for the shaping in 1)? If this particular path > is at its max rate and the queue is full then a packet will be sent to > that interface but ultimately dropped. VPN packets are UDP, so the > recovery would have to be in the VPN software. Double shaping is not going to be Ideal. If you just shape after encapsulation I think the fact udp is used to encapsulate is irrelevant. If it is tcp that is being carried then the sender should react normally to drops. Andy. > > It would seem if I'm understanding this correctly that even if I got > vlan to do what I thought I wanted it to do, it might not help anything. > Of course you might get around this by using TCP for vpn packets. > > I'm a little uncertain of some things in the last couple paragraphs so > I'll probably just try it. At any rate, one way for compression to > still be useful is to allow web pages to burst above the maximum > bandwidth by around 100KB. This covers most of the cases where > compression is useful. Anything low priority like ftp transfers must of > course be hard capped below the links capacity and set to a low > priority.. _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc