Tuesday, July 29, 2003, 11:42:31 PM, Ed White wrote: > On Tuesday 29 July 2003 17:22, Alexey E. Suslikov wrote: >> >slowing down the outgoing tcp acks etc slows down usual downloads tho. > Exact. > The trick explained works perfectly and does exactly what is described to do. > The target was to shape _download_bandwidth_ and it can be done pretty well > working on upload filtering rules . >> :) of course not. the goal of my example is to show, "how >> priorizing of incoming traffic not work" :) > Wrong. > I suggested to work on _upload_ queque for each box. > [download queque] internet ---> box > [upload queque] internet <--- box
i have got your example, but you don't want to get my :) ok, you have outbound mapped to appropriate queues accordingly to host based model. and yes, your shaper will work. but such incoming traffic was initiated by outbound from your side, so your box know how to shape. my example shows different case: we also have incoming, but initiated from outside of your box. how to shape in this case? and it is not about normal tcp connection, which can be slowed down by delaying ACKs or by ECN. this is about flooding, for example, by SYN-flood coming to you on the full width of your pipe. your pf is safe, thanks to state limit or adaptive timeouts. but your box is still have this junk on physical interface. all what i want to know "how to shape this"... so, Ed, there is no doubt about your trick: it is correct. i just want to show what "not any incoming traffic can be shaped" due protocol implementation limits, because we don't have ability to tell uplink's hardware or software "xxx.xxx.xxx.xxx/x are DDoSing me! so block them out!" :)
