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

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.
Parents
  • [ 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
Reply
  • [ 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
Children
  • 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.
  • [ 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
  • [ 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