[LARTC] Shaping Incoming Traffic

<PRE>At 20:09 2000-11-16 +0000, you wrote:
&gt;<i>Is there no way to shape incoming traffic? With any kernel version, or
</I>&gt;<i>even by rewriting the networking code? I understand the difficulties, and
</I>&gt;<i>the reasons why outgoing shaping is simple at the low-level but incoming
</I>&gt;<i>shaping is not done even at the high-level, but what about this? Use the
</I>&gt;<i>TCP window field to restrict the rate of data transfer (not worrying about
</I>&gt;<i>the details right now; just the general feasibility). (This is for a
</I>&gt;<i>single box, rather than for a box on a network which has a separate router
</I>&gt;<i>to shape its traffic.) If a node were to consistently violate the window,
</I>&gt;<i>it could be blocked until the administrator fixed the problem at that
</I>&gt;<i>node. (This is intended for thsoe who do not intend to violate the
</I>&gt;<i>policies of the server, rather than those who may wish to do so
</I>&gt;<i>maliciously.)
</I>&gt;<i>
</I>&gt;<i>I'd just like some pointers and hints for this...it seems workable to me.
</I>&gt;<i>But if there is another way, or *any* way, I'd rather pursue that before
</I>&gt;<i>the TCP way so I can see which is better. I'm simply discouraged by the
</I>&gt;<i>fact that no one seems to have tried this before, while it seems a
</I>&gt;<i>painfully obvious way to do it to me, so I wonder what I'm missing
</I>&gt;<i>conceptually.
</I>
Try
<A HREF="http://freshmeat.net/projects/rshaper/?highlight=rshaper">http://freshmeat.net/projects/rshaper/?highlight=rshaper</A>
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.

&gt;<i>From the README:
</I>
&gt;<i>                THEORY OF OPERATION
</I>&gt;<i>                ===================
</I>&gt;<i>
</I>&gt;<i>The  idea is easy:  whenever  a packet is   received through a network
</I>&gt;<i>interface, the rshaper module delays notification of the packet to the
</I>&gt;<i>network subsystem of Linux according to the expected data flow for the
</I>&gt;<i>involved host.
</I>&gt;<i>
</I>&gt;<i>In order to delay reception of  the packet, the network driver must be
</I>&gt;<i>modified to call the shaper's receive function instead of the standard
</I>&gt;<i>netif_rx().   Therefore, you  must modify  two lines  of  your network
</I>&gt;<i>device driver.  In  case you use a NE2000  clone or another 8390-based
</I>&gt;<i>ethernet device,  you can  use the patch  included in this  package as
</I>&gt;<i>&quot;8390-X.Y.c.patch&quot;, where X.Y  is your kernel versione (as  of now are
</I>&gt;<i>supported versions  2.0 and  2.2). If you  are new to  patches, please
</I>&gt;<i>refer to the last section.
</I>
Another method would be to use ICMP source quench:

<A HREF="http://www.faqs.org/rfcs/rfc1016.html">http://www.faqs.org/rfcs/rfc1016.html</A>

&gt;<i>Introduction
</I>&gt;<i>
</I>&gt;<i>   A gateway may discard Internet datagrams if it does not have the
</I>&gt;<i>   buffer space needed to queue the datagrams for output to the next
</I>&gt;<i>   network on the route to the destination network.  If a gateway
</I>&gt;<i>   discards a datagram, it may send a source quench message to the
</I>&gt;<i>   Internet source host of the datagram.  A destination host may also
</I>&gt;<i>   send a source quench message if datagrams arrive too fast to be
</I>&gt;<i>   processed.  The source quench message is a request to the host to cut
</I>&gt;<i>   back the rate at which it is sending traffic to the Internet
</I>&gt;<i>   destination.  The gateway may send a source quench message for every
</I>&gt;<i>   message that it discards.  On receipt of a source quench message, the
</I>&gt;<i>   source host should cut back the rate at which it is sending traffic
</I>&gt;<i>   to the specified destination until it no longer receives source
</I>&gt;<i>   quench messages from the gateway.  The source host can then gradually
</I>&gt;<i>   increase the rate at which it sends traffic to the destination until
</I>&gt;<i>   it again receives source quench messages [1,2].
</I>&gt;<i>
</I>&gt;<i>   The gateway or host may send the source quench message when it
</I>&gt;<i>   approaches its capacity limit rather than waiting until the capacity
</I>&gt;<i>   is exceeded.  This means that the data datagram which triggered the
</I>&gt;<i>   source quench message may be delivered.
</I>
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   <A HREF="mailto:Fredrik.Bjork@seaside.se">Fredrik.Bjork@seaside.se</A>


</PRE>