[2065] in linux-net channel archive
Re: Project: Balancing load between PPP connections
daemon@ATHENA.MIT.EDU (Al Longyear)
Wed Mar 13 23:36:30 1996
To: snowcat@math.csufresno.edu (Snow Cat)
Date: Wed, 13 Mar 1996 16:09:32 -0800 (PST)
From: "Al Longyear" <longyear@netcom.com>
Cc: linux-net@vger.rutgers.edu
In-Reply-To: <199603132301.PAA02200@ariel.math.CSUFresno.EDU> from "Snow Cat" at Mar 13, 96 03:01:26 pm
Snow Cat wrote:
>
> I wrote:
>
> > Linux supports the prioritization of IP frames with the firewall
> > code. You can change the priority of the frames as they flow through
> > your system on the way outside.
> >
> > What you can not change is the priority of the frames outside your
> > system as they flow into your firewall. Those frames have originated
> > at the remote system, somewhere on the Internet. It is that system's
> > responsibility to assign the frames the proper priority.
> >
> > 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.
>
> Sure, but what if ppp driver on the other side of the link assigns priority
> to frames to or from a certain port? It would be hard for us to have Sun and
> NeXT release their kernel under GPL so that we can fix the problem in the
> right place :)
Huh? What difference does that make? Once you have received the frame
then you have received the frame. There is nothing that you can, nor
should, do to 'un-receive' the frame.
If you want to assign a priority on your out-bound frames based solely
upon a port address, use the 1.3 firewall tools to do that.
If you run most any of the Linux clients or servers, there is no need
to do this. The clients support the priority assignments. (I believe
that the last time that I checked, the only hold out was ncftp. That
was changed many, many months ago -- I sent Mr. Gleason the patches
myself.)
The problem that you need to solve is that you want to have the remote
system suspend sending you the frame in the first place. Given that
you don't need 'source quench' for the reasons that I stated in the
last message, the only way that you can throttle the remote system is
to defer sending it the message that you have received the ACK.
Of course, since ACKs are sent end-to-end, if your system is simply
the router in the middle then there is nothing that you can really do
about the situation since you wont be sending the ACK in the first
place. In that case, you will have to simply live with the situation.
There is nothing that you can do about it short of getting a bigger
pipe.
However, the majority of users are complaining about their running a
single workstation connected to the Internet via PPP or SLIP. When
they start a FTP transfer, the transfer consumes the majority of the
bandwidth as it is designed to do given the priorities of the frames.
In this case, where the destination IP address is the single Linux
system then it sends the ACK frames. The delayed ACK messages are
about the only thing that you can do to control the flow coming into
your system.
Alan is correct. There is no real way to unblock a buffer in the peer
system's modem. Once it fills the buffer, further frames will be held
in the order by which that system queues the frames. This means that
all of the frames from that point until the modem clears the throttle
condition, will be held; regardless of the urgency or priority of the
frame.
Someone once thought that he would flush the buffers in the modem by
causing the modem to be overrun, send the PPP DLE/FLAG (called the
ABORT condition) and then transmit the high priority frames. It did
not work and the idea was abandoned. He forgot that the modems will
retrain at that time and may decide that they have performed this too
often and disconnect the telephone line.
Don't assume that having the TOS field in the IP header set correctly
will have an effect. There are far too many systems which are based
upon the BSD 4.3 "reno" release which totally ignore the TOS field
since they don't generate them. For those systems, which is probably
the bulk of the BSD systems out in the world, the only prioritization
is a simple FIFO. It wasn't until BSD 4.4 that BSD supported the TOS
field.
> Is there any documentation for Linux networking code
> and/or drivers?
The only 'documentation' is the source code.
--
Al Longyear longyear@netcom.com longyear@sii.com
Finger longyear@netcom.com for PGP public key.
