[Bloat] some comments on draft-ietf-tsvwg-byte-pkt-congest-10.txt

[Jonathan Morton]

On 17 Jun, 2013, at 10:40 pm, Dave Taht wrote:

> if we can agree that AQM = Active queue *length* management and
> can come up with a name for FQ+AQM hybrids that works for people (SQM
> - smart queue management?) so we know what we're talking about when
> talking about things

SQ = Smart Queueing sounds good to me, for AQM+FQ together.  It should probably also be taken to include any third or future category of techniques that is found to work well in concert, as well.

For the fourth (original) corner of the graph, PQ could mean Passive Queueing, meaning neither AQM nor FQ - this would have to refer to ordinary priority queues and packet aggregation as well as a dumb FIFO.  That means we need a robust definition of FQ.

So AQM means any technique which seeks to maintain the average length of the queue below the maximum, by proactively dropping or ECN-marking packets.

And FQ means any technique which uses a separate queue for each flow, or stochastically approaches that ideal.  Broadly classifying packets into a small number of categories (as has been done since the TOS days) is not sufficient to be FQ.

An example of a third technique would be such broad packet classification, which allocates a separate AQM+FQ combination for each category and dequeues them according to a priority algorithm.  We've discussed such things quite recently; the main problem seems to be identifying traffic reliably without application-level cooperation, which is a perennial problem.

> Anybody got a 68020 or slower to play with?

I have a Mac IIcx (16MHz 68030+FPU) with an Ethernet card - an '030 is pretty close to an '020 in performance per clock, if the '020 isn't using an MMU.  It has enough RAM to run Linux effectively.  It doesn't have DMA, though - a common limitation on single-user machines of the time - which is a severe limit on throughput.  Also, it probably needs some major surgery due to age-related component degradation (capacitors), since it currently won't power up.  Ironically, I ran into that problem just after fitting the new RAM, though it had been showing signs of it beforehand.

The next closest thing I've got is a 25MHz 486 (an IBM PS/1 in which I swapped the original i486SX for a DX) with two Ethernet cards (one is the well-regarded 3c509B) and an analogue modem fitted; a leftover from my university days a decade ago.  I know that it can route T1 level speeds despite not having full-duplex Ethernet or PCI.  I'd need to set up Linux afresh on it, of course, but then I could insert it in place of my usual firewall machine for testing.  That is, of course, if it hasn't succumbed to the same class of fault as the IIcx.

The next candidate I have after that is an Acorn RiscPC, but I think a 30MHz ARM CPU is sufficiently faster than a 68020 - *any* 68020 - to dilute the point.  Also, I don't have an Ethernet card for it, and even if I did, it also lacks DMA hardware AFAIK.  However, you could downclock the Raspberry Pi's CPU quite a lot (edit config.txt in /boot) if you want to explore this space - as long as the GPU and RAM clocks remain above some threshold, everything should work.  A quick look reveals definite reports of a 50MHz CPU clock working.

If you really want an '020 or '030 with DMA, the best candidates would probably be an Amiga, a NeXT Cube or an early Sun workstation.  The latter have probably survived relatively well, and were quite likely used for at least a few of the early performance studies that people now habitually rely on.

 - Jonathan Morton