I have added a 'Reply-To:' header for the redirection.
Snow Cat wrote:
>
> Good evening,
>
> Is it just me, or does Linux PPP really supports only one connection
> at a time?
It is just you. I usually have mail and NTP and news going over the PPP link
to my portable when I connect. They are all occuring at the same relative
time.
> With Linux 1.3.72+PPP 2.2.0e, if I connect to a remote host
> that just keeps sending data (like rcp local_machine:/sdmach /tmp),
> netscape download in another window slows down to 30 bytes per second.
> I can't even use telnet at this speed :)
There are a few issues here.
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.
> Some observations:
>
> Looks like if a remote host is sending data too fast, Linux will do nothing
> to slow it down.
It can not. The frames are being received at a rate X. They are being
forwarded at a rate of 10X or 1000X if they go to your own
computer. As such, the Linux system does not need to quench the
flow. It is keeping up with the transfer at a very acceptable rate.
The fact that the remote system, which is beyond your control, is
flooding your pipe has little to do with the Linux system being able
to deliver the frames and everything to do with the 'problem' that you
are experiencing.
There is a mandatory piece of logic in the TCP layer commonly called
'slow start'. This is to prevent the overflow of a smaller pipe with
data faster than it can take it. However, it applies only when the
transfer is initiated. This means that if you start a ftp transfer and
then wish to do telnet, the ftp transfer will see that it has the
majority of the pipe and keep it at that level. The slow start
algorithm will actually prevent the telnet transfer from consuming
more than the initial amount of bandwidth.
> TCP/IP standard includes "Source Quench" messages for this
> purpose, why doesn't UNIX send and recieve them?
That wont help you for the reasons which I mentioned earlier. The
"Source Quench" is primarily used for routers or bridges which must
pass frames from one subnet to another. It is the router which sends
the "Source Quench" when it tosses the frame because it has run out of
memory to hold it.
> Also, if Linux doesn't
> acknowledge packets that are coming too fast, won't the other side assume
> that network is conjested and slow down?
You have hit upon the only thing that will make an impact on the
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.
However, there are some serious problems doing this. If you delay for
too long of a period then you run the risk of causing the remote
system's ACK timer to expire and cause it to send the frame
again. This means that you will receive double (or tipple) the amount
of traffic for the same amount of data with a suitable decrease in
both bandwidth and transfer rates.
The hold-off rate needs to be dynamic. It must adjust itself so that
you receive a uniform average flow for a given socket or system.
> Another solution would be to add priorities to traffic from selected ports,
> like term. When I used it, I was able to open an ftp session and a Mosaic
> window and trsh was still usable?
That is because it was term which was sending you the frames, not
ftp.cdrom.com (which runs BSD networking.) The term program could
adjust the priority because it was the sending system for all of your
data.
The current firewall code for the 1.3 series kernels supports the
priority adjustment. This will suffice for system on your side of the
network. If you want to adjust the flow rate for the systems on the
other side of the telephone line then you will have to look elsewhere,
possibly coming up with a scheme to delay the ACK messages.
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.
I agree with you. Linux ACKs frames far too quickly. However, there is
nothing that a device driver, such as PPP, should or would do about that.
As I was against putting the priority code for the out-bound frames in
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.
> Is anyone working in this direction? If not, I might dig out my networking
> books and give it a try.
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.)
-- Al Longyear longyear@netcom.com longyear@sii.com Finger longyear@netcom.com for PGP public key.