Yup, this is what my experiments are showing. I'm not doing head/tail drop, but, I am dropping/marking at the device before and after the bloated device. That would be counterclockwise or clockwise of the bloated (slow and overqueued) device. This is essentially the same thing.
What I am observing is that if I drop/mark after (clockwise) the system is snappy and manages the queue quickly. Dropping counterclockwise (before) the bloated device is a slightly different story. If I let the flow run for a few seconds the bloat builds up in the queue at the slow device. Switching AQM on at this point causes "overshoot" and burns the connection. I think what is happening is that it takes so long for the drop signal to propagate that by the time the retransmitted packet arrives it's time to drop again so we lose the retransmission and have to wait for an RTO. Whatever. Baaaad mojo. Don't let this happen. Anyways, as long as the AQM system is on before the flow starts then the queuing is managed and the system remains snappy. So IMHO it really doesn't matter except in the weird corner case where a a running flow has already bloated the queue and then we switch on the AQM. BTW...On a related note: I tried to address that problem by using ECN. If I don't drop a packet then there will be no RTX so...Well anyways, I switched on the ECN on my Linux boxes and the thing doesn't work! Is ECN in Linux broken? Here are the details: I switched ECN on using the /proc filesystem setting it to request ECN and to accept ECN requests. However examining the wireshark trace shows that the flow is marked Not ECN capable. I'm running 3.12 kernels. I find it difficult to believe that ECN is broken in Linux, but, it's definitely not working. Uhhhh, seriously? ECN is broken in Linux? You gotta be kidding me?!? Did I do something wrong? Anybody else notice this? *** I don't care that much about it because my experiments don't actually require that I use ECN, but, how on earth can we expect people to activate ECN when it doesn't even work? Errrrggggghhh! -------------------------------------------- On Tue, 6/24/14, Fred Baker (fred) <[email protected]> wrote: Subject: Re: [aqm] New Version Notification for draft-baker-aqm-sfq-implementation-00.txt To: "Scheffenegger, Richard" <[email protected]> Cc: "[email protected]" <[email protected]>, "grenville armitage" <[email protected]> Date: Tuesday, June 24, 2014, 12:41 AM On Jun 23, 2014, at 6:32 AM, Scheffenegger, Richard <[email protected]> wrote: > <as individual> > > Hi Fred, > > thank you for writing this down; one aspect that gets referred to, but not made completely explicit in sections 3.2 and 3.3 is the interaction of the AQM / Queue signals with the transport control loop. > > IMHO, it should be made very clear, when the AQM action is done before the queueing, that the AQM signal is delayed for the outer control loop; obviously in a defensive loss situation, this will always be the case. In comparison, when the Queue prepends the AQM action, the AQM signal is delayed less to the outer control loop. > > Depending on the depth of the queue / departure rate, that timing difference can be significant... > > I don't know how to put that into better words that would fit into your draft though. > > Best regards, > > Richard Scheffenegger I can go into that if you want. My logic here goes something like this. You can think of a TCP session as a control loop stuck into the middle of a larger stream. Imagine I’m moving a gigabyte file from here to there, the MSS is 1440 bytes (an IPv6 packet containing it is 1500 bytes), the bottleneck link between “here” and “there” is some specific rate, and the propagation delay between “here” and “there” is some non-trivial value. The least effective window that would maximize throughput is the number of segments that could fully use the bottleneck capacity; any additional quantum that is there sits in a queue and increases the RTT. So at any given point in time, we can think of the transfer as having several components: K segments that are actually “in flight” somewhere An additional K segments that hack been received and whose acks are in flight. cwnd-2*K segments sitting in a queue, probably at the bottleneck. Some number of bytes that haven’t been transmitted yet of those, the next cwnd segments will be transmitted as acks arrive. Some number of bytes that have already been received at the far end but not delivered yet to the application Zero or more segments that have been received out of order and are being held pending retransmission Now, let’s mark a specific segment; I’ll call it segment N. I don’t really care what the value of N is. But it is the segment that the AQM algorithm will select and drop, by whatever algorithm it decides. In a tail-drop case, for the sake of argument, we can assert that the entire cwnd segments are between segment N and the receiver or are represented in acknowledgments on their way back. In a head-drop case, there are cwnd-2K segments sitting in the queue after segment N, K segments between it and the receiver, and K acks in flight. +------+ +--------+ +--------+ | | | Queue |Data K segments | | | +----->+ +----> - - - - ------->+ | |Sender| |Router 1| |Receiver| | +<-----+ +<---- - - - - <-------+ | | | | |Acks K acks | | +------+ +--------+ +--------+ So now, the whole thing rotates clockwise. 1) K segments already in flight arrive and are acknowledged while K acks arrive at the sender and trigger new transmissions. The queue still has cwnd-2*K segments in it. 2) depending on whether it was head drop or tail drop, somewhere between zero and cwnd-2*K segments arrive and are acknowledged while as many acks are received at the sender and trigger new transmissions. The queue still has cwnd-2*K segments in it. 3) the missed packet is detected by the receiver, who starts responding with duplicate acks. However, there are still K acks in flight, so the sender is going to send another K new packets before he even sees the first dupack. The queue still has cwnd-2*K segments in it. 4) we now get a long stream of dupacks, and the sender presumably retransmits the dropped packet. AT THIS POINT, SENDER REDUCES CWND. If more than one packet got dropped, let’s hope the SACK logic retransmits it as well. 5) At long last, the retransmission arrives at the receiver, who sends a giant ack and starts sending a stream of acks, triggering new transmissions. To determine the difference between head-drop and tail-drop, we have to ask ourselves how big cwnd-2*K is. If we are using traditional too-full-drop-something without AQM, it might be a largish number (it could be the size of the memory allocated to the queue if there is no competing traffic), and it is probably fair to say that head-drop would get the event back to the sender more rapidly than tail-drop. If we are using any AQM technology - RED, WRED, ARED, PIE, CoDel, Blue, AVQ, or whatever else, the fundamental purpose of the logic is to keep the queue relatively shallow, even if it ha a large memory system behind it. In RED terms, we would estimate that the mean queue depth will approximate min-threshold or less; each of the other technologies has its counterpart to that and will similarly keep the latency and/or queue depth down. Hence, cwnd-2*K is a function of the mean queue depth at the bottleneck, and is a relatively small number. Hence, if we’re using an AQM algorithm - any AQM algorithm as long as it works - the real differences between had-drop and tail-drop is a relatively small number. Which makes me ask - what are we really talking about? Does it actually matter? -----Inline Attachment Follows----- _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
