June 19, 2007 Intel-UCSD (Santa Clara) Network technology transition & testbeds Henning Schulzrinne Dept. of Computer Science Columbia University

June 19, 2007 Intel-UCSD (Santa Clara)

Network technology transition & testbeds

Henning Schulzrinne

Dept. of Computer Science

Columbia University


Overview

• Networking technology evolution• Why do good ideas fail?• The role of testbeds• The limitations of testbeds• Moving research into the real world


Internet transition: applications

• Moving analog applications to Internet– digitization of communication largely completed

• Extending reach of application– mobile devices– vehicles

• Broadening access– Minitel: SNCF had train schedule service– web: anybody can have a blog

• Allowing customization and creation– web pages to code modules


Completing the migration of comm. applications

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.





QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.








Migration of applications










text, still images

audio video

synchronous IM VoIP video conferencing

asynchronous email email, voicemail

YouTube


What’s wrong with the Internet - user perspective

• Lack of trust– small mistakes identity gone– can’t tell when one has “lost the wallet”– waste time on spam, viruses, worms, spyware, …

• Lack of reliability– 99.5% instead of 99.999%– even IETF meeting can’t get reliable 802.11 connectivity

• Lack of symmetry– asymmetric bandwidth: ADSL– asymmetric addressing: NAT, firewalls client(-server) only, packet relaying

via TURN or p2p• Users as “Internet mechanics”

– why does a user need to know whether to use IMAP or POP?– navigate circle of blame


Lifecycle of technologies

military corporate consumer

traditional technology propagation:

opex/capex

doesn’t matter;expert support

capex/opex

sensitive, but

amortized;expert support

capex sensitive;amateur

Can it be done? Can I afford it? Can my mother use it?

COTS(e.g., GPS)

IM, digital photo


Research reality










are needed to see this picture.QuickTime™ and a

TIFF (Uncompressed) decompressorare needed to see this picture.











new scheduling algorithm

cell-based networksdistributed data structuresnetwork coding

protocols

architecture(Internet, VoIP, DTN, ...)

95% of effort


What has made the Internet successful?

• 36 years approaching mid-life crisis time for self-reflection

next generation suddenly no longer finds it hip

• Transparency in the core– new applications (web, VoIP, games)

• Narrow interfaces– socket interface, resolver

• HTTP and SMTP messaging as applications

– prevent change leakage

• Low barrier to entry– L2: minimalist assumptions– technical: basic connectivity is within– economical: below $20?

• Commercial off-the-shelf systems– scale: compare 802.11 router vs. cell base station




Cause of death for the next big thing

QoS multi-

cast

mobile IP

active networks

IPsec IPv6

not manageable across competing domains

not configurable by normal users (or apps writers)

no business model for ISPs no initial gain 80% solution in existing system

(NAT)

increase system vulnerability


Why do good ideas fail?

• Research: O(.), CPU overhead– “per-flow reservation (RSVP) doesn’t scale” not

the problem– at least now -- routinely handle O(50,000) routing

states

• Reality:– deployment costs of any new L3 technology is

probably billions of $– coordination costs

• The QoS problem is a lawyer problem, not an engineering problem

• Cost of failure:– conservative estimate (1 grad student year = 2

papers)– 10,000 QoS papers @ $20,000/paper $200

million

QoS quality-of-service

IEEE 10,377 12,876

ACM 3,487 4,388


Good ideas

• Myth: Good ideas will win– “Build a better mousetrap and the world will beat a path to your door.” (Ralph

Waldo Emerson)– modern version: IEEE 802.11 will dig through IEEE Infocom proceedings to

find your master paper– even most Sigcomm papers have had no (engineering) impact

• Myth: Just ahead of its time – it will take 10 years to have impact– reality: most papers either have immediate impact or none, ever

• Mediocre ideas with commitment win over brilliant ideas without– particularly if part of a larger system– cost of understanding ideas– possible encumbrances (patents) researchers need to accompany their “children” through teenage years


More reasons for failure

• Old good enough– reliability and familiarity outweighs modest gains in performance

– ATM in LANs

• No real need– QoS: VoIP may finally motivate

