>> 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.
Agreed.
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?
That depends on the expectations of the institutions. If our example
student is able to generate 95% of flows because the network in
question is otherwise relatively quiet (maybe it's the middle of the
night, or a holiday), then yes, our example student should be able to
consume 95% of the capacity. If expectations are otherwise, then no,
and I'd expect that policies capable of enforcing that regardless of
the number of flows would be put in place at the appropriate
boundaries.
Let's say our example student is capable of generating 95% of flows by
virtue of having access to 95% of the IP endpoints in the example
network. How do you envision the OS notion of "user" helping you
implement a per-user notion of fairness on the backbone?
Stephen