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...
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...
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.
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.
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.
