[H-GEN] Network load calcs

Martin Pool martinp at mincom.com
Fri Jun 25 03:02:57 EDT 1999


(Note reply-to: being general at humbug.org.au vs Martin Pool <martinp at mincom.com>)

Ben Carlyle wrote:

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

I think that it should be possible to throttle the sender (lovely image,
that) by delaying replies, but not by so much as to simulate loss and
cause congestion.  I haven't checked any documentation though.

I think a practical solution at this point is for endpoint programs to
offer options to restrain how fast they read from the network.  

For example, one can imagine an option on wget(1) that causes it to back
off if it's reading at more than 1kB/s, simply by sleeping before doing
the next read(3).  This means that some bandwidth may go to waste, but
in a network with heterogenous pipes it's probably impossible to avoid
that without routers that respect QoS tags.

That could be generalized into a socket proxy (either a redirector or an
HTTP proxy) that applies throttling criteria to the packets it forwards.

Does that make sense?

-- 
 /\\\  Mincom | Martin Pool          | martinp at mincom.com
// \\\        | Software Engineer    | Phone: +61 7 3303-3333
\\ ///        | Mincom Ltd.          | 
 \///         | Teneriffe, Brisbane  | Speaking for myself only

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