Re: [LARTC] Re: More on qdiscs - about dangling backlogs

[Patrick McHardy <kaber@trash.net>]

Hi !
Don Cohen wrote:
> 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.

I don't think this is a good example.
Why use SFQ for only SYNs ? For each connection (flow) only one SYN is 
going to get enqueued. SFQ distributes available bandwidth equal between 
flows if it the queue becomes full. Now, if each flow just consists of 
one packet it's basically the same like fifo with higher overhead.
What if the Synflood lasts longer / your connection request happens 
during the synflood ? It will expire like the others.
Syncookies provide a much better protection against synfloods, you won't 
have to wait at all.

>    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.

I think maybe we misunderstood.
What i want to achieve is that flows respond more quickly to changes in 
available bandwidth. I assume that i am the bottleneck, otherwise it 
wouldn't make much sense at all. You write "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.". If we leave packets dropped on the path 
to us for reasons besides congestion out of sight it's unlikely that we 
drop a packet that would have generated a duplicate ack earlier. After 
all, we are the bottleneck so we control packet drops. Also, i don't 
want to generate a non-duplicate ACK, i want to tell the remote LESS 
bandwidth is available.


>  > 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?

I don't want to drop unneccasary much. If i drop the first one, the 
sender will receive notification of congestion as soon as possible and 
slow down. But i haven't put very much thought in this so it will 
probably not work like this.

Bye,
Patrick

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/