* [LARTC] Shaping Incoming Traffic
@ 2000-11-16 20:09 John
2000-11-17 8:42 `
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: John @ 2000-11-16 20:09 UTC (permalink / raw)
To: lartc
<PRE>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.
</PRE>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [LARTC] Shaping Incoming Traffic
2000-11-16 20:09 [LARTC] Shaping Incoming Traffic John
@ 2000-11-17 8:42 `
2000-11-17 12:53 ` Gregory
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: @ 2000-11-17 8:42 UTC (permalink / raw)
To: lartc
<PRE>At 20:09 2000-11-16 +0000, you wrote:
><i>Is there no way to shape incoming traffic? With any kernel version, or
</I>><i>even by rewriting the networking code? I understand the difficulties, and
</I>><i>the reasons why outgoing shaping is simple at the low-level but incoming
</I>><i>shaping is not done even at the high-level, but what about this? Use the
</I>><i>TCP window field to restrict the rate of data transfer (not worrying about
</I>><i>the details right now; just the general feasibility). (This is for a
</I>><i>single box, rather than for a box on a network which has a separate router
</I>><i>to shape its traffic.) If a node were to consistently violate the window,
</I>><i>it could be blocked until the administrator fixed the problem at that
</I>><i>node. (This is intended for thsoe who do not intend to violate the
</I>><i>policies of the server, rather than those who may wish to do so
</I>><i>maliciously.)
</I>><i>
</I>><i>I'd just like some pointers and hints for this...it seems workable to me.
</I>><i>But if there is another way, or *any* way, I'd rather pursue that before
</I>><i>the TCP way so I can see which is better. I'm simply discouraged by the
</I>><i>fact that no one seems to have tried this before, while it seems a
</I>><i>painfully obvious way to do it to me, so I wonder what I'm missing
</I>><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.
><i>From the README:
</I>
><i> THEORY OF OPERATION
</I>><i> ===================
</I>><i>
</I>><i>The idea is easy: whenever a packet is received through a network
</I>><i>interface, the rshaper module delays notification of the packet to the
</I>><i>network subsystem of Linux according to the expected data flow for the
</I>><i>involved host.
</I>><i>
</I>><i>In order to delay reception of the packet, the network driver must be
</I>><i>modified to call the shaper's receive function instead of the standard
</I>><i>netif_rx(). Therefore, you must modify two lines of your network
</I>><i>device driver. In case you use a NE2000 clone or another 8390-based
</I>><i>ethernet device, you can use the patch included in this package as
</I>><i>"8390-X.Y.c.patch", where X.Y is your kernel versione (as of now are
</I>><i>supported versions 2.0 and 2.2). If you are new to patches, please
</I>><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>
><i>Introduction
</I>><i>
</I>><i> A gateway may discard Internet datagrams if it does not have the
</I>><i> buffer space needed to queue the datagrams for output to the next
</I>><i> network on the route to the destination network. If a gateway
</I>><i> discards a datagram, it may send a source quench message to the
</I>><i> Internet source host of the datagram. A destination host may also
</I>><i> send a source quench message if datagrams arrive too fast to be
</I>><i> processed. The source quench message is a request to the host to cut
</I>><i> back the rate at which it is sending traffic to the Internet
</I>><i> destination. The gateway may send a source quench message for every
</I>><i> message that it discards. On receipt of a source quench message, the
</I>><i> source host should cut back the rate at which it is sending traffic
</I>><i> to the specified destination until it no longer receives source
</I>><i> quench messages from the gateway. The source host can then gradually
</I>><i> increase the rate at which it sends traffic to the destination until
</I>><i> it again receives source quench messages [1,2].
</I>><i>
</I>><i> The gateway or host may send the source quench message when it
</I>><i> approaches its capacity limit rather than waiting until the capacity
</I>><i> is exceeded. This means that the data datagram which triggered the
</I>><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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [LARTC] Shaping Incoming Traffic
2000-11-16 20:09 [LARTC] Shaping Incoming Traffic John
2000-11-17 8:42 `
@ 2000-11-17 12:53 ` Gregory
2000-11-24 15:38 ` [LARTC] shaping incoming traffic steeman
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Gregory @ 2000-11-17 12:53 UTC (permalink / raw)
To: lartc
<PRE>Since systems are now begining to support ECN (i.e. Linux 2.4), has anyone
thought of abusing ECN for ingress policing?
</PRE>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [LARTC] shaping incoming traffic
2000-11-16 20:09 [LARTC] Shaping Incoming Traffic John
2000-11-17 8:42 `
2000-11-17 12:53 ` Gregory
@ 2000-11-24 15:38 ` steeman
2003-02-11 17:03 ` [LARTC] Shaping " Andreas Wright
2003-02-11 18:11 ` Stef Coene
4 siblings, 0 replies; 6+ messages in thread
From: steeman @ 2000-11-24 15:38 UTC (permalink / raw)
To: lartc
<PRE>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\x10.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: <A HREF="mailto:philip.steeman@kh.khbo.be">philip.steeman@kh.khbo.be</A>
Belgium
</PRE>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [LARTC] Shaping incoming traffic
2000-11-16 20:09 [LARTC] Shaping Incoming Traffic John
` (2 preceding siblings ...)
2000-11-24 15:38 ` [LARTC] shaping incoming traffic steeman
@ 2003-02-11 17:03 ` Andreas Wright
2003-02-11 18:11 ` Stef Coene
4 siblings, 0 replies; 6+ messages in thread
From: Andreas Wright @ 2003-02-11 17:03 UTC (permalink / raw)
To: lartc
[-- Attachment #1: Type: text/plain, Size: 583 bytes --]
Hello ,
I would like to know if it is possible to do the following ?
To give priority to incoming IP packets from a specific source (IP address).For example I have packets coming in through an interface eth1 going to higher layer application on the same machine. I want to give priority to packets coming from 1.2.3.4 and maybe drop packets from other address at high data rates.
Can we do this using ingress or some other qdisc ?
Best Regards,
Andreas.
---------------------------------
With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs
[-- Attachment #2: Type: text/html, Size: 747 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [LARTC] Shaping incoming traffic
2000-11-16 20:09 [LARTC] Shaping Incoming Traffic John
` (3 preceding siblings ...)
2003-02-11 17:03 ` [LARTC] Shaping " Andreas Wright
@ 2003-02-11 18:11 ` Stef Coene
4 siblings, 0 replies; 6+ messages in thread
From: Stef Coene @ 2003-02-11 18:11 UTC (permalink / raw)
To: lartc
On Tuesday 11 February 2003 18:03, Andreas Wright wrote:
> Hello ,
>
> I would like to know if it is possible to do the following ?
>
> To give priority to incoming IP packets from a specific source (IP
> address).For example I have packets coming in through an interface eth1
> going to higher layer application on the same machine. I want to give
> priority to packets coming from 1.2.3.4 and maybe drop packets from other
> address at high data rates.
>
> Can we do this using ingress or some other qdisc ?
With ingress, you can only rate limit certain packets.
But you can use the imq device. You need to patch iptables and the kernel.
After that, you can redirect all incoming packets to this virtual device and
use an egress qdisc to shape the traffic.
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-02-11 18:11 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-11-16 20:09 [LARTC] Shaping Incoming Traffic John
2000-11-17 8:42 `
2000-11-17 12:53 ` Gregory
2000-11-24 15:38 ` [LARTC] shaping incoming traffic steeman
2003-02-11 17:03 ` [LARTC] Shaping " Andreas Wright
2003-02-11 18:11 ` Stef Coene
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.