[aqm] Draining queues

[John Leslie <[e-mail]>]

[e-mail] <[e-mail]> wrote:
> 
> A problem with ECN is that it does not drain an already flooded queue,

   I presume you mean that ECN doesn't drop the packet it marks.

> and depends (like RED) on the idea that one has a large queue in normal
> operation.

   I don't follow this at all. ECN is pointless without an AQM which
drops or marks well before tail-drop. Were we to run ECN without AQM,
we'd have to drop each packet anyway after marking it.

   Several flavors of AQM mark/drop well enough in advance of tail-drop
that the queue need never fill. Did you mean to say that ECN requires
being able to queue the ECN-marked packet which would otherwise be
dropped by the AQM?

> It is not obvious that sustaining a deep queue is a desirable state,

   Agreed!

> especially when there are highly variable capacities along any path,
> as is the case where one link is more than 2x slower than the rest of
> the links.

   Isn't that _always_ the case?

> If the dynamics of user loads are fractal, this will cause draining
> (and latency reduction) not to work.

   I'm guessing you mean that under "fractal" loads there's a tendency
for ECN-marked packets to clump and introduce latency at the bottleneck.
Recall that this is offset by the quicker response to an ECN mark at
RTT speed instead of having to infer a packet loss.

> If user loads are stationary gaussian and so forth, ECN can "tune"
> to relatively stable situations, but the queueing delay will be quite
> long end-to-end.

   I don't follow... Some AQMs may indeed allow queueing delay to grow
large; but this can only happen if the instantaneous percentage of
marked packets is quite a bit higher than TCP can tolerate.

> Since there is lots of evidence that user loads are fractal, dropping
> packets during sudden bursts will prevent sustained queueing, whereas
> ECN will not.

   I believe there is substantial agreement that ECN-marked packets
will need to be dropped anyway under particularly severe congestion.
At the very least, tail-drop can become necessary...

> So a proper approach (in my opinion) on the "real" Internet (rather
> than a bunch of competing long-duration FTPs) requires keeping the
> queues so short that there is no real opportunity to benefit from ECN.

   Here I quite disagree.

   An AQM could be designed to ECN-mark at a 1 millisecond queue depth;
and that can give the full benefit of ECN. Again, recall that ECN will
deliver the congestion signal in one RTT, instead of waiting to infer
a loss. TCP stops delivering useful bandwidth at one or two percent
packet loss: so it's hard to believe that ECN-marked packets will clog
the path significantly.

> Hence - we need to really see what happens with *real* traffic loads,
> not simplified simulations.

   Agreed! (Now if we could just get enough ECN deployment...)

> Real traffic loads are fractal, and fractal loads do not generally
> obey the Gaussian style "law of large numbers" - multiple fractal
> flows are *rougher* not smoother than a single one.

   I would say rather that real traffic loads _contain_ fractal flows.
Aggregation simply wouldn't work if we never experienced gaussian
smoothing.

> So check your mathematical "intuitions" at the door.  Stop writing
> equations based on tractable analytic models, because actual traffic
> does not follow those models.

   I strongly suspect our models _are_ faulty -- but we need research
results for _actual_ flows, with and without ECN, is order to diagnose
their faults.

--
John Leslie <[e-mail]>