Recently, a simpler model of service differentiation has emerged from LBL and MIT. The ideas are fairly simple and capitalise on recent advances on measurement based admission and network pricing theory . Surprisingly, this ends up being a specification of service profiles, which are implemented at the ingress (or egress) to any "area", where an area can be a backbone or an access net or whatever.
The service profile is ``accessed'' simply by the ``user'' (could be ingress/access router, or source host) setting the IP precedence bit.. (if they want low delay too, they set the TOS bit appropriately). The rate they send at determines the service profile (and therefore tarrif, if appropriate). There was one big unsettled difference between the model Van Jacobson proposes and the more complex model that Wroclawski and Clark have devised:
Jacobson's scheme drops all packets above the service profile rate (so if you pay, but the net is not congested, you don't get more than you paid) - for aggregated TCPs down such a pipe, this is not a propboem,, but a single TCP may not get good utilisation o nthis scheme (goal is to create a disincentive for people to use the premium scheme during light load periods anyhow!).
Clark/Wroclawski's scheme can do this, but can also specify a "TCP rate", which then implements a complex filter/policy at the ingress, that "understands" TCP dynamics and only drops packets for non-conforming TCPs (i.e. if TCP does slow start and congestion avoidance, their scheme for that particular profile will allow a saw tooth variation (not just a leaky bucket or burst tolerance, but a shaped burst tolerance!) - the details are unclear on how to make this go fast, but there are some nice simulations.
The main problem with not dropping packets that exceed the servcice profile is what to do with them - in Clark's scheme, the precedence bit is cleared. This has the problem that they then compete on an equal footing with non premium packets, and so can cuase congestion down stream - another problem is that they can arrive out of order w.r.t the premium ``in-profile'' packets. Some QoS routing researchers really like both schemes, since they can be implemted in 2 queues, (or maybe 4) and scale nicely (the nearer the backbone erouter, the less things have to be policed). RSVP might be used to "install" profiles although its more likely to be just a subscribe-time service. For alternate path QoS routing, it is also neat, since one only has to add mechanism for distributing 2 (or 4) sets of destination (or for multicast, source) based routes, which means it scales well.