[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

Re: [Openvpn-users] Re: Packet Aggregation with OpenVPN?

  • Subject: Re: [Openvpn-users] Re: Packet Aggregation with OpenVPN?
  • From: "uml" <uml@xxxxxxxxx>
  • Date: Sat, 15 Jan 2005 15:32:24 -0500

> On Sat, 15 Jan 2005 10:47:35 -0500, uml wrote:
> > Would there be a way of aggregating the stream (up to 1500 bytes
> > obviously) per crypto packet sent out over the openvpn link and
> > disassembled on the other side to keep the pps on the WAN side down?
> >
> > Is this a feature that could be considered for 2.1+ (or 3.0)?
> James is the person to speak on whether he'd consider the feature. Just
> looking at it from my perspective...

> Hmm. There's a definite latency penalty involved in doing that. Could you
> use IAX2 trunking? It's built with your individual application in mind,
> and consequently might be somewhat more effective.
Yes, the latency penalty comes into play in that you must queue the packets
(until either the MTU is reached or a latency timer is reached), but at the
gain of bandwidth and the sheer volume of packets that commodity grade
equipment can accomodate.

Unfortunately, IAX2 trunking is native only to asterisk at the moment, and
while it is a good idea, it is not new or the only place it is being used.
Quintum has a proprietary H323 'packet saver' technology, but once again,
proprietary.  I'm looking to be able to run any given protocol in this
fashion due to varying media (i.e. wireless, satellite, fibre, et al).
There are some wireless vendors who do this on their equipment, but it's
proprietary as well.  I'd love to use IAX2, but all the major carriers use
H323 still for the majority of all call traffic so our hands are usually

> Likewise, you could probably have another userspace bridging tool that
> does that (reads packets from the "real" interface, does
> packet-aggregation as appropriate, writes them to the tun device that
> OpenVPN is listening on), rather than needing this to be implemented in
> OpenVPN itself. It would still be a useful feature for folks who *aren't*
> using OpenVPN, right?
Interesting -- I wouldn't have a problem with that approach either, making
it more abstract from OpenVPN.

The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
Openvpn-users mailing list