QoS is not the only way that routed vs. broadcast networks differ in bandwidth contention. For example, in the common situation where you have many clients contending for one big NFS server, broadcast bandwidth-sharing is better than a switched network.
The betterness comes from the way broadcast nodes can hold back a packet until they know the packet will make it past the broadcast link, while routed networks have to drop the packet when there is congestion. I don't think the above argument against the common corporate problem of switch overuse generalizes very well to DSL where, unlike an office network, the ``core'' is faster than the ``leaves.'' But it's worth stating.
Now, let's move on to the more interesting argument: that end-to-end switched networks are better for fairness and QoS than networks that include broadcast segments. This argument is also suspicious once put into practice because the DSL camp is NOT implementing serious fair queueing at all levels of the DSL network. And they probably won't, since the DSL guys are firmly allied with the nay-saying ATM camp. But they could, and the feasability of real-time/fair schedulers like HFSC is better-proven on DSLish networks made entirely from point-to-point links and routers than it is on cable-ish networks that include broadcast segments.
Why? Because in the DSLish networks, each router has no control over what traffic arrives on its input channels but complete control over all its output channels---it can schedule a queued packet for transmission at any time it pleases without worrying that it will sense someone else's carrier and have to wait before transmitting, or experience a ``collision'' and have to automatically retransmit, or something. And unlike one's contentionfully-won slice of a broadcast channel, these point-to-point output channels have a known, constant bandwidth. This zero-transmission-latency, fixed-bandwidth output channel makes the real-time packet schedulers easier to design.
So long as the DSL camp continues to ignore the serious packet scheduler algorithms (ex. those in ALTQ), QoS is not the argument for DSL over cable that it might have been. However, let's just pretend DSL gets their act together and starts using stuff like HFSC in the customer routers. I still don't think that's enough to permanently burry cable with technical superiority.
There is a simple approach for bringing fair queueing and QoS to broadcast networks that I think shows promise. To understand why what I'm about to suggest is a sensible strategy, first accept that eventually all real-time traffic will have to face an unmediated contention-oriented broadcast bus---our hope is that this bus will be much faster than our real-time flow's bitrate, and also that it will have some simple quasi-fairness to prevent the ``Ethernet capture effect.'' PCI is a good example of such a bus, with its 1.056 Gbit/s bandwidth and rules about the max timeslice of ``burst transfers.'' As long as your network card is plugged into a PCI bus, your real-time session will not have telco-fascist ``end-to-end'' guaranteed bandwidth. When this harsh reality causes us problems, we don't blame the PCI bus for being ``non-deterministic''; we just say that our computer is too slow for videoconferencing and buy a faster one.
In fact, this ``gigantic wasted channel'' QoS is the same philosophy that current dumb-priority-based VoIP uses: the priorities make the VoIP phones experience the office network as if VoIP phones were its only users, and since the network was provisioned for mixed phone/data use, it is gigantic compared to the VoIP traffic alone. Gigantic-wasted-channel-QoS may seem dumb, especially to waning telco-fascists like Worldcom, but it works, man.
so, here is my magic recipe for extending router-oriented packet schedulers to a broadcast medium. Create two separate broadcast channels: a small one for reservations and a big one for data. This is analagous to 802.11b's CTS/RTS protocol between Terminals and the Access Point. Before transmitting a packet, Terminals must request a reservation from the Access Point. Reservations contend for bandwidth chaotically over the reservation channel. Terminals are forbidden from transmitting until the Access Point sends them a reservation-grant, and this reservation specifies a time-slot that the Terminal's data packet may occupy on the big data channel. The real packets on the data channel do not contend chaotically---they never collide because there is only one Access Point per broadcast channel that may hand out these reservations.
Although the reservations still contend for bandwidth chaotically, they are much shorter than the packets, perhaps only 2 - 4 bytes if you use a stateful protocol. Even though the reservation channel is narrower than the data channel, the reservations are 1/200 - 1/500th the size of the data packets, which makes the slow reservation channel equivalent to a gigantic, mostly-empty channel like PCI. The effect is less pronounced for small packets like telnet, but I think this is not a show-stopping limitation.
This scheme turns the entire broadcast network into something conceptually similar to a single output interface on the Access Point. If Terminals put QoS flow markers into the reservation-requests, then the Access Point can implement complicated scheduling algorithms like HFSC---it will simply schedule reservation-grants rather than packets in the output queue.
so, I still have faith in the future adaptability of broadcast channels to QoS.
Unfortunately, AFAIK no one is doing any of this QoS stuff YET. Cable does not do QoS over their broadcast channel---if you buy a telephone number from a cable carrier or one of those expensive ``guaranteed''-rate cable web server subscriptions, I think they use the glorified-telco-bit-multiplexing ATM-style QoS. And AFAIK DSL makes no attempt at QoS either, or else I guess some of the existing DSL equipment might plausibly adapt the primitive priority-based QoS that I discussed earlier in the context of VoIP on office Ethernets. I think the ultimate argument will take the form ``X carriers are starting to implement QoS, while Y carriers are still twiddling their thumbs.''
Oh yeah, and don't give me any of that crap about how QoS won't work until some hypothetical billing mechanisms are in place. That's nonsense and FUD. The solution to gratuitous reservations is simple: say that customers may only reserve a fraction of their channel's bandwidth as latency-bounded or best-effort, not the whole thing. That way, downloads will finish sooner as low-quality traffic, giving customers an incentive to classify their traffic honestly and in a globally-sustainable way. You can't use primitive priority-based so-called-QoS with this scheme, but so long as you use a good algorithm like HFSC, problem solved.
XXX -- incorporate Jeannine Mosely's paper.