lkml.org 
[lkml]   [1998]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: network nicety
Date
This is in IPv6.  Traffic prioritization.  There are boxes that sit in the
middle of you stream and mess with TCP streams to prioritize traffic.
Packeteer is one.

It is very hard to implement something like this. The data channel for ftp
has no real identification in it. The best way of doing this is in the
application.

---- As written by David Feuer:
> If this has been rejected or implemented before, please let me know,
> but....
>
> I am often frustrated that when I am running a network-intensive
> long-term process (generally a big FTP download), I get a big slowdown
> of burst-oriented interactive use (email, web browser, etc.). This is a
> particular problem since I am using a PPP connection. I have a couple
> ideas for solving this problem, and similar ones.
>
> First, I think that programs should have a netnice value (nnice?), along
> with a nice value. When transmitting packets, lower niceness processes
> (or threads.....) get higher priority. So if I were running a
> significant-use ftp server, I could set the netnice for my ftp server to
> 13, allowing other processes on my machine to have better
> responsiveness. Similarly, when using an ftp client to upload something
> big, I could set the netnice to 17 and keep on browsing. The best thing
> is that the performance of those big network transfers would not really
> go down much. They would just interfere less.
>
> This is only half a solution. It pretty much only solves sender-side
> problems. For home systems such as mine the big issue is receiver-end.
> When I am doing a big FTP download, web browsing often slows to a
> crawl. I was thinking that there might be some way to combine
> kernel-level changes with a modification of the pppd client+server to
> support some prioritization of the PPP link. I don't really know how
> this would work. It would be nice if I could set the nicety of a
> receiving program (ftp client, etc.), and have that tell the PPP server
> on the other end that it should make packets destined to ports owned by
> this process a low priority. One possibility would be to buffer them
> until there was network time (or their brief turn came around), and
> dropping their packets when the buffer is full.
>
> I think that some of these ideas (probably with huge modifications)
> could help improve Linux network performance.
> --
>
> Remove "NOSPAM" to reply.
> ______________________________
> / David Feuer \
> | dfeuer@NOSPAMbinx.mbhs.edu |
> | feuer@NOSPAMhis.com |
> | daf@morseNOSPAM.usno.navy.mil|
> \ david@NOSPAMfeuer.his.com /
> -----------------------------
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>


--
Robert Hajime Lanning Navigation Technologies
Unix Systems Administrator 740 E. Arques Ave.
(408) 617-5059 Sunnyvale, CA 94086
lanning@fhda.edu USA
lanning@kewltech.com lanning@navtech.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:44    [from the cache]
©2003-2011 Jasper Spaans