Hey, On Mon, 7 Nov 2022 at 21:58, Graham Johnston <johnston.grahamj@gmail.com> wrote:
I've been involved in service provider networks, small retail ISPs, for 20+ years now. Largely though, we've never needed complex QoS, as at $OLD_DAY_JOB, we had been consistently positioned to avoid regular link congestion by having sufficient capacity. In the few instances when we've had link congestion, egress priority queuing met our needs.
What does 'egress priority queueing' mean? Do you mean 'send all X, before any Y, send all Y before any Z'? If this, then this must have been quite some time now, as since traffic managers were implemented in hardware ages ago, this hasn't been available. And the only thing that has been available has been 'X has guaranteed rate X1, Y has Y1 and Z has Z1' and love it or hate it, that's the QoS tool industry has decided you need.
combine that with the buffering and we should adjust the drop profile to kick in at a higher percentage. Today we use 70% to start triggering the drop behavior, but my head tells me it should be higher. The reason I am saying this is that we are dropping packets ahead of full link congestion, yes that is what RED was designed to do, but I surmise that we are making this application worse than is actually intended.
I wager almost no one knows what their RED curve is, and different vendors have different default curves which is then the curve almost everyone uses. Some use a RED curve such that everything is basically tail drop (Juniper, 0% drop at 96% fill and 100% drop at 98% fill). Some are linear. Some allow defining just two points, some allow defining 64 points. And almost no one has any idea what their curve is, i.e. mostly it doesn't matter. If it usually mattered, we'd all know what the curve is and why. As practical example Juniper has basically In your case, I assume you have at least two points with 0% drop at 69% fill, then a linear curve from 70% to 100% fill with 1% to 100% drop. It doesn't seem outright wrong to me. You have 2-3 goals here, to avoid synchronising TCP flows so that you have steady fill, instead of wave-like behaviour and to reduce queueing delay for packets not dropped, which would experience as long a delay as there is queue if tail dropped. You could have a 3rd possible goal, if you map more than 1 class of packets into the same queue you can still give them different curves, so during congestion in a single queue can show two different behaviours depending on packet. So what is the problem you're trying to fix? Can you measure it? I suspect in a modern high speed network with massive amounts of flows the wave-like synchronisation is not a problem. If you can't measure it or If your only goal is to reduce queueing delay because you have 'strategic' congestion, perhaps instead of worrying about RED, use tail only and reduce queue size to something that is tolerable 1ms-5ms max? -- ++ytti