[2077] in linux-net channel archive
Re: Project: Balancing load between PPP connections
daemon@ATHENA.MIT.EDU (Alan Cox)
Thu Mar 14 04:27:52 1996
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
To: linux-net@vger.rutgers.edu
Date: Wed, 13 Mar 1996 18:56:22 +0000 (GMT)
In-Reply-To: <199603130327.TAA02384@costello.longyear.com> from "Al Longyear" at Mar 12, 96 07:27:12 pm
> Unfortunately, most systems are based upon the BSD networking and are
> broken as it relates to this issue. All frames have the same priority
> for those systems, whether they are ftp-data or telnet frames.
To be fair this is broken application layer not kernel layer code on the
whole. BSD has had good IPTOS_* support for a long long time.
> remote system. It is a variation on the 'delayed ACK' sequence. If
> Linux delayed the acknowledgment for the frames for, oh say, 100
> msec. then the remote system would not send the frames as fast as it
> does since it sends a frame only upon the receiption of the ACK for
> the last one, assuming that the window is full.
There are two window values on a TCP, the "window" is the advertised value.
However a second internally computed value kept by the sender is the
congestion window. This is how big a window can actually be used (by
experience and occasionally tripping over the limit) before data is lost,
and that is in effect what represents the number of bytes that fit in the
buffers of all devices between source/destination.
> I believe that the delayed ACK messages is on Alan's list of things to
> be done for Linux. You should get in touch with him about the status
> and what needs to be done.
Pedro Roque beat me to it. His ack code is already in, although its caused
a few glitches and 1.3.72 could get a bit ack happy. 1.3.73 is better but
something somewhere isnt quite 100%.
> the PPP driver, I am against holding off ACK messages in the PPP
> driver. This logic belongs in the networking layer __only__. The PPP
> driver is just that, a network device driver. It must send the frame
> as quickly as possible using the hardware it controls. It should not
> make a determination of the frame and somehow defer its transmission
> just because frames are coming in 'too quickly' as that makes it
> something other than a driver.
Holding off an ack will actually not help. The congestion window will simply
become larger because you are buffering more data before replying.
> Ok. However, your changes must be to the networking code and not the
> device drivers.
> Good luck. (I mean that in the serious concept. I have faith in you. We
> do need this logic.)
The biggest problem is receiving. It is easy to bound the sending problem
because you are in control. There is little you can do on the receiving side
except cause repeated pipe stalls by offering a ludicrously small window.
This is sometimes done on very lossy networks for other reasons and is
possible on linux (eg ax25 people often do
route add -net 44.0.0.0 gw whatever window 432
).
There are other fairly new techniques that should help if used at the sending
end such as the Vegas flow rate based flow control.
Alan
