No, I didn't notice that they didn't measure the L3/L4 overhead. I'm not familiar with the two APIs/tools they used. But if that is the case then it invalidates the majority of the study.

I'm not sure about sensationalism, but the article certainly has a strong bias.

The operators that my employer delivers charging solutions to rarely use the byte counters from the GGSN because they charge he traffic types differently, e.g. "free facebook" while other traffic is charged based on byte counters from the DPI box. It is true that some of the newer GGSNs/ASN-GWs have adequate DPI capabilities so they can classify the traffic with enough granularity and the byte from them can be used.

There is one slightly fishy thing in the study (yes, I read the fine paper). Their test with logging on, go idle, move to radio-inaccessible room, then have server start steaming UDP to the phone (which will be dropped due to inaccessibility). In my experience the SGSN/GGSN quickly signals that the user has gone offline (PDP session termination), and the stream of UDP from the server is blocked at the DPI or the GGSN. Sounds like the operator that the study used has a major bug in its charging setup where PDP session termination doesn't also stop the IPuser association.

I recently bought a Fujitsu Lifebook E751. It has a numeric keypad. The keyboard looks flimsy but doesn't feel that way.
Note: the page on fujitsu.com has a photo of some other model. There may be differences in the various sub-models.

Not exactly a thriller, but I enjoyed Charles Stross' Antibodies

What happened with the KPN incident last year? Was the legislation only for fixed-line internet?

That is not entirely true.
The train station ticket machines gives them back in change, and merchants happily accept them. But it is true that you normally won't get them in change from merchants.

Why the hell do these morons keep tabling impossible and/or extremely EXPENSIVE (compute-wise) proposals

Because when they withdraw them and make slightly less impossible and expensive proposals they seem reasonable to the politicians?

Interesting. What is your opinion on embedded SQL? (as i Pro*C/C++ or equivalent)?

I never completely understood most of my colleagues' preference for JDBC-like access to a database, when embedded SQL catches most errors much earlier (t compile-time). Sure, it is kind of ugly, but JDBC-like access with its many getString()/getNumber()/... isn't pretty either.

http://tools.ietf.org/html/draft-vyncke-advanced-ipv6-security-01 has some interesting ideas. At least it is a starting point - we don't want to end up with the same situation as for IPv4 where everything has to be piggybacked on inside-initiated HTTP connections.

Italian does not differentiate between mitts and mittens - I guess there has never been the need.

CCN = Cyclomatic complexity number

It is basically the number of of different paths in a code block. It indicates how many tests you have to perform to reach 100% coverage. But more importantly it is also a reasonable indication of how complex the code is to comprehend. A cyclomatic complexity of 20 is quite high, unless the 20 different paths are 20 different cases in a switch statement.

Look for "cyclomatic complexity" on wikipedia - it covers the subject quite nicely.

Argh... stupid moderate button. Posting just to cancel the down moderation.

Your ISP is likely not counting bytes that transfer through a connection to your modem

Actually, they most likely are.
For dialup, PPPoA or PPPoE they get all the nice byte counters using RADIUS accounting. All BRAS boxes supports that. (RFC 2866)
Some ISPs use Netflow protocol (or the newer IPFIX) on some central routers. The downside is that they have to correlate the usage information with the IP-address assignment which can be tricky near the session start and session end.
Some ISPs collect the byte counters from the DPI boxes with fine granularity. (Allot, Sandvine, Ipoque, ...). Some of the DPI boxes can automatically correlate the IP-address with the subscriber information, producing ready-to-charge CDRs.
For DOCSIS environments I would expect them to collect the byte counters using the SAMIS interface (Note: I don't have detailed experience with DOCSIS).
In 3GPP IMS environments they can get the byte counters from either the Rf (offline) or the Ro (online) reference point All specified in 3GPP TS32.299. Some operators are also doing it via the Gx reference point in newer releases but that is quite ugly.

The byte counters they collect may include L1/L2/L3 overhead. Eg. RADIUS usually include the L2 overhead from PPP, Netflow usually includes the ethernet overhead, DPI boxes typically reports byte counters that make sense for the inspection granularity, ditto for 3GPP Ro.

How do I know this? I work in the business.