As you can imagine, stepping back into this thread at this stage feels like stepping into a lion's den. However, Neotel is committed to working with its customers, and this is almost certainly the best forum to assist us in addressing issues raised by customers, so I'm here. This is not a final answer, but should show that a lot of analysis has been done, and we are close to giving a final answer.
There have been some quite extreme views expressed here, and we'd obviously like nothing more than to keep our customers happy, but we have to base our conclusions on proper engineering analysis. Some of the solutions under discussion aren't very likely to get to an answer, and seem more likely to make us all unhappy. This post should probably have a legal disclaimer up front, but that's not the kind of interaction we'd like here.
At the outset, let me state that it is Neotel's intention to offer the best value for money services. The cap, based on the individual counts of data sent and received by the network, is one of the mechanisms that we use to set the value of a service, and we aim to measure as accurately as possible. Strictly speaking, we don't cap, but bill at the industry's lowest out-of-bundle rate when the cap is exceeded. It makes no sense that we would intentionally miscount downloads and uploads, when providing clear, accurate billing is one of our principles. Similarly, Neotel will always address any genuine errors on its part, if objectively at fault.
It has been pointed out already, but licensed providers of telecoms services are bound in a number of ways. In addition to the obligations imposed by our licence and the regulator, we subscribe to ISPA's code of conduct as a member, and our billing and billing process have multiple checks and balances, and must be auditable.
It's particuarly important that we stick to actual facts. For that reason, we are grateful to those users who have provided and continue to provide us comprehensive data for analysis. It's obviously very easy simply to agree with a conclusion based on someone else's information, or incomplete information, but one has to be very scientific in one's approach. Neotel has a strong engineering team, and makes use of world class platforms, but a complex answer to a seemingly simple question sometimes takes time.
To start with, here is some information on how billing is done on the network, and how counting can be done at the customer side:
- Downloads and uploads of IP packets are counted at the first common point in the network (in our case, the PDSN). This information is used by the AAA platform to generate data records periodically.
- In postpaid systems, the data records are processed by the billing system when generating the final bill. (Note that more detailed analysis as required here would generally be done on the stored data records, rather than the bill.)
- Since the count is done within the IP network, and not at the basestation, there is no question of air protocol (or even Ethernet) overhead being counted in either direction. Only IP packets are counted, without any overheads or headers.
- Typical counters on MS Windows, Mac OS or Linux that look at USB ports similarly cannot count any air protocol overheads. They typically read from the driver library (not the port itself), and count IP packets. They may therefore count some modem control data during call setup, but typically only IP packets in a call.
We have done extensive testing in controlled conditions, as well as analysis of data provided by customers. There is too much data to present everything here, but a small sample may help.
The graphs in the pdfs below show a comparison between our network counters, Windows performance (task manager), DUMeter and Netlimiter over a relatively short period. It is clear from this data that the various counters track each other quite closely, with a slight step variation up and down typically a result of the granularity of the data collection.
View attachment Download.pdf
View attachment Upload.pdf
The exception seems to be the upload counter on Netlimiter, which under-reads dramatically when compared to other Windows counters. We are not sure whether this is a flaw in Netlimiter, or a question of configuration.
We have done testing on Mac OS, and some limited testing on Linux as well, but not comprehensively yet.
At face value, these short duration results seem to suggest that network and user counts are always the same within a small margin. Certainly, our auditable network counters appear to be correctly counting incoming and outgoing packets, since we seem to see the same at the user end. Since the network counters are the only basis on which it is possible to bill, it's not clear how else we could measure to obtain a different result.
However, we are keen to understand how some customers could possibly have arrived at different results, and are conducting longer duration and more comprehensive measurements, on which we hope to provide feedback shortly. There are still some factors that could be at play, and we're open to suggestions.
Obviously, it's not possible to rule out some other cause for the discrepancies reported, which is why we are continuing the testing and analysis. Whilst we don't want a flood of data, we'd welcome inputs from users who can do accurate, comprehensive, verifiable measurements against which to compare network data.
Finally, note that this is not some sort of public announcement intended to close the discussion. It is part of this interactive discussion thread, so feel free to respond.
). Your claim should therefore be addressed to "Neotel". Neotel will then have to elect a court representative.
