This is a very important point here. If OW were managing their own bulk capacity then they'd have detailed sight of the throughput on each account on the RADIUS server. I do not understand how issuing a new account could resolve people's problems. Unless...
The answer that issuing a new account is easier is just bollocks in this case. Not only does it not actually do anything in terms of support (where it may in fact be an issue completely unrelated to AAA and the customer has now in fact received diddly-squat in the way of support), but those accounts were sent back into the allocation pool for some other poor sod to suffer on. It's also just as easy to...you know...actually look at the RADIUS logs and resolve the issue if you're managing your own capacity.
The "it's easier this way" answer just shows me that Openweb have nothing but contempt for their customers and view support as a burden more than a service I'm afraid.
Now on to the issue of contending at the account level - this is somewhat fine by me. Every single ISP contends their bandwidth, so no matter where you go you'll be contending for the bandwidth with at least 5 other people (15 with most uncapped accounts). But this is built into the backend system - it doesn't happen on an account level. Further contending at the account level by sharing account IDs is despicable. Now you have at least two people contending for the same already-contended bandwidth, so the reasoning that this is normal is hogwash.
There is more to this though - they claim that one cannot accurately glean anything from the concurrent session IDs on a single login other than from their system, but this makes no sense - they're not a tier 1 provider. This only makes sense if they have removed all contention from their backend and are contending solely at the account level, so sharing user IDs, but this is preposterous as it would entail changing passwords for all users on the same account each time. Although it does go to explain why they opted to disable password changes on their system and issued the same passwords combos to just about everyone. It also explains why people then would be issued new accounts when they had troubles. It means that all you need is a trained monkey on support who knows how to copy 1122 and a username.
So perhaps they did after all opt for the unethical contention at the account level by sharing user IDs. Explains a lot. The puzzle pieces fall into place. Just means more people will have issues but then their support simply has to have a batch of logins to send out, or issue a new one each time from the revolving pool.
Either way, they lost my trust with this fiasco and their refusal to address it. All they needed to do to qualm people's troubles was to offer the affected users a copy of their connection logs, upon which nothing confidential would exist. The fact that they chose not to indicates to me that they opted to contend at the account level by sharing IDs instead and assumed their customer base to be morons or pushovers. Whether they contended additionally no-one will probably ever know...