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
