Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 2 subscribers
  • Views 1249 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

PPPoE-DSL and QOS Question

aelbric
First time Astaro user.  I absolutely love the product and am on the cusp of recommending it to some of my small-business consultant friends.  The only hurdle I have left is validating that QOS is working on low-bandwidth broadband connections.

I have gone through the posts here and any documentation that I can find.  It appears that under V6 there may be an issue with QOS actually functioning properly.  My experimental setup is as follows:

Athlon 700Mhz w/ 512MB RAM
Astaro v6
3000/512 DSL
100 Mbps LAN
2 LAN clients
1 802.11 client
1 Linux server (HTTP, SAMBA services)

All services including IPS, MASQ, DNS, HTTP Proxy, SIP Proxy working fine.  When I enable QOS though, there is a hiccup.  The external interface is configured with QOS on, uplink at 512:256:192:64, downlink at 3000.  As with all other reports that I have seen, any service (P2P for example) that will consume all bandwidth does not release it to the higher-priority queues when necessary.

Example rules (using a P2P app for bandwidth consumption): 
Source - Service - Action - Destination
Internal - Any - Allow (standard) - Any
Any - P2P - Allow (low-priority) - Any

With the P2P app running at fulll speed, all of the normal congestion issues crop up.  SIP calls and RTP connections drop, latency skyrockets, web browsing fails (even pointed to the HTTP Proxy).  Is there a problem with this ruleset or is it the QOS implementation?

One other thing.  I noticed that the "Monitor Interface Usage" option does not appear in WebAdmin for a PPPoE-DSL connection as it does for standard ethernet.  Is there a way to manually trigger the threshold messages?  Is this an oversight in the management interface?

Any help or insight would be appreciated.


This thread was automatically locked due to age.
Parents
  • 0
    QOS doesn't seem to work very well in ASL 5 & 6 for a lot of people.

    Nonetheless,

    1. Are you using the SIP proxy? If not, you should set a rule for SIP to be HIGH Priority.

    2. Have you tested your DSL to see if it is as fast as it's rated at? (try dslreports or upload to a nearby FTP server)

    3. It is very hard to get P2P to conform to a set of defintions, as a lot of "servers" (peers) won't be using the standard ports.
    Therefore, you might want to change your ANY-ANY rule to also be LOW Priority, and see if that helps for SIP, etc. Or, set a rule just for the PCs running P2P to be LOW.

    4. I don't know about the "monitor interface usage", but you can install IPTraf if you want. (search these forums for instructions)

    I'm using ASL 5.2 (which doesn't have a SIP proxy), and I've found that I have to set my P2P client (eMule) to only use about 1/5 of my outgoing bandwidth, or else I have problems with dropouts on my VOIP phone.
    I set this within eMule itself.

    Barry
  • 0 in reply to BarryG
    [ QUOTE ]
    QOS doesn't seem to work very well in ASL 5 & 6 for a lot of people.

    Nonetheless,

    1. Are you using the SIP proxy? If not, you should set a rule for SIP to be HIGH Priority.

    2. Have you tested your DSL to see if it is as fast as it's rated at? (try dslreports or upload to a nearby FTP server)

    3. It is very hard to get P2P to conform to a set of defintions, as a lot of "servers" (peers) won't be using the standard ports.
    Therefore, you might want to change your ANY-ANY rule to also be LOW Priority, and see if that helps for SIP, etc. Or, set a rule just for the PCs running P2P to be LOW.

    4. I don't know about the "monitor interface usage", but you can install IPTraf if you want. (search these forums for instructions)

    I'm using ASL 5.2 (which doesn't have a SIP proxy), and I've found that I have to set my P2P client (eMule) to only use about 1/5 of my outgoing bandwidth, or else I have problems with dropouts on my VOIP phone.
    I set this within eMule itself.

    Barry 

    [/ QUOTE ]

    1.  No SIP Proxy in use for the test. VoIP seems to be most latency and congestion sensitive so I'm using it as a test.

    2.  This particular DSL line is running at rated speed.

    3. Interesting idea setting all traffic to low priority and setting critical services to high only.  I would think that might move the problem though.  Of course if VoIP traffic is working that may be good enough (for now).  I will try some combinations of this and report back.

    4.  Monitor Interface Usage should be an option on the WebAdmin page for the interface that allows you to set threshold for reporting congestion.  It's MIA from the PPPoE-DSL page.

    The only reason I'm using a P2P app for this is that it's the easiest way to saturate a link for long periods of time both ways (don't worry, I'm sharing Linux ISOs [:)] case.
Reply
  • 0 in reply to BarryG
    [ QUOTE ]
    QOS doesn't seem to work very well in ASL 5 & 6 for a lot of people.

    Nonetheless,

    1. Are you using the SIP proxy? If not, you should set a rule for SIP to be HIGH Priority.

    2. Have you tested your DSL to see if it is as fast as it's rated at? (try dslreports or upload to a nearby FTP server)

    3. It is very hard to get P2P to conform to a set of defintions, as a lot of "servers" (peers) won't be using the standard ports.
    Therefore, you might want to change your ANY-ANY rule to also be LOW Priority, and see if that helps for SIP, etc. Or, set a rule just for the PCs running P2P to be LOW.

    4. I don't know about the "monitor interface usage", but you can install IPTraf if you want. (search these forums for instructions)

    I'm using ASL 5.2 (which doesn't have a SIP proxy), and I've found that I have to set my P2P client (eMule) to only use about 1/5 of my outgoing bandwidth, or else I have problems with dropouts on my VOIP phone.
    I set this within eMule itself.

    Barry 

    [/ QUOTE ]

    1.  No SIP Proxy in use for the test. VoIP seems to be most latency and congestion sensitive so I'm using it as a test.

    2.  This particular DSL line is running at rated speed.

    3. Interesting idea setting all traffic to low priority and setting critical services to high only.  I would think that might move the problem though.  Of course if VoIP traffic is working that may be good enough (for now).  I will try some combinations of this and report back.

    4.  Monitor Interface Usage should be an option on the WebAdmin page for the interface that allows you to set threshold for reporting congestion.  It's MIA from the PPPoE-DSL page.

    The only reason I'm using a P2P app for this is that it's the easiest way to saturate a link for long periods of time both ways (don't worry, I'm sharing Linux ISOs [:)] case.
Children
  • 0 in reply to aelbric
    Well, the SIP proxy is supposed to solve the problem for VOIP.

    Solving it for everything else could be hard (as I said in #3, P2P is hard to regulate as the ports move around alot, even within 1 P2P app).

    Barry