> > 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. >
As you'll probably remember, I'm just an academic who tries to keep up with the times. What I can add is that in the latest MEF CECP (Carrier Ethernet Certified Professional) courseware (Blueprint D), egress bandwidth profiles that are based on token buckets are still actively advocated as a means of applying QoS. Cheers, Etienne On Tue, Nov 8, 2022 at 10:00 AM Saku Ytti <s...@ytti.fi> wrote: > Hey, > > > On Mon, 7 Nov 2022 at 21:58, Graham Johnston <johnston.grah...@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 > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
