When packets are being sent over the wires, the TCP scheduling algorithm (usually CUBIC, VEGAS, RENO, or now BBR) will send out packets until the parameters they monitor indicate the downstream device is about to overload. Then they will back off slightly to prevent packets from being lost. These TCP transmit strategies tend to either monitor packet loss rate or round trip time, sometimes both. What they do with these two parameters determines the biggest differences between the packet sending algorithms.
CODEL comes into affect when the scheduling algorithm decides it can't send out packets quickly enough without losing them, and they build up on local buffers. This can happen with TCP but also other internet protocols.
Something most people don't know is that without a scheduling algorithm like BBR,VEGAS, or RENO, you can send out packets at interface speed. In simpler protocols like UDP you need to do your own packet scheduling. Otherwise your machine will send out packets at interface speed until they are mostly dropped by the first slower link. This is why TCP has scheduling algorithms, they're all an attempt to monitoring the end to end link speed from A to B you can achieve without losing data.
Edit: BBR is a new TCP scheduling algorithm to fight buffer-bloat at the TCP level. Since the majority of internet traffic is TCP, wide adoption would cause a big improvement. TCP scheduling only affects outgoing packets, so its important to get this into Windows and Linux so we can get the full benefit of having buffer-bloat reduction on both ends. I'm looking at MS here because they're the last major OS running an aggressive and buffer-bloat causing TCP algorithm.
CoDel is an AQM (Active Queue Management) algorithm - it decides what packets to drop and when to drop them as a packet queue fills. This is most relevant at the hop with a bottle neck link.
BBR and reno etc are TCP congestion control algorithms or less frequently called congestion avoidance algorithms - they manipulate the window size and attempt to avoid congestion using different takes on congestion signaling (i.e.loss based reno, delay based for vegas, model based for bbr). This is most relevant from the sender side.
Scheduling would be more advanced queuing disciplines (for QoS or flow based fair queuing) and packet pacers. Queuing disciplines can apply to any bottle neck link, pacing is most useful sender side.
I try to talk about these things in a way that's easy for lay people to understand. Even among programmers QoS and packet scheduling are a niche topic