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

[Openvpn-users] QoS -- passtos and non-tos packets?


  • Subject: [Openvpn-users] QoS -- passtos and non-tos packets?
  • From: matt mead <m-sf@xxxxxxxx>
  • Date: Fri, 02 Jun 2006 12:21:16 -0400

I have recently switched to using passtos, and doing htb traffic control to 
throw bulk (0x8) and interactive (0x10) tos packets into queues that correspond 
to the quality of service I want to achieve.

This works very well at the outer physical interface level - the TOS packets 
and other packet designations get into the right queues based on a number of 
filter matches.  However, when speaking strictly about the VPN, it seems that 
the packets with TOS are prioritized properly at the outer physical layer, but 
there are some additional packets with TOS 0x0 that get dumped into an "all 
other traffic" type of queue.

Using tcpdump on the outer physical interface, I can do interactive ssh and see 
that when I press enter, a number of udp packets hit the VPN server.  Some are 
TOS 0x10 and some are 0x0.  It is these 0x0 packets that concern me.  Since 
they get dumped into an "all other" type of queue, one high rate connection 
through the VPN can degrade the interactivity of other connections through the VPN.

The 0x10 (interactive) packets go through quickly, the 0x8 (bulk) packets get 
available bandwidth only type queuing, but these extra 0x0 packets from *all* 
VPN connections get lumped into a single queue, mixing packets associated with 
the bulk and interactive together into that single bucket.  While interactivity 
is improved over no queueing at all, the interactive sessions are still getting 
hampered by the lumping into a single queue of all the 0x0 packets I have no 
way to classify.

I'm curious if the 0x0 packets that are clearly associated with the 0x8 and 
0x10 packets should have their TOS bits set -- is there some issue with openvpn 
that is causing them not to be?  Are they control information for the 
particular TCP connection being encapsulated in the VPN?  Is there some way to 
better associate all packets related to a single connection on the outer 
physical network interface?  I'm guessing the inability to do so is part of the 
design - otherwise there might be information disclosure about the traffic 
encapsulated in the VPN tunnel.

Currently I am using iptables to set TOS for specific known services that 
people use through the VPN.  I have openvpn configured to pass TOS through, and 
then I perform queue selection with traffic control based on TOS bits.  Is 
there a better way to do QoS?


-matt

-- 
matt mead

http://collectivity.goof.com/


_______________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users


Warning: require_once(../../../archive_common.php) [function.require-once]: failed to open stream: No such file or directory in /home/openvpn/domains/openvpn.net/public_html/archive/openvpn-users/2006-06/msg00036.html on line 220

Fatal error: require_once() [function.require]: Failed opening required '../../../archive_common.php' (include_path='/usr/local/lib/php') in /home/openvpn/domains/openvpn.net/public_html/archive/openvpn-users/2006-06/msg00036.html on line 220