[2106] in linux-net channel archive
Re: Project: Balancing load between PPP connections
daemon@ATHENA.MIT.EDU (Avery Pennarun)
Fri Mar 15 01:12:02 1996
Date: Thu, 14 Mar 1996 23:50:47 -0500 (EST)
From: Avery Pennarun <apenwarr@foxnet.net>
To: Al Longyear <longyear@netcom.com>
cc: linux-net@vger.rutgers.edu
In-Reply-To: <199603140009.QAA00429@costello.longyear.com>
This discussion interests me because the solution seems to obvious, yes no
one is mentioning it. Please flame me and tell me why I'm wrong :)
On Wed, 13 Mar 1996, Al Longyear wrote:
> > > 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.
It seems to me that the correct solution to the problem is not to "slow
down" one of the transfers (as that basically reduces bandwidth with no
noticeable advantage) but to make one connection "more important" than
another.
Let me explain with an example. I have a PPP connection from my home system
(freedom, 1.3.72) to a router (tbcentral) at my internet provider. On an
ethernet network with that router, there is a Linux box (insanity, also
running 1.3.72) that I use.
I open two connections from freedom to insanity: an ftp "get" and a telnet.
While the ftp runs, my telnet session slows to a crawl. Well, it isn't
technically _slow_, but it has a delay of 2-5 seconds behind my typing.
Because both ends of the connection are Linux 1.3.72 (and this has been
happening since the beginning of time, 1.3.20 or so was the first I tested)
we can't blame BSD networking. tcpdump from a "bystander" Linux box on the
same ethernet shows that my ftp and telnet packets have correct TOS values
going in both directions, so that should be fine.
(Aside: In fact, my telnet client didn't set TOS by default, but clever use
of IP firewalling on freedom allows me to set the TOS flag during initial
connection, and thus the telnet server on insanity retains the value for the
entire session. Setting TOS _did_ improve performance somewhat, though not
as much as I had hoped. Setting the TOS flag while making a connection to a
broken BSD machine doesn't work, though, as expected.)
Now back to the point of this: why is my telnet session not getting top
priority? tbcentral (the router) is a Telebit Netblazer, which may be
BSD-based, but compared to similar experiments with a Linux router it seems
to do a BETTER job.
It was my impression that a session set with IPTOS_LOWDELAY, ie. my telnet,
should have a "higher priority" than an ftp session. Seriously, this is
hardly useful unless it gets a MUCH higher priority.
On the other hand, I don't want my ftp to just be slow. If my telnet is
idle, then let the ftp go. The suggestions so far about excessively
delaying ACKs, not responding to packets, etc will certainly slow down the
ftp but more than anything will probably result in a less efficient transfer
because they don't depend on the activity of the other sessions. I think
this is attacking the wrong problem.
So what causes the lag? In such a simple example, the only thing I can
think of is a buildup of packets on the router, tbcentral. Insanity (the
server) should certainly have no trouble sending data as fast as it pleases
through the ethernet. If the router just forwards packets in the order
they're received, I will probably have to clear out 10k of ftp packets from
the queue before I can get my lousy 50 bytes of telnet.
That's what I thought IPTOS was for. If a packet with a higher priority,
say IPTOS_LOWDELAY, is in the buffer, it should supercede any low-priority
IPTOS_THROUGHPUT packets that are waiting (within reason - the ftp should
still get SOME time if the telnet goes crazy). Don't be silly like Al's
example of the person trying to flush the modem buffer; let any packets
finish that are already on their way (modems only have a 1k buffer anyway I
think) but make sure the telnet packet is the next one to go out.
Isn't that what IPTOS does already? If not, why not? If so, what do any
other routers en route (usually much faster than my 28.8k modem) have to do
with performance, and more importantly, what does the BSD-based
lack-of-IPTOS stuff even affect as long as I have some router along the way
set to change IPTOS of incoming packets automatically?
Have fun.
Avery
