Messages in this thread | | | Subject | Re: Project: Balancing load between PPP connections | Date | Tue, 12 Mar 1996 19:27:12 -0800 (PST) | From | "Al Longyear" <> |
| |
Oleg, and everyone else, please don't use the kernel mail list for serious issues as this. There is a linux-net@vger.rutgers.edu list for networking issues. The kernel list is too populated these days with the current critical issue of "What do we call Linux?" or the parentage of Mr. Stallman.
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.
| |