All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] idea...
@ 2002-12-23 20:22 Radoslaw Stachowiak
  2002-12-24 16:43 ` Patrick McHardy
  0 siblings, 1 reply; 2+ messages in thread
From: Radoslaw Stachowiak @ 2002-12-23 20:22 UTC (permalink / raw)
  To: lartc

as we all know, we can shape only outgoing traffic.
we can, of course, use IMQ or other drop-type shaping on incoming
interface but it has some pitfalls, to name few:
.. it relies on fact that upper layers (mostly TCP) can and will handle
accordingly to dropped packets
.. its waste of bandwith, because dropping packet which is already
delivered to us does not save our pipe (unless tcp/etc starts acting)

this is classic problem of two interface router.

small ascii:   (internet)---(ppp0)router(eth0)---(lan)

And here goes my idea:
to write a qdisc which is applied to _outgoing_ traffic on ppp0 which
acts on tcp only packets, namely ACKs, dropping and/or modyfing their
content to faster 'inform' sending side (internet) about bottleneck.
classic shaping does not work as this packet flow is relativly small
(acks). Such qdisc has to investigate content of packets, so im not sure
if it can be done in classical (qdisc) way, or if its rather a task for a netfilter
family.

Please share Your thoughts on this idea. TIA.


	.radek.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [LARTC] idea...
  2002-12-23 20:22 [LARTC] idea Radoslaw Stachowiak
@ 2002-12-24 16:43 ` Patrick McHardy
  0 siblings, 0 replies; 2+ messages in thread
From: Patrick McHardy @ 2002-12-24 16:43 UTC (permalink / raw)
  To: lartc

Hi,

On Mon, 23 Dec 2002, Radoslaw Stachowiak wrote:

> as we all know, we can shape only outgoing traffic.
> we can, of course, use IMQ or other drop-type shaping on incoming
> interface but it has some pitfalls, to name few:
> .. it relies on fact that upper layers (mostly TCP) can and will handle
> accordingly to dropped packets
> .. its waste of bandwith, because dropping packet which is already
> delivered to us does not save our pipe (unless tcp/etc starts acting)

Unfortunately, this is true.

> 
> this is classic problem of two interface router.
> 
> small ascii:   (internet)---(ppp0)router(eth0)---(lan)
> 
> And here goes my idea:
> to write a qdisc which is applied to _outgoing_ traffic on ppp0 which
> acts on tcp only packets, namely ACKs, dropping and/or modyfing their
> content to faster 'inform' sending side (internet) about bottleneck.
> classic shaping does not work as this packet flow is relativly small
> (acks). Such qdisc has to investigate content of packets, so im not sure
> if it can be done in classical (qdisc) way, or if its rather a task for a netfilter
> family.
> 

I'm doing something very simliar to your idea, basically a qdisc which 
uses the Ideas of TCP Rate Control (modifiy window size and ack rate) to 
control _incoming_ tcp rates. It is very, very accurat and doesn't waste a 
bit because nothing has to be thrown away. It has higher computantional 
overhead than f.e. htb because it has to keep per-flow state. My 
particular implementation uses ip_conntrack which will be running in many 
cases anyway. It is not finished yet, mostly because its realy time 
consuming and i don't have that much time. My implmentation is still 
missing one of the most important parts, namely accurat prediction of how 
fast a flow would go without rate control. this is required because with 
rate control, you have to decide how much bandwidth to allocate to a flow 
_in advance_ and it won't go faster that this. this means you really want 
to have a good prediction how fast it could go.
despite this, it is quite "useable", non-tcp traffic is handled by a 
fallback tocken bucket policer. It works for both in- and egress.
I haven`t worked on it for almost two month now, but if someone is 
interested in helping out i would be glad to finish it as soon as 
possible.

Bye,
Patrick

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2002-12-24 16:43 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-23 20:22 [LARTC] idea Radoslaw Stachowiak
2002-12-24 16:43 ` Patrick McHardy

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.