How to allocate an equal share of incoming web traffic to every user

Hi,

My company has Ethernet link to our ISP but the bandwidth ISP gives us
is only 2Mbps. How should I configure border router to provide an
equal share of incoming web traffic to every user. Is it enough to
just issue "fair queue" command on outside interface, or I should use
other technique?
I think I'd use some king of queueing or shaping but I'm sure what
exactly should I use.

 

:My company has Ethernet link to our ISP but the bandwidth ISP gives us
:is only 2Mbps. How should I configure border router to provide an
:equal share of incoming web traffic to every user.

Are you sure you want to do that? If 9 users look at simple pages that
are only (say) 10 Kb long, and the 10th user is looking at a page that
is (say) 100 Kb long [darn advertisements!] then your requirements as
stated would require that 90 Kb would have to be dropped from out of
the 10th user's page (or else that the 10th user would have to sit and
wait for the other users to all get around to visiting 10 pages each in
before the 10th user's page would be delivered.)

Over how long a period should the "share" be computed? If someone
stays behind when everyone else leaves, so that their www surfing
will not interfere with anyone else, then when that last person hits
the volume used by the other users that day, should the last person
be blocked until the next day when others come in and do more transfers?
What happens if one of the others is sick or away from the office and
so transfers nothing -- should the others be blocked from transfering
anything as well?

How do you intend to determine whether traffic is for a particular
user? If you have any kind of server (e.g., a unix machine) then
multiple people might be logged in to it, and http connections are
not marked as to who started them (not unless you are using one
of the AAA schemes such as is used on the PIX; the PIX makes a poor
traffic shapper, though.) You cannot work "per connection", as
some browsers will start multiple connections per user interaction
[e.g., if there are multiple images to be fetched.]


:Is it enough to
:just issue "fair queue" command on outside interface, or I should use
ther technique?

If you fair queue on your outbound interface, all you will achieve is
fair queueing of the http *requests*.

If you fair queue on the inbound side of your WAN interface, you could
end up throwing away traffic that had -already- crossed the 2 Mbps
link. The only way that helps is that it forces TCP to engage in
congestion control for that link, which works over the longer term
but wastes the bandwidth already consumed.

:I think I'd use some king of queueing or shaping but I'm sure what
:exactly should I use.

Roughly speaking, "queueing" would be associated with policies that
gave priority for one kind of traffic over another [e.g,, suppose that
there was a bunch of traffic for an internal machine, such as perhaps
an internal ftp: then you might want to prioritize the returning
http traffic over that ftp traffic, knowing that it is realatively
expensive to have to get the http traffic but relatively cheap to
retransmit the ftp traffic locally. "Policing" is, generally speaking,
associated with policies that monitor traffic use and discard traffic
that there isn't room for within the policies. "Shaping" is similar
to "policing", except that packets get buffered to be sent out at
the next opportunity instead of being discarded. You can see that
"shaping" could involve large amounts of memory buffers; policing can
usually be implimented in hardware with only the memory buffers that
would already exist for the port queues anyhow.

 

dont change anything. 2mbps should be more than adequate for web browsing
for any small office scenario.

 

The fact is that our company also has 2 VPNs that connect central
office with brunch offices located in other cities. There's no any
kind of QoS for these VPNs - it's bandwidth is as good as Internet
connection between Cisco Routers which acts as VPN endpoints. So I
fink configuring fair queue on outside interface is not a bad idea.

 

:The fact is that our company also has 2 VPNs that connect central
ffice with brunch offices located in other cities. There's no any
:kind of QoS for these VPNs - it's bandwidth is as good as Internet
:connection between Cisco Routers which acts as VPN endpoints. So I
:fink configuring fair queue on outside interface is not a bad idea.

Maybe it is just that I haven't had enough sleep yet, but I am having
a hard time understanding what you have written above. I am having
an even harder time relating it to your original question about
providing an equal share of incoming web traffic to every user.

If possible, avoid trying to control *incoming* traffic by applying
limits to your outside interface. Traffic should be controlled at the
point of transmission, not at the point of reception: otherwise
you are throwing away traffic you have already paid to receive
in the hopes that it happens to be part of a long transission and
that the other end will notice the lack of acknowledgement and will
slow down transmitting the rest. If one person has a large
transmission and the rest have smaller transmissions, you could end
up retransmitting big parts of the larger transmission several times
before the rate slowed enough to match the lower bandwidth that the
other users -happened- to be using.


If you want to control traffic fairly and to be able to fine-tune
what gets priority and what does not, then I suggest that you should
invest in some equipment by Packeteer.