Lots of good press these days on the value of RED or W-RED.

Certainly seems to me that discussion of Weighted RED has little to do with RED. Or at least, it's an easily seperable issue that I would prefer to seperate. Perhaps I'm non-characteristic, but my bias is towards a best effort network, and I easily see the use of RED there, but WRED is a whole different ballgame.

What might be a useful benchmark to collect is the size of queue length on border router interfaces (at both public and private peering points) so that there might be some accurate data on just how RED will affect behaviour of said gear.

I'm curious how you did that. I was looking at this relatively recently (circa two weeks ago), and I came to the conclusion that 1 poll/second was just too low a granularity, and trying to do anything meaningful with that data wasn't useful (FFTs were useless...). Of course, my data was SNMP-based and my polling software isn't prepared to deal with higher frequency than 1 Hz, so I stopped there. This is certainly an area where vendors could improve. MO spoke to this at ISMA, and I think vendors are listening (or at least, some of them have suggested so).

Some estimates have RED capable hardware (other than the wonderful work that Curtis has done) available for mere mortals in the next couple of months.

It may also be that RED-capable software for existing hardware comes sooner than you think. I'm not at liberty to speak a whole in this regard, but people should be encouraged to communicate their desires to their vendors.

As for me, I'm collecting interface queue lengths at LAP/MAE-LA off the participating routers...

Any thoughts?

Well, I wonder how you collect queue lengths. Putting on my cisco-centric hat, IOS doesn't let you collect "real" queue lengths used with the kind of packet forwarding that most people use (optimum switching) -- you f9cannot even see them with "show interface". The only user-visible way to see those is "show controllers cxbus". You can sample interfaces.iftable.ifentry.ifentry.ifoutdiscards and assume this gives you a reasonable view into queue lengths (that's what I did) -- if you did something different, I'd be curious. On another random note, while cleaning my office this weekend I bumped into a piece of the Floyd/Jacobson RED paper that suggests there was some existing work on characterizing global synchronization: Another goal in deciding which connections to notify of congestion is to avoid the global synchronization that results from notifying all connections to reduce their windows at the same time. Global synchronization has been studied in networks with Drop Tail gateways [37], and results in loss of throughput in the network. and I spent part of Sunday/Monday tracking down [37], which is a Lixia Zhang/Dave Clark paper abstracted from Lixia's thesis. Unfortunately it's all simulation-based work (oh well). --jhawk