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/