My presentation on M2M at Telco2.0 and my impression of the conference

Tuesday and Wednesday I was at the Telco 2.0 conference in London organised by STL. I was an invited speaker on the M2M track on Wednesday morning. Like many of you, I know the Telco 2.0 blog and knew of the conferences. Good friends in this community, like James Enck were on stage there before me. Other friends in this community stood at the basis of the Telco 2.0 ideas. So I was quite happy to be invited to the event.

Telco 2.0 on M2M
My presentation was part of the dedicated M2M track. Not all the attendants were there, but only those interested in M2M. The crowd was treated with a series of presentation from carriers and various forms of system integrators and suppliers.


What I found interesting in the telco presentations was, what they were and weren't about. What they weren't about is what their customers were doing and the problems that these customers were facing. What they were about is, potential use cases, the organisation of the telco's M2M unit and how it was embedded in the organisation and the design of the M2M platform. The whole reasoning was supply driven. Build it and they will have to come. As someone had warned a while ago, most telco diagrams of a problem start with their network in the upper left part of the page and the customer in the lower right part of the page. This is true. It also shows where their focus is; themselves, not their customer.

The difference between the telco's wasn't too great. Orange seems to go for a more fully integrated solution, where they will deliver the network, the platform and all sorts of other devices. Telenor has a dedicated group for M2M networking solutions, called Connexion and another group Objects that focus on service enablement, regardless of the network. So Connexion can sell to the whole market without involving Objects and vice versa.

Most of the presentations were at least of a decent quality and sometimes quite better. It deserves metntioning, because often this is different. However, the feeling these presentations give me in retrospect, is that of enormous budgets and very little idea of what the customer is looking for. This idea came from a remark by a quite brilliant and quiet Eastern European financial controller of a mobile telco, who remarked privately that his company just didn't have the size and the budgets necessary for such a platform, certainly given the 5 euro max revenue/month per SIM. This remark is so incredibly true. The large behemoths of European Telecoms are still swimming in the free cash flow. Free cash flow that is supposed to do something and might as well be spend on M2M. Running after every hype in the business, including M2M is not so much a necessity as it is a luxury.

The interactive format of Telco2.0 also means there was quite some feedback from the room, through instant polls. What it showed was that the audience was effectively split over the idea whether mobile telcos have a larger role to play  in the M2M ecosystem.

My presentation on how M2M customers becoming MVNO's
 I gave a presentation called "Your M2M customer wants to be MVNO". In generally the audience quite liked it. They thought it was thought provoking. I do think it was the most referenced presentation during the day. Both the facilitator and the speakers quite often referred to Rudolf or Logica. This was of course nice for my ego. I really focussed on the 4 central business problems and why becoming an MVNO was a solution.


What was also quite clear is that the industry really doesn't want to hear what I had to tell. The idea that a large scale M2M user is going to become a wholesale customer of the telco is just not done. There were some interesting comments why not:

Your customer wants to be mvno v2

View more presentations from Raindeer.

Say no to streaming video (there is no use for it and it hurts net neutrality)

Andrew Odlyzko has written a very insightful paper called "The delusion of net neutrality". The title is a bit of a misnomer as he is not arguing that net neutrality is a delusion. Instead he picks on network providers who argue that there shouldn't be/cannot be net neutrality. The technologies used for Deep Packet Inspection are used to enable streaming and real-time communications. Real-time communications may be sensitive to jitter, latency etc. and may benefit from QoS mechanisms on an overloaded link, but any communication that is not realtime (most streaming and near-realtime) communication shouldn't have that problem. Andrew Odlyzko'sargument is very true and well worded.

Video shouldn't be streamed it should be send via "faster than real time"-download. If it is send in this way their will always be way more in the buffer, so that temporary hickups will not harm the download and once the entire movie or a section of a movie has been downloaded there is no problem at all anymore even if the network goes down. The advocates of streaming video can't bring anything against this idea, except that it doesn't allow them to sell very expensive streaming kit. A big online video farm like Youtube always makes use of faster than real time downloads for exactly those reasons. Highest Quality of Experience for the end-user and lower costs for Youtube are a killer combination. So needing to enable streaming video is not a good argument in favor of non-net neutral networks.

