On Wed, 5 Sep 2007, Stephen Stuart wrote:
Operators always define the "user" as the person paying the bill. One bill, one user.
It's easy to imagine a context where authentication at the application layer determines "user" in a bill-paying context. Passing that information into the OS, and having the OS try to schedule fairness based on competing applications' "guidance," seems like a level of complexity that adds little value over implementing fairness on a per-flow basis. In theory, any such notion of "user" is lost once the packet gets out on the wire - especially when user is determined by application-layer authentication, so I don't consider 802.1X or the like to be helpful in this instance.
Money and congestion are aggregated on many different levels. At the dorm level, money and congestion may be shared on a per-student basis while at the institution level money and congestion may be shared on a per-department basis, and on a backbone level money and congestion may be shared on a per-institution basis. That's the issue with per-flow sharing, 10 institutions may be sharing a cost equally but if one student in one department at one institution generates 95% of the flows should he be able to consume 95% of the capacity?
Its fun to watch network engineers' heads explode.
What if the person paying the bill isn't party to either side of the TCP session?
The person paying the bill is frequently not a party to either side of individual TCP sessions, that is why you also frequently have disputes over which TCP session should experience what level of congestion.