Don Cohen wrote: > > > I like those, but also suggested that HTB would be a good place to add > > > code for dropping stale packets. If you're interested in doing that I > > > should mention: > > > Not all packets come with timestamps (e.g., locally generated ones). > > > Solution: at enqueue, if the timestamp is 0, set it to the current > > > time. > > > > It would be better done in fifo/sfq. It is because HTB can do it > > only when dequeuing and at that time some packets were already dropped > > by SFQ because if has had queues full of "old" packets. > > I see, you suggest that I could do better if enqueue started with > something like > while (oldest packet expired) drop oldest packet > Of course this is still only an approximation. There will still be > times when you have to drop a packet but it turns out that, before the > next one is dequeued another packet will have expired (so if you only > knew that you could have saved the packet you dropped before). > > > SFQ should maintain pqio queue of all packets and look at head of > > the list sometimes to keep its queues frre of old packets and thus > > to have room for new ones. > > 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. 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. 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. 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). Bye, Patrick
