> > Definitely it would be helpful to create work conserving model > > of CBQ (HTB :-)) which would drop packets instead to dequeue > > them. > > Won't help me I think. I don't have the need of hierarchies or fancy > prioritizations between different traffics or whatever, only to be able to > slow down (with a delay) some specific traffic destined for the local TCP. > > The filter police allows me to drop packets, but do not allow me to introduce > delays. > > TCP is generally too smart to be delayed proper by "randomly" dropped packets > without any signs in RTT. Especially when the RTT is small. Are you sure !? TCP slows down by half on every dropped packet per congestion window AFAIK. On other side it is often hard to slow TCP down by packet delay as TCP will try to accomodate it by making MSS larger. Am I right jamal ? > > > IMHO ingres queuing could be used as poor man's way how to reshape > > (or priorize) traffic which can't be shaped at egress side (usualy > > because of adminstrative boundaries). This need would vanish in > > presence of such classfull work conserving CBQ. > > And such a administrative boundary is the one I am playing on. The boundary > between a small customer and his ISP. The ISP obviously have the luxury of > egress, but the customer does not on traffic received by him. > > Exacly how would this need vanish? as I said above, packet dropping works well (at least for me in the same ISP scenario). When you are queuing then delay only helps you to postpone burst of reply data to some less used time. When bulk traffic persists, packet is droppes and TCP fallbacks down. devik
