Smarting the Dumb Pipes

les seauxstupidepoignées de porte de réseau pour une dactylo sueur

Oh, sorry, I work for a french company now. We are required to prepare our presentations in english and french...it’s kind of a new experience for me - like being in Canada!

Wednesday, May 26, 2010

smarting the dumb pipesnetwork servicesfor developers This is the story of how

we’re applying the lessons of an open ecosystem to a closed one.


main() { puts “hello, world!”;}

main() {for(;;) { puts “hello, world!”;}

}

#include <stdio.h>

main() { for(;;) {

printf ("hello, world!\n"); }}

#include <stdio.h>

main() { for(;;) {

printf ("hello, world!\n"); printf ("I like you.\n"); }} I worked at SourceForge

for all of the last decade, where my job was to make sure people could share technology and make it better. Now I work in telecommunications.


I’ve gone from working in the most open ecosystem in the world to one of the most tightly controlled.


the network

You may wonder what we’re doing here.

We haven’t exactly done a good job so far of “working” with modern developers.


This is Alcatel-Lucent’s US headquarters. Raise your hand if you know what we do.

Nobody? Really? Oh, well let me tell you.


Active WDM

Central Offices

Serving Office

Regional Transport

1692 OPS

1692 MSE

1692 MSE

1692 OPS

GX 550 Multiservices

Switch

1696 MS

7342 OLT

7330 FTTN

Active DWDM

GR303 TR008 V5.2

7342 ONT Distribution

Cabinet

Splitters Up to 64

GPON ONTs per PON Line

GPON

Indoor Residential Gateway

VoIP Soft Phone

DHCP

Analog Phone

IPTV Set Top Box

Ethernet, HomePNA or MoCA

POTS

Access Point IP Services Router

Gateway TDM Switch

Sealed Expansion Module

MDU Remote Expansion

Module

DHCP

7342 ONT


Metropolis® DMXtend Access Multiplexer


Metropolis® DMXtend

Access Multiplexer

Metropolis® DMXpress Access Multiplexer

This is what we do. We sell things that let companies build and run the networks you use every day.

This graph is an example our marketing standards team uses to teach us how to make neat and legible graphs. Everything we do is complex.


And it has to be complex, because one day it’s going to be bolted into somebody’s rack...


...or buried underground...


...or left at the bottom of the sea.


Most developers (and users) see the network as something they put packets into and receive packets from.

unspeakably huge,

complex,mysterious,

stuffynetwork

thing that nobody

understands

packets

packets


the “dumb pipe”

That’s where the phrase comes from. Developers just want the network to do one thing: be a reliable pipe to put data through.


And why not? We all expect things in our everyday life to behave as if they’re simple when they’re anything but.

When I’m at home and I want to discard a liquid of some sort, I pour it in the drain.


When I want water, I get it from the faucet.

I don’t know where my waste water goes or where my fresh water comes from, I just trust that it will work. The pipes in my house are truly “dumb” to me. Or, maybe, I’m dumb to them.


This makes the networks feel kind of bad because, well, nobody likes to be taken for granted.

What? You don’t feel sorry for them? Let’s all say “awwww”.

To be fair, the networks have been taking us for granted a little bit too.

There’s another, better, reason why this is a problem.


(disclaimer: this data is complete bs, i made it up to illustrate the point)

revenue per user network demand industry awesomeness

The bigger problem is that the situation is financially untenable.

Pricing the network as a cheap commodity hasn’t been working very well.

Services have driven way more demand than anybody expected, or have designed the current business model around.

Something new has to be done, or we may see drastic changes to the net as we know it: the end of flat-rate service or more and more dropped calls).


user context

content

communicationscall control, messaging

preferences, contacts, device, location

storage, distribution, transcoding

accountingpayments, authentication, history

The networks have the potential to be more than just a commodity, though - they can offer a lot of capabilities that developers can’t get anywhere else.


Active WDM

Central Offices

Serving Office

Regional Transport

1692 OPS

1692 MSE

1692 MSE

1692 OPS


Switch

