Applications: History to Future Why end-to-end shouldn’t be dead Pete Resnick Protocol standards bonehead Qualcomm Technologies, Inc.

Who is this guy? This is not an academic talk – I’m an engineer: The only good code is shipping code I’m a pragmatist, not a theoretician – I used to be a coder, now I do standards – I don’t radio/chips, “Qualcomm” notwithstanding I’m an applications guy – I depend on the network below me – I don’t care what’s down there so long as it supports my apps needs – However, I know when it’s a mess I want to talk about gaps in the current architecture for apps, and what FIA things might fill them.

Back in my day… The end-to-end model was alive and well – The smarts were at the endpoints – The stupids were in the middle Every host was a first-class endpoint – Had your own IP address and domain name – Most everyone was single-homed – Could run whatever applications you liked Applications on one host talked to applications on other hosts – Who was client and who was server was about order – We had client-server-server-client, but mostly because some machines got turned off at night

Renumbering shouldn’t have changed anything, but it did Folks who run servers hated renumbering – Shouldn’t have made a difference – Update DNS – Long-lived connections are a pain, but weren’t prevalent On-and-off hosts started getting dynamic addresses – Again, update DNS; maybe more dynamically – Long-lived connections were not an issue Now, renumbering and long-lived connections matter – Deal with renumbering by using dynamic names – Deal with connections by re-rendezvous So, we need dynamically-updatable naming and application-independent re-rendezvous

Device mobility shouldn’t have changed anything, but it did More dynamic form of renumbering problem – Any given host can change – Changes can happen more quickly Much in common with multi-homed problem – It’s just that links go up and down Traditional fixes are broken – Not all problems are solved by a layer of indirection – Home base makes me not mobile – Hourglass notwithstanding, apps have a single point of failure Just need (more) dynamic names and rendezvous Same solutions as renumbering

NATs shouldn’t have changed much, but they did Renumbering problem, only worse – You may get a new number each time – Your public address is hidden – Your port numbers may be remapped But same sorts of solutions could help – Need something to get your mapping – Need to advertise address and port in DNS We need to be able to get a public address and advertise the address and port number

We’ve got tools, but they’re not deploying Multi-Path TCP (or HIP or …) provides post-connection re-rendezvous – HIP inserted a layer; apps wouldn’t deploy – MPTCP is new; jury is out PCP provides public address and port – PCP is very new – Still need a way to advertise Dynamic DNS with SRV – Should have been default; not deployed (Why?) – Without it, can’t be an addressable endpoint And then there were the incentives…

Money changes everything Routing infrastructure is expensive – Routers aren’t cheap; work as little as possible – Nobody loves multicast – Don’t want little guys pumping out data Big servers make big money – Eyeballs coming to servers sells advertising – Copyright holders want control of their stuff Support costly for full-fledged small endpoints – Security a pain; easier to cut them off Result: no more peer-to-peer or even client-server We are now back to mainframe-terminal

What do we need to get back? Network-independent dynamic naming – Routing infrastructure should be stable – Names should be re-pointable Re-negotiate and re-rendezvous addresses – If one side changes, all I need is to re-negotiate – Both sides changing simultaneously is rare Will need re-rendezvous for that – Should be application independent Ability to source data without being costly – Shouldn’t need a server (or a datacenter or cloud) – From an apps perspective, couldn’t care less about supporting big content providers

Analysis Caveats – Doing this from fast read and presentations – Looking at a few here; more during discussion

Analysis MobilityFirst – Dynamic name resolution big win – Not clear to me how I discover things – Depending on a web-of-trust sounds like work for me NDN – Named data and caching in the net helps apps – Puts a lot of pressure on routing infrastructure Will they be willing? – Seems designed for big distribution of data What about “uninteresting” data between two ends? ChoiceNet – Architecturally not a problem for apps – Economics for small apps with little data seems scary

Discussion