One argument I did miss is that "Faster than realtime" also frees up resources later on in time, allowing better overall quality of experience to end-users. I've argued this in the OECD report on Broadband I wrote. Let's say a streaming movie takes 10% of line capacity. If there are 10 parallel streaming movies at the same time, the link is full. If you allow for faster than real time downloads, if there are two users they can download the movie to the buffer five times faster than they need it from buffer. When later on in time more people come online to watch a movie, the earlier downloaders either may have finished the download already, or may be able to stop the download of the movie for a time, freeing up resources to allow an eleventh or twelveth downloade in at the same time. (for other arguments, see my rants on QoS and flow based routing)

Technology, economics, ethics, qos and flow control

Dr. Lawrence Roberts, who was one of the men who started the internet and is no head of switch company Anagran wrote on Internet Evolution. I reacted as follows:

I think I will have to disagree with the whole contents of your post. The problem lies in a combination of factors: technology, economics and ethics. Technology wise I do wonder about the technical soundness of flow control routers. We tried much of the basics with ATM and the idea didn't scale well. However, you've got your technical credentials, so lets assume the product you are pitching works as sales sais it does.

The problem however is that technology in itself may be sound, but that the discipline of economics provides the measures along which the success of technology gets measured. Terms like: the best, fairness, quality, simple and even scale are not technical terms. There is no best chip or router design. ATM isn't better or worse than Ethernet. It does different things. Simplicity is impossible to measure when you're talking millions of lines of code, high end lasers, asics etc.

Measuring what is best requires therefore insight into the field of economics. I've once tried to write an outlne for a scientific paper on the subject. You can find it here: http://lunaticthought.blogspot.com/2007/11/there-is-no-economic-basis-for-qos.html One of the main problems with adding flow control like structures to networks is that they base themselves on the premise that the network is almost full and therefore we need a mechanism to manage congestion on the network.

There are 2 problems with this idea:

1. Is there a problem: Are networks really full? (which means in technical terms that spikes at small time intervals (hundreds of miliseconds) are exceeding network capacity? Are we really seeing this often?

2. Are you the solution: Is the solution to managing a traffic jam, to introduce congestion management or to increase capacity? Network growth is 50% per year according to mr. Odlyzko. So when the current usage of the network is set at 100 and it is reaching the capacity where flow control kicks in.. In a year time it will be 150 and in two years time at 225. How many packets can flow control drop without it being like TCP?

With TCP fairness (fairness is ethics) ideas there are also similar problems.

1. It assumes that over the entire stretch between two network points there is a problem. What if the two end points are small say 1mbit upload on both sides. Why would that require control in a non congested 10Gbit network in the middle?

2. It seems to assume that every TCP flow should get an equal proportion of bandwidth. However I have paid for 20/1 DSL. What would be a fair distribution of available space on a 100mbit line between me and 40 people with a 5 mbit line? Do we all get equal amounts of bandwidth? Do I get 4 times as much because I have bought 4 times as much? or 8 times as much, because I pay 8 times as much. Do we want communism or capitalism?

3. You mentioned that TCP punishes those that are further away. This sounds correct from an economical point of view, distance incurs costs, costs decrease efficiency. Inefficient solutions should be thrown out. Get stuff locally.

4. randomly dropping packets is seen as unfair. many solutions are trying to think up ways to determine which packets should be dropped. This requires the network to know the utility function of all users in order to determine fairness. However if I have 2 streams running each consuming 5 mbit/s whereas there is only one 9 available, maybe I don't want 4.5mbit per stream, but want to drop one of the streams. How would the network know which one to drop. Random dropping hits everybody equally with the added costs of omniscience.

5. How do you balance streams fairly if you don't know the future? traffic changes on miliseconds. Are you sure that dropping this packets is necessary, maybe the end-user stops a transfer and other packets should be dropped from the que. or maybe no packets need to be dropped, because all of the sudden traffic stops.

All in all if we look at this from an economics point of view, the rules of economy teach us that generally the solution is that one which is the most efficient as seen from the market players individually and as a whole. It should therefore have low entry costs, low transaction costs, little overhead and generally not make assumptions on what individual actors want.

All of these considerations I miss in your proposal. Plain flat Ethernet/TCP/IP maybe dumb and stupid, but it's dumb and stupid for everyone. It's not pretentious. If it's full you upgrade capacity. If there is enough capacity. There is enough for everyone.