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

ffeature request

William Warren
I like the fact that ASL has QOS on hte outgoing traffic..however incoming QOS would also be highly useful..[:)] 


This thread was automatically locked due to age.
Parents
  • 0
    William,

    there is one problem, the purpose of doing QoS is to use your bandwidth more effective, right? For inbound traffic however, by the time the traffic reaches the Astaro QoS the bandwidth was already used... 
  • 0 in reply to Andy_01
    this is not to manage your incoming bandwidth usage..but to be able to limit hte bandwidth usage of individual groups or veven users..aka i want to make a certain group of users/services to use only 128k incoming bandwidth....that would be a nice option to have...therefore insuring other users have a better share of the total incoming pipe(cuts down on hogs)....
    frankly soho products like sygate have this feature i am surprised a product aimned at the enterprise(like ASL) does not..[:)] 
  • 0 in reply to William Warren
    You cannot really manage incoming data speeds.

    Well you can, but the firewall will just be dropping packets, so the bandwidths used already. 
  • 0 in reply to Simon Shaw
    well if i have a 3 meg pipe and i do not want one user to hog it all i am obviously not worried about overall usage on the pipe..i want to be able to limit user to a certain speed..128k 1 megabit..whatever..[:)]  Hence the request for the feature... 
  • 0 in reply to William Warren
    If the firewall is dropping packets at the server end wont TCP/IP windowing automatically reduce the number of packets to match the number of packets that are getting through hence using less bandwith???    
Reply Children
  • 0 in reply to Kogmonster
    If the firewall was to refuse ACKing beyond a certain number of packets/unit time for a designated user, true the packets would get there in response to the first request anyway; but a user not getting all the packet replies back to his workstation will usually give up on making the excessive requests; and thus, over the long term, it will make for more bandwidth preservation on the inbound.

    Another more draconian approach (and thus should not be configured by default!) would be to disallow ALL firewall interaction for an IP once it has abused its inbound quota/unit time. As soon as this is reached, refuse ACKing any packets for the workstation, and shut the user out of the firewall for some proscribed period of time, that can possibly be overridden; coupled with a mail notification, that would be interesting.

    P.S. I wouldn't like to spoil anybody's surfing, but these could be used with ridiculous sustained thresholds, where you really were being a bandwidth hog...