Patrick McHardy writes:
> I don't think dropping at dequeue is necessary.
Here's an example showing it is.
I have an SFQ with max queue size 128 and very low rate, say about
1 packet/sec that I use to limit the rate of SYN's.
Now as part of a test I send a syn flood, say 200 packets in one
second. In that first second SFQ drops 200-128 but the time limit
won't drop any more on enqueue. Now we're sending one packet/sec
and I try to open a tcp connection.
Suppose the age limit is 5 sec. and we drop on enqueue only.
If I try to open the tcp connection 3 sec after the flood, none of the
124 or so packets in the queue has expired and it's going to take 2
min. for my syn to get through. Whereas, if dequeue drops expired
packets then I can get through in 2 sec.
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 reason to drop is that it's a waste of time/bandwidth to send
expired packets, and even worse to make something unexpired wait for
them (and even worse yet if it has to wait long enough to expire
itself).
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.
In this case tcp should stop cause it doesn't get any acks cause its
packets are not getting forwarded. Or if the problem is the other
direction, it should stop cause it's not getting the acks.
> 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.
I think now we're getting into the subject of why it's good to
drop packets that have been waiting for a long time.
If your objective is to generate a duplicate ack then I'm not sure
dropping packets is the right way. After all, you might drop a packet
that would have generated one sooner. For that matter, you might have
dropped one that would have generated a non-duplicate ack, which would
be even better for tcp. Nevertheless, I do think it's good to drop
packets that are not forwarded in a timely fashion. It's just not a
simple argument.
> 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.
I'm not sure what you have in mind for the check here.
I was expecting that no packets would actually take a long time
between being received/generated and being enqueued. Rather, when you
enqueue one, you can look in the queue to find any others that have
been in the queue too long. But this does not catch as many cases as
checking at dequeue.
I was not proposing to set any timers. Just record the time the packet
arrives and when you dequeue, see how long ago that was.
> 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).
I don't think I understand what you're proposing. If we enqueue 50
packets from one flow all at once, and after sending 10 they all
expire (since they're all about the same age), then you want to drop
one? Why is it worth sending the rest?
