Re: QOS

I was hping for inbound rate limiting and/or QOS myself..[:)]  

I think that inbound rules make no sense at all, how would you control how many data you may receive at the firewall ?
What would be nice however with QOS is the ability to add a rule based on the source port on the firewall, and not only on the target port... 

If this were the case, how do you think the internet would function?

Servers on 100MB backbones would be trying to cram massive amounts of data down dial-up lines.

As I understand it (and i could be wrong), the TCP algorithm adjusts the speed of data if packets are lost so inbound QOS is perfectly possible.

(and implemented in other firewall products)
  

No, what happens is the "recipient" just drops the excess packets forcing the server to resend them.  The server does not magically know the speed of the downloading user.

So you can do primitive QoS on incoming traffic, but all's you are doing is saying "I have x speed connection, drop packets in excess of this amount"   The sending server see's what gets through and what doesn't and just keeps resending till the clients got all the file.

Basically the 100mbit server tries to cram the file down the link, but it misses so many acknowledgements it has to resend.

TCP cannot adjust the speed on the fly like that.
 

whether or not it is pretty is not the issue(interesting how this always gets twisted)..we want the ability to rate limit the incoming traffic... 

So your saying that an ISP with several thousand dial-up customers, will just have to drop several Gbits of traffiic/second  from servers on internet backbones?

I thought that the TCP algorithm, when faced with lots of dropped packets, altered its bandwidth utalisation.

Anybody else want to clarify this?   

So your saying that an ISP with several thousand dial-up customers, will just have to drop several Gbits of traffiic/second  from servers on internet backbones?

I thought that the TCP algorithm, when faced with lots of dropped packets, altered its bandwidth utalisation.

Anybody else want to clarify this?   

Well what actually happens is the server waits for an ACK from the client before sending the next packet.

(Unless the connection is UDP traffic, UDP is connectionless, packet gets sent and the server hopes it gets there but doesn't know).  (AFAIK).

When bandwidth limiting incoming connections you basically drop the packets and don't ACK past the set limit.  This means the server resends the packets it never got an ACK for.
 

And if the server does not recieve an ack packet, it backs off and lowers its rate of transmission?

I don't see this as a dirty form of QOS, so is it possible to add it to astaro?

Thanks

Alex