• Not worth the money - price, not technology– video conferencing: succeeds once no incremental cost

– 802.11 wireless, GPS

• Value not captured– those getting the benefit not willing to pay for it

– e.g., enabling unknown new applications

• Market niche disappears– cell switching vs. packet switching


The Hockeystick Problemutility

adoption

1.0

complexitysecurity risks

bandwidth


Internet: What has gone wrong?

• Familiar to anybody who has an old house…• Entropy

– as parts are added, complexity and interactions increase• Changing assumptions

– trust model: research colleagues far more spammers and phishers than friends• AOL: 80% of email is spam

– internationalization: internationalized domain names, email character sets

– criticality: email research papers transfers $B and dial “9-1-1”– economics: competing providers

• “Internet does not route money” (Clark)• Backfitting

– had to backfit security, I18N, autoconfiguration, … Tear down the old house, gut interior or more wall paper?


Core goals for new networks

• reliability

• diagnosability

• sustainability

• adaptability

• survivability


(My) guidelines for a new Internet

• Maintain success factors, such as

– service transparency– low barrier to entry– narrow interfaces

• New guidelines– optimize human cycles, not

CPU cycles– design for symmetry– security built-in, not bolted-on– everything can be mobile,

including networks– sending me data is a privilege,

not a right– reliability paramount– isolation of flows

• New possibilities:– another look at circuit switching?– knowledge and control

(“signaling”) planes?– separate packet forwarding from

control– better alignment of costs and

benefit– better scaling for Internet-scale

routing– more general services– storage and computation as

network services


Impact of networking research

• Very low publication-to-impact ratio• Brilliant idea, magically transformed into reality

– by somebody else

• Research as point scoring– publication count– citation by other papers, also without impact– read mostly by other researchers– goal: graduate/get tenure


Who’s the customer?

• Goals may not be identical– Equipment vendors: preserve investment, confirm earlier

choices• ATM, SS7

– Carrier: preserve product differentiation, business model, customer lock-in, monopoly rent, …

• walled gardens, WAP, AAA, DRM, IMS, …

– Consumer: fashion, functionality, cost• search engines, WiFi, MP3, Skype, web hosting, …

• Easier for some organizations– e.g., Google: direct customer is advertiser, but revenue driven by

page views consumer


Why testbeds?

• Hardware is cheap– project-specific --> avoid reproducability problems

• Can’t build it at one institution– cost– scale (distances, nodes)– maintenance (technicians, programmers)

• Can’t justify at one institution– cost vs. usage intensity


Four testbed flavors

• Experimental system: build, evaluate, write– PlanetLab, EmuLab, ORBIT– usually under-resourced

• Demo platform– show sponsor that money was not wasted– gain user visibility

• Deployment platform– e.g., Coral on PlanetLab– geographic reach: within one-hop access by millions– user privacy concerns

• Migration path (pre-commercial)– Internet2 (maybe)– limited evidence (economics vs. technology)– user privacy concerns, particularly for data plane



users








Testbed limitations

• Small scale (10s of nodes)– unlikely to test scalability of IPv8 or BGP++

• Friendly users– Internet2 can send malicious users to the dean’s office

• Difficult to build community– the less commodity, the harder (learning curve for grad students)– unclear transition path (cf. Linux)

• Fake economics– usually, free to end users– administered by wizards

• Mostly landline– spectrum and cost prevent large-scale mobile testbeds– user interest is in ubiquitous mobility

• System vs. components– can only change one component at a time


Conclusion

• Start from problem definition, not testbed (or $300M...)– user-focused, not researcher toys– just more QoS and multicast?– different from other research areas: plumbing vs. new capabilities– will it prevent spam and just work out of the box?

• Good research practices and evaluation– or is everybody else supposed to do the hard work?– rising expectations: can’t assume friendly Internet of 1980s

• Realistic expectations for testbeds– different targets

• reproducibility vs. usability

– scale• just large enough

• Consider federation of testbeds– combine scale and reproducibility

Documents

June 19, 2007 Intel-UCSD (Santa Clara) Network technology transition & testbeds Henning Schulzrinne Dept. of Computer Science Columbia University