lkml.org 
[lkml]   [1996]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Project: Balancing load between PPP connections
    Date
    From
    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.




    \
     
     \ /
      Last update: 2005-03-22 13:36    [W:0.025 / U:30.496 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site