> > I suppose SFQ could still do something like above even if HTB were > > dropping expired packets at dequeue. And this would save all qdiscs > > the work of dropping expired packets at dequeue, which is still needed > > even if you also check at enqueue. Also, only dropping at dequeue is > > a good approximation to what you want in the common case where the > > queue size is too large for the low rate assigned to the class. I > > argue it's much better to do this in a few classful qdiscs than to ask > > for it to be done by all the others. > > I hope i got you right, here are my thoughts on this: > > I don't think dropping at dequeue is necessary. The goal is not to provide > a maximum in-queue time, if the qdisc is able to send there is no reason > to drop. The problem is if the qdisc is not able to send many packets > can get queued until drops occur. This means it takes a long time until > the sender receives indication of congestion. For TCP, congestion is > indicated by either consequent ACKS with the same ACK number or SACKs. > ACKs are only generated by the receiver if something was actualy > received, so by dropping packets after some timeout the time until a > duplicate ACK is generated becomes smaller. IIRC the congestion is also indicated by not recieving ACK for some period (2*RTT is initial IIRC). So that when packet is delayed too much TCP treats it as drop and sends dupliocate ACK requesting whole prev. segment ... > If you assume the expiration time to be smaller than the time requried > to fill the senders congestion window, it doesn't makes sense anymore to > drop packets during dequeue as this could possibly prevent a duplicate > ACK from beeing generated -> relay indication of congestion. right. > It sounds better to me to check for expired packets during enqueue > (timers would probably be too expensive i guess) and drop them before > enqueueing the new packet. exactly :) > With SFQ, what about not keeping a per-packet timeout but a per-flow > congestion-indication timeout which would drop the first packet of a > flow after max(age of any packet from this flow) >= timeout ? This would > assure congestion indication to be delivered to the sender as soon as > the flow is chosen to send again after the timeout occured (as long as > qlen(flow) > 1 which is probably the case). Maybe I don't remember some RFC correctly but ACKs with info about congestion are sent in reverse direction .. (?) But I still think that if ever do this machinery that it should be done at bot enqueue and dequeue time. Don Cohen is right in thing that in dequeue it'd be simpler to implement (at least for testing). devik
