Is there no way to shape incoming traffic? With any kernel version, or even by rewriting the networking code? I understand the difficulties, and the reasons why outgoing shaping is simple at the low-level but incoming shaping is not done even at the high-level, but what about this? Use the TCP window field to restrict the rate of data transfer (not worrying about the details right now; just the general feasibility). (This is for a single box, rather than for a box on a network which has a separate router to shape its traffic.) If a node were to consistently violate the window, it could be blocked until the administrator fixed the problem at that node. (This is intended for thsoe who do not intend to violate the policies of the server, rather than those who may wish to do so maliciously.) I''d just like some pointers and hints for this...it seems workable to me. But if there is another way, or *any* way, I''d rather pursue that before the TCP way so I can see which is better. I''m simply discouraged by the fact that no one seems to have tried this before, while it seems a painfully obvious way to do it to me, so I wonder what I''m missing conceptually.
At 20:09 2000-11-16 +0000, you wrote:>Is there no way to shape incoming traffic? With any kernel version, or >even by rewriting the networking code? I understand the difficulties, and >the reasons why outgoing shaping is simple at the low-level but incoming >shaping is not done even at the high-level, but what about this? Use the >TCP window field to restrict the rate of data transfer (not worrying about >the details right now; just the general feasibility). (This is for a >single box, rather than for a box on a network which has a separate router >to shape its traffic.) If a node were to consistently violate the window, >it could be blocked until the administrator fixed the problem at that >node. (This is intended for thsoe who do not intend to violate the >policies of the server, rather than those who may wish to do so >maliciously.) > >I''d just like some pointers and hints for this...it seems workable to me. >But if there is another way, or *any* way, I''d rather pursue that before >the TCP way so I can see which is better. I''m simply discouraged by the >fact that no one seems to have tried this before, while it seems a >painfully obvious way to do it to me, so I wonder what I''m missing >conceptually.Try http://freshmeat.net/projects/rshaper/?highlight=rshaper for rshaper. I haven''t tried it myself, but they use a metod where they delay the notification of received packets to the sending host. From the README:> THEORY OF OPERATION > ==================> >The idea is easy: whenever a packet is received through a network >interface, the rshaper module delays notification of the packet to the >network subsystem of Linux according to the expected data flow for the >involved host. > >In order to delay reception of the packet, the network driver must be >modified to call the shaper''s receive function instead of the standard >netif_rx(). Therefore, you must modify two lines of your network >device driver. In case you use a NE2000 clone or another 8390-based >ethernet device, you can use the patch included in this package as >"8390-X.Y.c.patch", where X.Y is your kernel versione (as of now are >supported versions 2.0 and 2.2). If you are new to patches, please >refer to the last section.Another method would be to use ICMP source quench: http://www.faqs.org/rfcs/rfc1016.html>Introduction > > A gateway may discard Internet datagrams if it does not have the > buffer space needed to queue the datagrams for output to the next > network on the route to the destination network. If a gateway > discards a datagram, it may send a source quench message to the > Internet source host of the datagram. A destination host may also > send a source quench message if datagrams arrive too fast to be > processed. The source quench message is a request to the host to cut > back the rate at which it is sending traffic to the Internet > destination. The gateway may send a source quench message for every > message that it discards. On receipt of a source quench message, the > source host should cut back the rate at which it is sending traffic > to the specified destination until it no longer receives source > quench messages from the gateway. The source host can then gradually > increase the rate at which it sends traffic to the destination until > it again receives source quench messages [1,2]. > > The gateway or host may send the source quench message when it > approaches its capacity limit rather than waiting until the capacity > is exceeded. This means that the data datagram which triggered the > source quench message may be delivered.I''m not aware of any implementation of this method for Linux that would suite your needs. Cisco has shaping both for incoming and outgoing traffic. See www.cisco.com for mor info. /Fredrik __________________________________________________________________________ Fredrik Björk Seaside Internet/Varberg Energi Fredrik.Bjork@seaside.se
I have used rshaper and it works fine. You may also look at "ingres". If you do, see the discussions about ingress on the "Linux-Diffserv" mailing list http://icawww1.epfl.ch/linux-diffserv/. Regards Daniel Från: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl]För Fredrik Björk At 20:09 2000-11-16 +0000, you wrote:>Is there no way to shape incoming traffic?Try http://freshmeat.net/projects/rshaper/?highlight=rshaper for rshaper. I haven''t tried it myself, but they use a metod where they delay the notification of received packets to the sending host. /Fredrik __________________________________________________________________________ Fredrik Björk Seaside Internet/Varberg Energi Fredrik.Bjork@seaside.se _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/
Since systems are now begining to support ECN (i.e. Linux 2.4), has anyone thought of abusing ECN for ingress policing?
I''m just learning to use QOS, and it seems very powerfull.
Can some-one give me a hint what to do for the following (simplified) problem.
128kbit +------+ 10Mb +----------+ 10Mb
provider-------------+router+--------+linux-masq+------------ internal network
+------+ +----------+
eth0 eth1=10.1.14.1
The only thing I can change things on, is the linux-computer.
This computer is a masquerading computer (I don''t know if this poses
problems?)
The problem:
On the internal network all the students are downloading as fast(slow) as
they can.
So the incoming traffic is almost 100%.
The outgoing traffic is very low (max 20%).
Someone in our library wants to telnet from an inside computer to an
outside computer. This works extreme slow (unworkable).
Is there a solution for this problem?
Thanks in advance,
Philip
-----------------------------------------------------------------------------
Philip Steeman tel: (+32)59 56 90 16
Zeedijk 101 fax: (+32)59 56 90 01
8400 Oostende E-mail: philip.steeman@kh.khbo.be
Belgium
Limit the outgoing traffic to the internal network (to the students). You
may start with a limit of 64kbit/s to the students.
Regards
Daniel
-----Ursprungligt meddelande-----
Från: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl]För
steeman philip
I''m just learning to use QOS, and it seems very powerfull.
Can some-one give me a hint what to do for the following (simplified)
problem.
128kbit +------+ 10Mb +----------+ 10Mb
provider-------------+router+--------+linux-masq+------------ internal
network
+------+ +----------+
eth0 eth1=10.1.14.1
The only thing I can change things on, is the linux-computer.
This computer is a masquerading computer (I don''t know if this poses
problems?)
The problem:
On the internal network all the students are downloading as fast(slow) as
they can.
So the incoming traffic is almost 100%.
The outgoing traffic is very low (max 20%).
Someone in our library wants to telnet from an inside computer to an
outside computer. This works extreme slow (unworkable).
Is there a solution for this problem?
Thanks in advance,
Philip