[H-GEN] Network load calcs
Ben Carlyle
benc at foxboro.com.au
Fri Jun 25 01:14:14 EDT 1999
(Note reply-to: being general at humbug.org.au vs Ben Carlyle <benc at foxboro.com.au>)
Christopher,
Michael wrote:
> > Using ipchains you can gain some control over OUTGOING packets by using the
> > -t option to manipulate the TOS[1] flags. If you want to control INCOMING
> > packets, then you are SOL[2] unless you have control over the upstream
> > router (do you think Telstra or Ozemail would let you play with their
> > routers? 8^)
You wrote:
> Can one not do it based upon the port that the packets come in on?
Ahah. A chance to draw some ascii art and neglect my duties at work
for a few minutes:
Your network
-------- ------------
| | outgoing data -> | |
| Router |--------------------------------------| ISP Router |
| | <- incoming data | |
-------- ------------
|| | |
|| | |
|| | |
|| | |
|| | |
-------- vwvwvwvwvwvwvwvwv
| | \ Internet /
| PC(s) | / (It's a cloud \
| | \ dammit!) /
-------- wvwvwvwvwvwvwvwvw
||
|| - Fat pipe
||
--- - Skinny pipe
According to the Internet Protocol, when a router is requested to
send more data down a pipe than can fit, it is required to discard
packets right then and there. It cannot send more packets than the
pipe can carry (for hopefully obvious reasons), therefore the
router trying to send the data is effectively the bottleneck.
As you can see by this crude diagram, the usual bottleneck for
internet traffic to a subnet is the ISP<->Local router connection,
hence there is a bottlneck of outgoing data at your router, and
a bottleneck of incoming data at your ISP router. Since most internet
traffic tends to be incoming, this is somewhat of a problem. You
usually don't have control over the ISP router. You cannot rely on
the default router implementation to give you any quality of service
whatsoever unless you have specifically had it put in place. QOS
is -not- required by the Internet Protocol version 4 (IPv4).
The Internet Protocol version 6 (IPv6) is slightly cooler with
respect to Quality Of Service (QOS) and deciding which packets
to drop:
1) QOS is mandatory in all compliant implementations.
2) QOS actually means something, with a set of 16(? and yes,
I'm simplifying) priority levels with losely defined
criteria for placement of different user-level protcols
(telnet, ftp, email, etc).
It doesn't go all the way, and certainly doesn't implicitly provide
a mechanism to do some of the things originally requested in this
thread (such as different priorities for masq and squid traffic).
We'll also have to wait until the world (slowly) changes over to the
new IP version before any of the benefiets really appear. The major
difference users will notice is probably that their irc sessions
won't be buffeted as much by FTP and web traffic.
You have no means by which to explain to the remote (bottlneck)
router which packets to keep and which packets to drop.
As Mark Suter has pointed out, what I have said so far is only
absoultely true for protcols that do not require data to travel
in both directions. TCP is a classic example of a bi-directional
protocol with congestion control, which means that deliberately
slowing down the reply confirmation packets will cause the protocol
to send data more slowly. If your incoming data is TCP based, then
you are essentially simulating congestion... lying and saying that
the packet never arrived most of the time. This can be an effective
hack, but it is a sledgehammer approach for a couple of reasons I
can think of:
1) It's an end-to-end solution, meaning that packets are re-sent
from the source costing everyone money.
2) You recieve the same packet multiple times, possiblly adding to
your congestion problems.
3) You have to pinpoint the packets that are replies to the offending
data.
4) You will probably have to do a fair bit of fine tuned guessing
to decide how much to throttle.
After a few failures, TCP will start sending (and failing)
less often. This will reduce congestion.
In the end there is no
universally accepted protocol I'm aware of for describing which
packets a remote router should keep and which it should discard
when encountering congestion on "your" link over stock-standard
IPv4. Hacks are available, but don't expect an out-of-the-box
solution.
Benjamin.
--
This is list (humbug) general handled by majordomo at lists.humbug.org.au .
Postings only from subscribed addresses of lists general or general-post.
More information about the General
mailing list