In message <[email protected]> Michael Richardson writes: > > Eggert, Lars <[email protected]> wrote: > > I've heard that statement [that RED is supported] from many different > > people. I wonder if it is > > actually true. Is there any hard data on this? > > The issue I've had is that while RED is supported on a routing device, > and I can enable it on a per-VLAN basis, that does me little good, because > there are bottlenecks in layer-2 devices (ethernet, but also DSL,GPON, etc.) > which are out of my control. > > What I would like is a standard layer-3 way to measure bandwidth across > my layer-3 hop, and autoconfigure RED (or CoDel) to the measured bandwidth. > My understanding is that some equipment can use 802.1ad CCP and/or Loopback > frames to measure bandwidth across bridged layer-2 ethernet networks. > > I'm unclear if this is a feature of that equipment, or a part of the > standard. My understanding is that the math involved is pretty > straightforward, but getting it right in code can involve dealing with a > number of numerical issues which makes it slightly non-trivial to > implement. (And you need good low-latency time stamping of packets) > > -- > Michael Richardson <[email protected]>, Sandelman Software Works
We need to keep context of deployment in mind: core, edge, access, enterprise, data center, home or soho, etc. In network core RED implementations or things claiming to be RED started coming out as early as about 1995. Some of the early hardware that supported RED didn't get it even close to right, most notably early Cisco RED, and gave RED a bad name among service providers. With the faulty implementations there was no way to get good results but the vendors just claimed "you didn't configure it right". In the core there are no bottlenecks at layer-2 devices. There are almost no layer-2 devices to be found and a responsible service provider, knowing layer-2 devices are dumb will make sure not to congest them if used at all. Layer-2 devices are used in core to edge sometimes and in edge sometimes, but again a responsible service provider, knowing layer-2 devices are dumb will make sure not to congest them if used at all. We would have to poll or do an informal anonymous poll of a few major service providers to see if they use RED at all today. For the most part the goal is to keep at least the core if not the core and edge sufficiently overprovisioned as to always be uncongested. This is where in the decade gone by large numbers of parallel 10G ports were used and today that is moving toward parallel 100G. With a Tb or multiple Tb between routers (DWDM makes this expensive but sufficiently cost effective), congestion is very unlikely. Sometimes growth can temporarily outpace deployment, so perhaps RED is available for that situation. In enterprise and data center there is also very good control over what equipment is used and how it is used. However, clue density decreases exponentially farther from the core and approaches zero in some data centers and in some enterprise IT departments. This is also true of the part of service provider organizations that pick stuff for consumer access. Where clue density is lowest, you'll find ignorance of AQM and buffer issues and lack of consideration for buffering and AQM when picking equipment for deployment and configuring it. Where consumer networking is concerned, cost is often the deciding factor, often on the SP side as well. DSLAMs went from no buffering in the 1990s to today where DSLAM and CMTS have too much and don't ship with buffers configured to reasonable values and AQM enabled by default, and SP often don't change the defaults yielding bloat. As for AQM in home networking and SOHO or small business, there may be bottlenecks elsewhere. RED will only help if the bottleneck is at the link between you and the service provider. One way to make that the case on the inbound direction is to create a queue (using something like pf and altq) with less than your downlink speed and apply RED to that. That covers a bottleneck between you and the SP in either direction (or both). AFAIK no consumer "home router" allows this sort of pacing. If the bottleneck is further in the SP infrastructure you can't do much if anything from your home network to affect it. Its also worth noting that PC hosts don't always make good routers or switches and the limits of hardware (like PCIe x1 cards, or too many cards) or CPU processing can become the bottleneck. OTOH, if you are just front ending an SP link on the order of 10 Mb/s things it should work with all but an old PC and NICs. There can also be bottlenecks internal to a LAN. An example would be large transfers between hosts. This can cause a bottleneck at a switch within the LAN and maybe what you (Michael) are referring to. Again, about the only thing you can do is configure the interfaces down to FastE speeds (100Mb/s) on a low end GbE switch, or get a higher end switch with buffering and RED - they exist but may cost 2-3 binary orders of magnitude more that a dumb and/or unbuffered GbE switch with same port count (dumb and overbuffered also exists). So my first question to the AQM WG is "what is the scope of AQM WG work in terms of where in the network this WG wants to focus?" If the answer to that question is "everywhere", then we have to be aware that conditions in core and conditions in home or enterprise are very different. If the focus is on home, soho, and small business, then the charter should say so (I don't think it is). Curtis _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
