Fw: [Openvpn-users] QoS in OpenVPN 2.0

[Ross M. <ros...@ya...>]

Whoops hit reply instead of reply all.
/Ross

----- Original Message ----- 
From: "Ross MacGillivray" <ros...@ya...>
To: "James Yonan" <ji...@yo...>
Sent: Monday, March 28, 2005 4:07 PM
Subject: Re: [Openvpn-users] QoS in OpenVPN 2.0


>I looked at the change log for more information on passtos.
>
> If I wanted to engineer a network with VPN traffic and non-VPN traffic.  I
> think at least some of the time I would
> want to set the priority of all VPN traffic on the physical interface 
> ahead
> of all non-VPN traffic.  I would do this on
> the physical interface using whatever capability for QoS that existed in 
> the
> host OS.    From the point of view of the host
> OS all VPN traffic (even lower priority traffic within the VPN) would
> treated
> at a higher priority than non VPN traffic
> presumable if there is a reason to build a VPN, there is reason to
> prioritized all traffic on the VPN as high.
>
> Within the VPN I might want to have High, Medium, and Best Effort Traffic.
> However Best Effort VPN Traffic
> might still be pushed through faster than the non-VPN traffic.   This kind
> of scenario means using the same ToS bit settings on the inner (VPN) 
> packet,
> and outer non-VPN packet wouldn't work   What this calls for, I think, is
> two independent traffic classification and marking mechanisms one outside
> the VPN implemented by the host OS, and another implemented within the VPN
> by OpenVPN (sorry if I'm creating work).
>
> Also in practical network building scenarios particularly within
> communications carriers, the people who build and
> administer VPNs and associated quality of service within the VPN may have
> only some contact with the people who administer physical network
> infrastructures.  VPNs are often built under custom contracts specific to 
> a
> given customer.  The VPN customer may insist upon 4 priorities within 
> their
> private network, i.e. within their VPNs, and the administrators of the
> physical hardware may only support 3 priorities.   VPN traffic might be
> always marked as high within the three priorities of the physical
> infrastructure.  Even if lower priority traffic within the VPN rides the
> physical network at a priority lower than High Priority, the 
> transformation
> from four priorities within the VPN to three priorities on the physical
> network is not obvious.  For all of the above reasons, I think independent
> classification and marketing within the VPN independent of the ToS bit
> setting outside the VPN will be needed.
>
> Again the above scenario argues for traffic classification and marking 
> within
> the VPN that is independent of the traffic classification and marking
> outside the VPN.
>
> I am not suggesting anything should be removed from OpenVPN only that
> independent mechanisms of traffic classification (based for example on 
> Port
> field data) and then subsequently marking (filling in the ToS bits 
> according
> to some standard such as Differentiated Service) are probably needed.
>
> Finally, I should point out OpenVPN is a great product, and adding 
> traffic
> classification and
> marking capability explicitly for traffic within the VPN would do nothing,
> but improved the product, and I am guessing that public carriers if they 
> are
> not doing so now may well adopt OpenVPN for certain 'special' products.
>
> /Ross
>
> ----- Original Message ----- 
> From: "James Yonan" <ji...@yo...>
> To: "Ross MacGillivray" <ros...@ya...>
> Cc: <ope...@li...>
> Sent: Sunday, March 27, 2005 11:32 PM
> Subject: Re: [Openvpn-users] QoS in OpenVPN 2.0
>
>
>> On Sun, 27 Mar 2005, Ross MacGillivray wrote:
>>
>>> I agree if you simply want to prioritize all Tunnel traffic versus other
>>> traffic on the physical interface(s) of the machine
>>> hosting OpenVPN, then this can be done using the host operating systems
>>> stack.  Assuming the stack on the host OS
>>> supports QoS capability, but that is a different question.
>>>
>>> What I was looking for was prioritization within the Tunnel of specific
>>> traffic versus other traffic.
>>
>> This is exactly what --passtos does.
>>
>> James
>