Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 2 subscribers
  • Views 2369 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

QOS for VOIP & P2P - designing around issues

AdrienBelcourt
Hi, QOS seems to have worked fine for me. However, Astaro places priority-based-discard on the egress(upload) side of the interface. You have to design your QOS setup around this.  Here is my understanding so far, with suggestions.

The best place for prioritisation-based-discard is just after the packet filter has marked the traffic. The best and toughest way to discard-on-priority is to then check the ingress port and work out if your P2P traffic is overwhelming the Voip traffic. You then discard P2P based on ingress. Astaro does not do this. It checks the egress port instead. You can still do QOS but it requires wrapping a hot towel round your head and thinking hard.

Am building a couple of different lab setups to prove this function. Try the following and tell me how you get on.

Upload Bandwidth: 450K
Download Bandwidth: 180K
(do speed tests and monitor using Reporting -> Network)

(Internet to LAN) INTERNAL Upload QOS (egress)
450 (priority only) or 450:450:400:400 (reserve 50K of bandwidth)

(Lan to Internet) EXTERNAL Upload QOS (egress)
180 (priority only)or 180:180:130:130 (reserve 50K of bandwidth

Download QOS (ingress)for both INTERNAL and EXTERNAL
100000 

Prioritisation on Discard only happens as the packet leaves (egress) the firewall. So received traffic prioritisation for Voip and P2P downloads should happen as those packets egress on the internal interface. So designing the rules to get what you want is tricky.

I suggest setting your ingress(download) discard threshold high. You do not want packet discard on ingress, as it discards packets from all types. So Voip traffic is hit. Leave the discarding to the egress QOS so lower priority traffic is dropped first.

I think you can only reserve bandwidth if you have Multiple lans. What I want to try next is this.

Upload
EXT: 180:50:130:130 (LAN+DMZ to Internet)
INT: 100000:450:100000:400 (Internet+DMZ to LAN)
DMZ: 100000:50:100000:130 (Internet+LAN to DMZ)

Download: all interfaces set to 100000

The questions I need to prove to go forward are:

1. Any packet filter rule (for say FTP) will mark packets travelling in both directions as Low, Medium or High - default being Medium.

2. Overload of the ingress port (download QOS) results in randomly selected packets being discarded regardless of whether they may be low(p2p), medium or high(voip) priority.

3. It is only on egress from the firewall (both internal or external interfaces) that the lower priority packets can be discarded in favour of higher priority packets.

4. The QOS policy must be designed to avoid packet discards on ingress(download) in favour of egress(upload) to protect high priority traffic.

5. The QOS setting 1024:512:128:128: sets maximum allowed bandwidths, i.e. it is not bandwidth reservation. So 1024:512:1024:128 would be valid....

6. Its right to enable/set QOS on all the physical ports.

Will keep you posted,

Adrien.


This thread was automatically locked due to age.
  • 0
    [ QUOTE ]
    2. Overload of the ingress port (download QOS) results in randomly selected packets being discarded regardless of whether they may be low(p2p), medium or high(voip) priority.

    [/ QUOTE ]

    IMHO, I'm not sure this is true in practice.

    Normally, the EXT interface in ASL is a 100mbit or 1gbit NIC hooked up to a router or bridge.
    Either way, the ASL interface will not be overloaded by incoming traffic under normal situations. (I'm sure you could construct a situation where it would happen, but I don't think it's likely.)

    Therefore, I don't understand why the ingress QOS would ever need to drop packets.

    Furthermore, in my experiences with P2P (eMule) and my cable modem (4000k/400k), the outgoing traffic is the problem. (for whatever reason, ASL's QOS doesn't seem to help here either.)
    It is very rare that the incoming link is saturated.

    However, I can imagine that bittorrent could overwhelm your downlink.
    Nonetheless, if it did, the ISP router, or possibly the cable modem if it has QOS, would be dropping your packets, NOT ASL.

    I don't see how QOS at the endpoint (ASL) can solve this problem. Only if all your VOIP traffic is tagged as high priority, AND your ISP routers have QOS AND they prioritize YOUR traffic, will QOS solve this problem (overloaded downlink).
    It is possible to get QOS from your ISP, but it won't be cheap.


    Am I missing something?

    Barry
  • 0 in reply to BarryG
    Thanks Barry,  your  right ingress qos is not going to drop packets received from the cable modems or LAN.  Ever I think.  A moment of "how did I miss that" there. By the same token - neither will Astaro if it well specced - and neither will egress QOS to the LAN.  
    So no reason to drop packet for downloads from the internet - unless I want to.  And I think there are good reasons to.  

    There must be upstream bottlenecks in the ISP that happily discard all types of packets as P2P tries to ram the  latest monster download onto a  machine behind the firewall.   Using "uplink" QOS for egress to the LAN however seems to be the only way to discard lower priority download traffic in favour of Voip.  You set your LAN egress bandwidth to the download bandwidth of your Internet connection.  Then, you throttle back the overall LAN egress bandwidth (and therefore download bandwidth) until the Voip stream goes clean.  This is the point where the upstream ISP bottleneck is no longer stressed.  Course P2P is having lots of packets dropped at the egress point onto your lan. Would you want it any other way?

    I also don't know how to tell if Voip packets are being discarded.  Does Skype give that kind of information so I can test this?  Any recommendations of Voip clients that give good network info to test the above guess?
    Does that scan for you?

    Adrien.
  • 0 in reply to AdrienBelcourt
    [ QUOTE ]
    There must be upstream bottlenecks in the ISP that happily discard all types of packets as P2P tries to ram the  latest monster download onto a  machine behind the firewall.   Using "uplink" QOS for egress to the LAN however seems to be the only way to discard lower priority download traffic in favour of Voip.

    [/ QUOTE ]
    Right.

    [ QUOTE ]

    You set your LAN egress bandwidth to the download bandwidth of your Internet connection.  Then, you throttle back the overall LAN egress bandwidth (and therefore download bandwidth) until the Voip stream goes clean.  This is the point where the upstream ISP bottleneck is no longer stressed.  Course P2P is having lots of packets dropped at the egress point onto your lan. Would you want it any other way?


    [/ QUOTE ]
    Interesting. Astaro has always recommended only setting QOS on WAN interfaces so I never realized you could do this.
    I guess it still won't work well unless Astaro only drops low-priority packets, which you said it doesn't.

    [ QUOTE ]
    I also don't know how to tell if Voip packets are being discarded.  Does Skype give that kind of information so I can test this?  Any recommendations of Voip clients that give good network info to test the above guess?

    [/ QUOTE ]

    I'm using VOIP hardware so I don't know if software VOIP shows that info (nor do I know if mine shows it either)... I guess you could use ethereal or whatever and look for missing packets.

    My understanding is that the SIP proxy in ASL 6 is supposed to make VOIP work better even if QOS isn't working well, but I haven't tried 6 yet.

    Barry
  • 0 in reply to AdrienBelcourt
    [ QUOTE ]
    Using "uplink" QOS for egress to the LAN however seems to be the only way to discard lower priority download traffic in favour of Voip.  You set your LAN egress bandwidth to the download bandwidth of your Internet connection.  Then, you throttle back the overall LAN egress bandwidth (and therefore download bandwidth) 

    [/ QUOTE ]

    I see major problems with this if you have a DMZ or multiple LANs.
    Transfers between LAN and DMZ will be throttled, and may even cause packets to be dropped unnecessarily.

    I guess you could have 2 ASL boxes to fix this, but that would be more expensive, etc.

    Barry
  • 0
     [ QUOTE ]
      I guess it still won't work well unless Astaro only drops low-priority packets, which you said it doesn't  

    [/ QUOTE ] 

    Did not mean to give that impression.  I am assuming that Astaro QOS "does exactly  what it says on the tin" - I just need to figure out how.

    [ QUOTE ]
     I see major problems with this if you have a DMZ or multiple LANs. 

    [/ QUOTE ]

    Yup - this is a doozy - see the latter half of my first post in this thread.  I kept the medium priority queue for LAN to LAN traffic.  not a very good solution, because it does not use priority discard - but uses the queue settings to throttle the traffic.  It also begs the question of whether the xx:yy:zz[:P]p settings in uplink qos define maximums for high-medium-low priorities or... reserve borrowable bandwidth. 

    Adrien
  • 0
    strange behaviour on P2P tests.  Outbound QOS rules do not seem to limit P2P bittorrent traffic.  No packets recorded on LiveLog.  

    Only packet filter rules:
    INTERNAL - HTTP- ANY allow
    INTERNAL - ANY - ANY allowLow (for Azerus)
    HTTP Proxy - transparent mode (cobion off)
    - CONNECT method blocked
    DNS Proxy on

    Roughly 10kbps upload and 10-20kbps download.  Modding the Egress figures for low priority traffic seem not to make any difference.  Even after firewall reboot.   The real kicker is switching off the ANY-ANY-ANY rule allowing only HTTP (connect method blocked), Azerus carries on slowly uploading and downloading.  NO trace of any packet activity in livelog.  Also the firewall performance was pants (as we say in the UK) despite the fact that the total throughput through the firewall was 30kbps.

    I do like  a puzzle, but my idea bag is empty here.  MTU to check next?  Have the MTU of my Azerus PC set to 1400. Any ideas of where to go next SVP.  

    Thanks in advance,

    Adrien.
  • 0 in reply to AdrienBelcourt
    Turning off a rule will not stop existing connections, it will only prevent new ones from being created.
    I.E. you'll need to restart the P2P clients, or possibly even reboot the firewall if there are a lot of peers still trying to keep connections open.

    You can use TCPDump on the console, or install IPTraf, if you want to look at packet traffic.
    (tcpdump is included in ASL 5, and I believe, 6. 
    For IPTraf, search these forums for instructions.)

    What part of the performance was bad? The webmin?

    Barry
  • 0 in reply to BarryG
    Finally got QOS to work to control P2P traffic to 50% of uplink and downlink bandwidth.  

    - 450Kbps - max DSL downlink without QOS
    - 180kbps - max DSL uplink without QOS

    Design objectives
    a) Limit P2P download to 200kbps and upload to 90kbps
    b) Ensure LAN to DMZ has full bandwidth
    c) Allow  higher priority traffic to steal bandwidth from P2P
    d) Protect VoIP traffic from packet loss.

    I set the following QOS rules
    Extrn: 100000:9910:90000:90  downlink: 100000
    DMZ: 100000:9800:90000:200 downlink: 100000
    Intrn: 

    Setting Maximum WORKS:  viewing network throughput on Webadmin: Reporting -> Network is beautiful smooth max uplink line of 200kbps and downlink line of 90kbps on the graphs from the time I implemented the above rules this morning.  Note, no other traffic competing apart from a little browsing and POP3/SMTP from Internal network.  You really can throttle P2P by putting the traffic in low priority queue and using QOS settings. 

    Key point was that the three queue qualifiers MUST add to the max queue bandwidth.  Anything else does not seem to work.  Also, can only limit traffic flow of low-default-high queues when traffic egresses the firewall - hence the 200k setting on DMZ limits the Azarus / P2P download and 90k setting on External limits the upload.

    Next - to prove LAN to DMZ (on medium/high) gets full bandwidth.  that higher priority traffic - say FTP/VoIP will steal bandwidth from lower priority P2P queue.

    Can anyone else confirm this approach works for them?  Also, does constraining download traffic causes VoIP to run clean?

    Adrien.