1696 MS

7342 OLT

7330 FTTN

Active DWDM

GR303 TR008 V5.2


Cabinet

Splitters Up to 64


GPON


VoIP Soft Phone

DHCP

Analog Phone

IPTV Set Top Box


POTS


Gateway TDM Switch



Module

DHCP

7342 ONT





Access Multiplexer


...?Raise your hand if you’ve had a good experience partnering with a carrier and developing against these services.

Nobody? Really? Wow!


Here’s what’s happened instead: people have found a way around.

Developers figured out how to do a lot of this stuff, while only relying on the network to send and receive packets.

This has generally been very successful, but I think that the network can play a much larger part than that.


network enablers

Active WDM

Central Offices

Serving Office

Regional Transport

1692 OPS

1692 MSE

1692 MSE

1692 OPS


Switch

1696 MS

7342 OLT

7330 FTTN

Active DWDM

GR303 TR008 V5.2


Cabinet

Splitters Up to 64


GPON


VoIP Soft Phone

DHCP

Analog Phone

IPTV Set Top Box


POTS


Gateway TDM Switch



Module

DHCP

7342 ONT





Access Multiplexer


rest

ims

parlay

sandwich

esperanto

In order for a developer to access these capabilities without needing a partnership with a carrier and a full understanding of network internals, they need to be exposed using web services.


A large benefit of exposing these capabilities through web services is that they aren’t just available to the cable router, set-top box, or mobile device that connects you to the network...they’re available to applications that run anywhere.


enablers

network provider

provider 2 provider 3

... ?The problem with network providers opening up APIs to developers is that there are so many of them. Over 700.

Partnering with a single carrier is hard, who wants to partner with 700?


enablers enablers enablers

unified network API

provider 1 provider 2 provider 3

What the industry needs is a centralized place for developers to code against that knows which network to pass the request along to.

We’re in a good position to do this because we’re close to the networks without actually being one of them.


But wait - we were talking about money. How does any of this fix the carrier business model?


location: $0.045/call sms: $0.035/call

Some networks charge developers per-call for access to their services, costing as much as five cents/call for the most expensive ones.


300,000/daysms

advertising

Let’s say, for example, you built an application using SMS and advertising, and you were able to get enough users to send 300k SMSs every day and show 500k ad impressions.

500,000/day(eCPM of $2)


revenue: $1,000/daysms cost: ($10,500)/day

net: ($9,500)/day

sms + advertising

By paying for SMS messages on a per-call basis, you could possibly lose a substantial amount of money...and, worse, it doesn’t scale.


API pricing models that charge up-front fees for developers can make it really hard to get your business off the ground.


This may be a bit of a departure, but I will come back around: Some things go really well together, like chocolate and peanut butter, strawberries and cream, mayonnaise and french fries, cocaine and baking soda.

I think the same thing holds true for network capabilities and other technology.

++

+

location +

sms + advertising

billing


$30$70

$75

$125

$700

developerad providersms providernetwork provideroverhead

Instead of charging per call, developers can use bundled APIs to share their revenues with API and network providers.

If these providers give you something of value, and you’re successful enough to make money, they get paid.

That’s what we’re working on.


revenue: $1,000/day to providers: ($300)/day

net: $700/day

sms + advertising

Using a bundled API, our example app begins to generate revenue.


This is hard. Really hard.

Not only do we need to prove that the business model works, but we need to build the APIs and convince the carriers to turn them on.

This might take a while, even though we’re being super aggressive.


If you have an API that you think might pair up with a capability from the network to make something interesting, email this guy. He’s sitting right over there.

[email protected]

redg wantsyour api

really bad


mailto:[email protected]




http://openapiservice.com

We have APIs in our lab that you can play around with. Although only one carrier is on-board now, we’re in talks with lots of carriers to expand the program.




What network API would you use in your app if we were to launch it tomorrow?

What capabilities have we not thought of?

[email protected]

what APIs should the network expose?






Smarting the Dumb Pipes

Technology

Transcript of Smarting the Dumb Pipes