Core-Stateless fair queuing

While starting to read the next paper, a question popped out in my head: does the fair queuing algorithm violate some end-to-end principle? While congestion avoidance is something that seem to best taken care of by the hosts (assuming that the hosts wants reliable communication), I would think that trying to allocate bandwidth fairly among flows is something that needs to be in the network, since the host does not know anything about other hosts and may not even be cooperative in the first place.

Another issue seems to be that for a router to implement fair queuing, it needs to keep track of all flows, which requires state, and grows in complexity with the number of flows. Also, when should a router stop keeping track of a flow? The proposed Core-Stateless Fair Queuing (CSFQ) tries to resolve this by pushing the work out from the core routers to the edge routers. The key idea is for the edge router to label incoming packets with their flow and rate, while the core routers probabilistically drops packets based on the labeled information and an estimated fair rate. The simulations show that CSFQ closely approach a fair queuing variant, even outperforming it in one scenario.

I am not quite sure why this might be better than fair queuing from a complexity point of view. I suppose all the workload is on the edge-routers which are next to senders, while the core routers can do something much simpler on a per packet basis. Would the edge router see less flows than a core router, and thus this is a way of distributing flow tracking work?

As the authors point out, it is not clear how easy it is to track flows. How much problem does this cause if not done properly? Also, how easy is it to label a packet with this flow ID and rate, and how do you assign a unique flow ID (some long random number perhaps?).