Principles and lessons for a new internet and 4g wireless networks
1 / 75

Principles and Lessons for a New Internet and 4G Wireless Networks - PowerPoint PPT Presentation

  • Uploaded on

Principles and Lessons for a New Internet and 4G Wireless Networks. Prof. Henning Schulzrinne Dept. of Computer Science Columbia University. Overview. Interest in revising Internet architecture What didn’t we think of the first time What has made the Internet successful

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Principles and Lessons for a New Internet and 4G Wireless Networks' - EllenMixel

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Principles and lessons for a new internet and 4g wireless networks l.jpg

Principles and Lessons for a New Internet and 4G Wireless Networks

Prof. Henning Schulzrinne

Dept. of Computer Science

Columbia University

WWIC (Coimbra, Portugal)

Overview l.jpg
Overview Networks

  • Interest in revising Internet architecture

    • What didn’t we think of the first time

    • What has made the Internet successful

    • Built-in vs. bolted on

  • User issues: what bothers users

  • Internet infrastructure: the plumbing

  • Network management

  • Talking meta: research and standardization

WWIC (Coimbra, Portugal)

Outline l.jpg
Outline Networks

  • Applications and upper layers

  • Internet protocol infrastructure

  • Network management

  • Network standards

  • Networking research

WWIC (Coimbra, Portugal)

The three cs of internet applications l.jpg
The three Cs of Internet applications Networks

grossly simplified...




what users care about

what users care about



WWIC (Coimbra, Portugal)

Killer application l.jpg
Killer Application Networks

  • Carriers looking for killer application

    • justify huge infrastructure investment

    • “video conferencing” (*1950 – †2000)

    • ?

  • “There is no killer application”

    • Network television block buster  YouTube hit

    • “Army of one”

    • Users create their own custom applications that are important to them

    • Little historical evidence that carriers (or equipment vendors) will find that application if it exists

  • Killer app = application that kills the carrier

WWIC (Coimbra, Portugal)

Internet transition applications l.jpg
Internet transition: applications Networks

  • 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

WWIC (Coimbra, Portugal)

Completing the migration of comm applications l.jpg
Completing the migration of comm. applications Networks

WWIC (Coimbra, Portugal)

Migration of applications l.jpg
Migration of applications Networks

WWIC (Coimbra, Portugal)

Building internet applications l.jpg
Building Internet applications Networks

80% care about this level

extensible CMS, Wiki

(Drupal, Mambo, Joomla, ...)

Ruby on Rails, Spring, ...

Ajax, SOAP

PHP, Java w/libraries


taught in Networking 101

C/C++ with sockets

custom protocols on UDP, TCP

WWIC (Coimbra, Portugal)

User issues guesses l.jpg
User issues (guesses) Networks

  • 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

WWIC (Coimbra, Portugal)

Left to do glue protocols l.jpg
Left to do: glue protocols Networks

  • Lots of devices and services

    • cars

    • household

    • environment

  • Generally, stand-alone

    • e.g., GPS can’t talk to camera

  • Home

    • home control networks have generally failed

      • cost, complexity

  • Environment

    • “Internet of things”

    • tag bus stops, buildings, cars, ...

WWIC (Coimbra, Portugal)

Left to do event notification l.jpg
Left to do: event notification Networks

  • notify (small) group of users when something of interest happens

    • presence = change of communications state

    • email, voicemail alerts

    • environmental conditions

    • vehicle status

    • emergency alerts

  • kludges

    • HTTP with pending response

    • inverse HTTP --> doesn’t work with NATs

  • Lots of research (e.g., SIENA)

  • IETF efforts starting

    • SIP-based

    • XMPP

WWIC (Coimbra, Portugal)

Geopriv and simple architectures l.jpg
GEOPRIV and SIMPLE architectures Networks































WWIC (Coimbra, Portugal)

Configuration complexity l.jpg
Configuration complexity Networks

  • 65% of attacks exploit mis-configured systems

  • Human error accounts for 48% of wide area network outages

    • Yankee Group 2002: operator error is the largest cause of failures and largest contributor to time to repair; in two of the three (surveyed) ISPs, configuration errors are the largest category of operator errors.

  • 45% WAN operations cost attributed to component configuration

    • Yankee Group, 1998

  • Although setup (of the trusted computing base) is much simpler than code, it is still complicated, it is usually done by less skilled people, and while code is written once, setup is different for every installation. So we should expect that it’s usually wrong, and many studies confirm this expectation. (B. Lampson)

WWIC (Coimbra, Portugal)

Open issues configuration l.jpg

Ideally, applications should only need a user name and some credential

password, USB key, host identity (MAC address), …

More than DHCP: device needs to get

application services


security variations

policy information (“sorry, no video”)

user data (address book)

Multiple sources of configuration information

local network

application service provider

Configuration information may change dynamically

event notification

Needs to allow no-touch deployment of thousands of devices

Open issues: Configuration

WWIC (Coimbra, Portugal)

Mobile systems reality l.jpg
Mobile systems - reality credential


  • idea: special purpose (phone) --> universal communicator

    • idea is easy...

  • mobile equipment: laptop + phone

    • sufficiently different UI and capabilities

  • we all know the ideal (converged) cell phone

  • difficulty is not technology, but integration and programmability

    • (almost) each phone has a different flavor of OS

    • doesn’t implement all functionality in Java APIs

    • no dominant vendor (see UNIX/Linux vs. Microsoft)

    • external interfaces crippled or unavailable

      • e.g., phone book access

location data

WWIC (Coimbra, Portugal)

Outline17 l.jpg
Outline credential

  • Applications and upper layers

  • Internet protocol infrastructure

  • Network management

  • Network standards

  • Network research

WWIC (Coimbra, Portugal)

What has made the internet successful l.jpg
What has made the Internet successful? credential

  • 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

WWIC (Coimbra, Portugal)

What has gone wrong l.jpg
What has gone wrong? credential

  • 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?

WWIC (Coimbra, Portugal)

In more detail l.jpg
In more detail… credential

  • Deployment problems

    • loss of transparency (NATs, deep-packet inspection, ...)

  • Layer creep

  • Simple and universal wins

  • Scaling in human terms

  • Cross-cutting concerns, e.g.,

    • CPU vs. human cycles

      • we optimize the $100 component, not the $100/hour labor

    • introspection

    • graceful upgrades

    • no policy magic

WWIC (Coimbra, Portugal)

Internet design principles l.jpg
Internet design principles credential

did not anticipate cyber attack, exfiltration, malicious control

cooperative protocols --> insider threat

“permit-by-default” instead of “deny-by-default”

malicious use of resources remains anonymous & untraceable

J Christopher Ramming, IAMANET briefing, April 2006, based on D. Clark, SIGCOMM 1998

WWIC (Coimbra, Portugal)

Core goals for new networks l.jpg
Core goals for new networks credential

  • reliability

  • diagnosability

  • sustainability

  • adaptability

  • survivability

WWIC (Coimbra, Portugal)

Survivability l.jpg
Survivability credential

  • Real world: locks keep out the honest

    • until the police arrives

  • Internet: assumption of lawlessness

    • no global law enforcement

    • carriers have little interest in policing their users

      • bots, spam

    • must survive extended periods of attacks

  • From permit-by-default to deny-by-default

WWIC (Coimbra, Portugal)

Reliability l.jpg
Reliability credential

  • From secondary medium to core

    • Office without phone vs. without Internet

  • Applications: 2 servers exponentially better than 1

    • costs “only” doubles

    • but most application protocols don’t fail over automatically

      • examples: HTTP, IMAP, POP, NFS

      • exceptions: SMTP, SIP

  • Networks: 2 networks exponentially better than 1

    • most (US) residences are served by 3 networks: DSL, cable, cellular

    • no good multi-homing technology that scales

    • economics dubious - via neighbors?

WWIC (Coimbra, Portugal)

The transformation of protocol stacks l.jpg

Internet credential

ca. 2005

H. Zimmermann

ca. 1980


ca. 1995






















The transformation of protocol stacks

WWIC (Coimbra, Portugal)

Cause of death for the next big thing l.jpg
Cause of death for the next big thing credential

WWIC (Coimbra, Portugal)

Simple wins mostly l.jpg
Simple wins (mostly) credential

  • Examples:

    • Ethernet vs. all other L2 technologies

    • HTTP vs. HTTPng and all the other hypertext attempts

    • SMTP vs. X.400

    • SDP vs. SDPng

    • TLS vs. IPsec (simpler to re-use)

    • no QoS & MPLS vs. RSVP

    • DNS-SD (“Bonjour”) vs. SLP

    • SIP vs. H.323 (but conversely: SIP vs. Jabber, SIP vs. Asterisk)

    • the failure of almost all middleware

    • future: demise of 3G vs. plain SIP

  • Efficiency is not important

    • BitTorrent, P2P searching, RSS, …

WWIC (Coimbra, Portugal)

Measuring complexity l.jpg
Measuring complexity credential

  • Traditional O(.) metrics rarely helpful

    • except maybe for routing protocols

  • Focus on parsing, messaging complexity

    • marginally helpful, but no engineering metrics for trade-offs

  • No protocol engineering discipline, lacking

    • guidelines for design

    • learning from failures

      • we have plenty to choose from – but hard to look at our own (communal) failures

    • re-usable components

      • components not designed for plug-and-play

      • “we don’t do APIs”  we don’t worry about whether a simple API can be written that can be taught in Networking 101

WWIC (Coimbra, Portugal)

Possible complexity metrics l.jpg
Possible complexity metrics credential

  • new code needed (vs. reuse)  less likely to be buggy or have buffer overflows

    • e.g., new text format almost the same

    • numerous binary formats

    • security components

    • necessary transition: bespoke  off-the-rack protocols

  • new identities and identifiers needed

  • number of configurable options + parameters

    • must be configured & can be configured (with interop impact)

    • discoverable vs. manual/unspecified

    • SIP experience: things that shouldn’t be configurable will be

    • RED experience: parameter robustness

    • mute programmer interop test: two implementations, no side channel

  • number of “left-to-local policy”

    • DSCP confusion

  • start-up latency (“protocol boot time”)

    • IPv4 DAD, IGMP

WWIC (Coimbra, Portugal)

Democratization of protocol engineering l.jpg
Democratization of protocol engineering credential

  • Traditional Internet application protocols (IETF et al.):

    • one protocol for each type of application:

      • SMTP for email, ftp for file transfer, HTTP for web access, POP for email retrieval, NNTP for netnews, …

      • slow protocol development process

      • re-do security (authentication) for each

      • each new protocol has its own text encoding

        • similarity across protocols: SMTP-style headers

          • Content-Type: text/plain; charset="us-ascii"; format=flowed

        • large parsing exposure  new buffer overflows for each protocol

  • Separate worlds:

    • most of the new protocols in the real world based on WS

    • IETF stuck in bubble of one-off protocols  more fun!

      • re-use considered a disadvantage

      • insular protocols that have local cult following (BEEP)

WWIC (Coimbra, Portugal)

The transformation of protocol design l.jpg
The transformation of protocol design credential

  • One application, one protocol  common infrastructure for new application

  • Old model:

    • RPC for corporate “one-off” applications

    • custom protocols for common Internet-scale applications

  • Far too many new applications

    • and not enough protocol engineers

    • network specialist  application specialist

    • new IETF application protocol design takes ~5 years

  • Many of the applications (email to file access) could be modeled as RPC

custom text protocol



(SNMP, X.400)

RFC 822 protocol


use XML for protocol bodies

(IETF IM & presence)

SOAP and other XML protocols

WWIC (Coimbra, Portugal)

Why are web services succeeding after rpc failed l.jpg
Why are web services succeeding(*) after RPC failed? credential

  • SOAP = just another remote procedure call mechanism

    • plenty of predecessors: SunRPC, DCE, DCOM, Corba, …

    • “client-server computing”

    • all of them were to transform (enterprise) computing, integrate legacy applications, end world hunger, …

  • Why didn’t they?

  • Speculation:

    • no web front end (no three-tier applications)

    • few open-source implementations

    • no common protocol between PC client (Microsoft) and backend (IBM mainframes, Sun, VMS)

    • corporate networks local only (one site), with limited backbone bandwidth




WWIC (Coimbra, Portugal)

(*) we hope

Time for a new protocol stack l.jpg
Time for a new protocol stack? credential

  • Now: add x.5 sublayers and overlay

    • HIP, MPLS, TLS, …

  • Doesn’t tell us what we could/should do

    • or where functionality belongs

    • use of upper layers to help lower layers (security associations, authorization)

    • what is innate complexity and what is entropy?

  • Examples:

    • Applications: do we need ftp, SMTP, IMAP, POP, SIP, RTSP, HTTP, p2p protocols?

    • Network: can we reduce complexity by integrating functionality or re-assigning it?

      • e.g., should e2e security focus on transport layer rather than network layer?

    • probably need pub/sub layer – currently kludged locally (email, IM, specialized)

WWIC (Coimbra, Portugal)

Nsf green field approach l.jpg
NSF “Green Field” approach credential

  • US National Science Foundation (NSF) working on new funding thrust  next-generation Internet

    • idea: incremental components  new architecture

    • vs. traditional “brown field” approach

  • Two major components

    • GENI: large-scale experimental testbed for testing next-generation ideas

      • building on PlanetLab (hundreds of public-access servers)  p2p, CDN, measurement infrastructures

      • probably offers circuits (optical or virtual with bandwidth guarantees)

      • ~$300M (not yet allocated)

    • FIND:

      • regular research program within NETS ($15m)

      • prepare architecture designs

WWIC (Coimbra, Portugal)

Nsf find and geni cont d l.jpg
NSF: FIND and GENI, cont’d credential

  • Fundamental notions:

    • not constrained by existing Internet architecture

  • Difficulties:

    • not coordinated  too many moving pieces?

    • no single research team can do everything

    • point optimization: Internet for

    • benchmarks missing

      • how do you compare architectures?

      • are there quantifiable requirements?

      • are there metrics to compare different approaches?

      • user-related metrics?

  • Cynic’s prediction based on the past:

    • IPv6: “you’ll get security, QoS, autoconfiguration, mobility, …”

    • IPv4: “good ideas, I’ll do those, too”

WWIC (Coimbra, Portugal)

My guidelines for a new internet l.jpg

Maintain success factors, such as credential

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

(My) guidelines for a new Internet

WWIC (Coimbra, Portugal)

More network services l.jpg
More “network” services credential

  • Currently, very specialized and limited

    • packet forwarding

    • DNS for identifier lookup

    • DHCP for configuration

  • New opportunities

    • packet forwarding with control

    • general identifier storage and lookup

      • both server-based and peer-to-peer

    • SLP/Jini/UDDI service location  ontology-based data store

    • network file storage  for temporarily-disconnected mobiles

    • network computation  translation, relaying

    • trust services ( IRT trust paths work)

WWIC (Coimbra, Portugal)

Security l.jpg

More than just encryption! credential

Need identity and role-based certificates

May want reverse-path reachability (bank  customer)


WWIC (Coimbra, Portugal)

Ngn or what s wrong with 3g l.jpg
NGN or what’s wrong with 3G credential

  • NGN = next-generation network

    • roughly, 3G on landline

    • really, ISDN 2.0 on packets

    • SIP for signaling, IPv6

  • Problems

    • complexity: gateways to old world

    • coupling: link-layer properties only available to certain applications

      • e.g., voice-specific link behavior (FEC, delay)

    • closed: may be difficult to integrate with enterprise systems

      • regular SIP phones may not work properly

WWIC (Coimbra, Portugal)

What s my 4g l.jpg
What’s (my) 4G? credential

  • Definition: fixes all the things that 3G got wrong...

    • voice legacy (3G ~ B-ISDN)

    • high cost

    • system complexity

  • Wireless as access network

    • already happening: 3G-802.11 bridges

    • application shouldn’t care about access mode or carrier --> more applications

  • But with discoverable and configurable path properties

    • not a wireless-specific issue!

  • May be less a technical than economics problem

    • same bits, different value --> capture consumer surplus

WWIC (Coimbra, Portugal)

Internet re engineering summing up l.jpg
Internet (re)engineering: summing up credential

  • Traditional protocol engineering

    • “must do congestion control”

    • “must do security”

    • “must be efficient”

  • New module engineering

    • must reduce operations cost

    • out-of-the-box experience

    • re-usable components

      • most protocol design will be done by domain experts (cf. PHP vs. C++)

  • What would a clean-room design look like?

    • keep what made Internet successful

    • generalize & adjust to new conditions

WWIC (Coimbra, Portugal)

Outline42 l.jpg
Outline credential

  • User perspective

  • Internet protocol infrastructure

  • Network management

  • Network standards

  • Networking research

WWIC (Coimbra, Portugal)

Network management transition in cost balance l.jpg
Network Management credential Transition in cost balance

  • Total cost of ownership

    • Ethernet port cost  $10

    • about 80% of Columbia CS’s system support cost is staff cost

      • about $2500/person/year  2 new PCs/year

      • much of the rest is backup & license for spam filters 

  • Does not count hours of employee or son/daughter time

  • PC, Ethernet port and router cost seem to have reached plateau

    • just that the $10 now buys a 100 Mb/s port instead of 10 Mb/s

  • All of our switches, routers and hosts are SNMP-enabled, but no suggestion that this would help at all

WWIC (Coimbra, Portugal)

Circle of blame l.jpg
Circle of blame credential

probably packet

loss in your

Internet connection 

reboot your DSL modem


probably a gateway fault

 choose us as provider



must be a

Windows registry

problem  re-install




must be

your software

 upgrade

WWIC (Coimbra, Portugal)

Diagnostic undecidability l.jpg
Diagnostic undecidability credential

  • symptom: “cannot reach server”

  • more precise: send packet, but no response

  • causes:

    • NAT problem (return packet dropped)?

    • firewall problem?

    • path to server broken?

    • outdated server information (moved)?

    • server dead?

  • 5 causes  very different remedies

    • no good way for non-technical user to tell

  • Whom do you call?

WWIC (Coimbra, Portugal)

Voip user experience l.jpg
VoIP user experience credential

  • Only 95-99.5% call attempt success

    • “Keynote was able to complete VoIP calls 96.9% of the time, compared with 99.9% for calls made over the public network. Voice quality for VoIP calls on average was rated at 3.5 out of 5, compared with 3.9 for public-network calls and 3.6 for cellular phone calls. And the amount of delay the audio signals experienced was 295 milliseconds for VoIP calls, compared with 139 milliseconds for public-network calls.” (InformationWeek, July 11, 2005)

  • Mid-call disruptions common

  • Lots of knobs to turn

    • Separate problem: manual configuration

WWIC (Coimbra, Portugal)

Traditional network management model l.jpg
Traditional network management model credential



“management from the center”

WWIC (Coimbra, Portugal)

Old assumptions now wrong l.jpg
Old assumptions, now wrong credential

  • Single provider (enterprise, carrier)

    • has access to most path elements

    • professionally managed

  • Problems are hard failures & elements operate correctly

    • element failures (“link dead”)

    • substantial packet loss

  • Mostly L2 and L3 elements

    • switches, routers

    • rarely 802.11 APs

  • Problems are specific to a protocol

    • “IP is not working”

  • Indirect detection

    • MIB variable vs. actual protocol performance

  • End systems don’t need management

    • DMI & SNMP never succeeded

    • each application does its own updates

WWIC (Coimbra, Portugal)

Management l.jpg
Management credential

what causes the most trouble?

network understanding

fault location

we’ve only succeeded here


element inspection

WWIC (Coimbra, Portugal)

Managing the protocol stack l.jpg
Managing the protocol stack credential

protocol problem


asymmetric conn (NAT)



gain problems

VAD action



protocol problem

playout errors


TCP neg. failure

NAT time-out

firewall policy


no route

packet loss

WWIC (Coimbra, Portugal)

Types of failures l.jpg
Types of failures credential

  • Hard failures

    • connection attempt fails

    • no media connection

    • NAT time-out

  • Soft failures (degradation)

    • packet loss (bursts)

      • access network? backbone? remote access?

    • delay (bursts)

      • OS? access networks?

    • acoustic problems (microphone gain, echo)

WWIC (Coimbra, Portugal)

Examples of additional problems l.jpg
Examples of additional problems credential

  • ping and traceroute no longer works reliably

    • WinXP SP 2 turns off ICMP

    • some networks filter all ICMP messages

  • Early NAT binding time-out

    • initial packet exchange succeeds, but then TCP binding is removed (“web-only Internet”)

  • policy intent vs. failure

    • “broken by design”

    • “we don’t allow port 25” vs. “SMTP server temporarily unreachable”

WWIC (Coimbra, Portugal)

Proposal do you see what i see l.jpg
Proposal: “Do You See What I See?” credential

  • Each node has a set of active and passive measurement tools

  • Use intercept (NDIS, pcap)

    • to detect problems automatically

      • e.g., no response to HTTP or DNS request

    • gather performance statistics (packet jitter)

    • capture RTCP and similar measurement packets

  • Nodes can ask others for their view

    • possibly also dedicated “weather stations”

  • Iterative process, leading to:

    • user indication of cause of failure

    • in some cases, work-around (application-layer routing)  TURN server, use remote DNS servers

  • Nodes collect statistical information on failures and their likely causes

WWIC (Coimbra, Portugal)

Architecture l.jpg
Architecture credential

“not working”


request diagnostics

orchestrate tests

contact others

inspect protocol requests



can buddy reach our resolver?

“DNS failure for 15m”

notify admin

(email, IM, SIP events, …)

WWIC (Coimbra, Portugal)

Failure detection tools l.jpg
Failure detection tools credential

  • STUN server

    • what is your IP address?

  • ping and traceroute

  • Transport-level liveness and QoS

    • open TCP connection to port

    • send UDP ping to port

    • measure packet loss & jitter

  • TBD: Need scriptable tools with dependency graph

    • initially, we’ll be using ‘make’

  • TBD: remote diagnostic

    • fixed set (“do DNS lookup”) or

    • applets (only remote access)





WWIC (Coimbra, Portugal)

Failure statistics l.jpg
Failure statistics credential

  • Which parts of the network are most likely to fail (or degrade)

    • access network

    • network interconnects

    • backbone network

    • infrastructure servers (DHCP, DNS)

    • application servers (SIP, RTSP, HTTP, …)

    • protocol failures/incompatibility

  • Currently, mostly guesses

  • End nodes can gather and accumulate statistics

WWIC (Coimbra, Portugal)

Outline57 l.jpg
Outline credential

  • User perspective

  • Internet protocol architecture

  • Network management

  • Network standards

  • Networking research

WWIC (Coimbra, Portugal)

The role of standards l.jpg
The role of standards credential

  • Most users won’t see network improvements until standard emerges

    • gatekeeper

  • Exceptions

    • De-facto standards (Microsoft)

    • TCP enhancements -- via OS

    • Some new tools (Skype)

WWIC (Coimbra, Portugal)

Standards work l.jpg
Standards Work credential

  • Old approach

    • standards group goes to Geneva

    • Input: dinners

    • Output: PowerPoint

    • software groups convert finished standard into products (maybe)

  • New approach

    • standards contributors directly develop (or supervise) libraries, prototypes and other tools

      • possibly in conjunction with academic research groups

    • early, pre-completion feedback

    • rapid early release  possible early implementation IPR

    • train development staff

    • participate in interop testing

WWIC (Coimbra, Portugal)

Sip sipping simple 00 drafts l.jpg
SIP, SIPPING & SIMPLE –00 drafts credential

includes draft-ietf-*-00 and draft-personal-*-00

WWIC (Coimbra, Portugal)

Rfc publication l.jpg
RFC publication credential

WWIC (Coimbra, Portugal)

Trouble in standards land l.jpg
Trouble in Standards Land credential

  • Proliferation of transition standards: 2.5G, 2.6G, 3.5G, …

    • true even for emergency calling…

  • Splintering of standardization efforts across SDOs

    • primary:


    • architectural:

      • PacketCable, ETSI, 3GPP, 3GPP2, OMA, UMA, ATIS, …

    • specialized:

      • NENA

    • operational, marketing:

      • SIP Forum, IPCC, …















WWIC (Coimbra, Portugal)

Ietf issues l.jpg

SIP WGs: small number (dozen?) of core authors (80/20) credential

some now becoming managers…

or moving to other topics

IETF: research  engineering  maintenance

many groups are essentially maintaining standards written a decade (or two) ago


constrained by design choices made long ago

often dealing with transition to hostile & “random” network

network ossification

Stale IETF leadership

often from core equipment vendors, not software vendors or carriers

fair amount of not-invented-here syndrome

late to recognize wide usage of XML and web standards

late to deal with NATs

security tends to be per-protocol (silo)

some efforts such as SAML and SASL

tendency to re-invent the wheel in each group

IETF issues

WWIC (Coimbra, Portugal)

Ietf issue timeliness l.jpg

Most drafts spend lots of time in 90%-complete state credential

lack of energy (moved on to new -00)

optimizers vs. satisfiers

multiple choices that have non-commensurate trade-offs

Notorious examples:

SIP request history: Feb. 2002 – May 2005 (RFC 4244)

Session timers: Feb. 1999 – May 2005 (RFC 4028)

Resource priority: Feb. 2001 – Feb 2006 (RFC 4412)

New framework/requirements phase adds 1-2 years of delay

Three bursts of activity/year, with silence in-between

occasional interim meetings

IETF meetings are often not productive

most topics gets 5-10 minutes  lack context, focus on minutiae

no background  same people as on mailing list

5 people discuss, 195 people read email

No formal issue tracking

some WGs use tools, haphazardly

Gets worse over time:

dependencies increase, sometimes undiscovered

backwards compatibility issues

more background needed to contribute

IETF issue: timeliness

WWIC (Coimbra, Portugal)

Outline65 l.jpg
Outline credential

  • User perspective

  • Internet protocol infrastructure

  • Network management

  • Network standards

  • Networking research

WWIC (Coimbra, Portugal)

Lifecycle of technologies l.jpg
Lifecycle of technologies credential


(e.g., GPS)

traditional technology propagation:

IM, digital photo




opex/capex doesn’t matter;

expert support

capex/opex sensitive, but amortized;

expert support

capex sensitive;


Can I afford it?

Can it be done?

Can my mother use it?

WWIC (Coimbra, Portugal)

Science vs engineering l.jpg
Science vs. Engineering credential

  • Computer Science has identity crisis: applied math, experimental science or engineering?

  • Applied math

    • general abstractions & elegant models

    • reality only a distant motivator

    • metric: can it be published in J Applied Probability?

  • Experimental science

    • emphasis on general insights

    • measurements & models

    • often reflective: “analyze Gnutella structure”

    • point solutions

    • metric: does it fit Small World and is it self-similar? is it optimal?

  • Engineering

    • emphasis on real-world impact

    • constrained by existing large systems

    • system solutions: needs to play nice with rest of the world

    • metrics: scalability, cost, maintainability, implementability

  • Honesty about what we’re doing

WWIC (Coimbra, Portugal)

Traditional research l.jpg
Traditional research credential

  • Inspired by physics or chemistry

  • Physics: Theory  experiment  lab bench  prototype  (semiconductor) product

    • Communications: Research  advanced development  development

  • Necessary for hardware

  • Dubious for software-intensive systems

    • rewrite several times (if not forgotten)

    • less qualified each time

    • BL example: Unix

WWIC (Coimbra, Portugal)

Who s the customer l.jpg
Who’s the customer? credential

  • 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

WWIC (Coimbra, Portugal)

Good ideas l.jpg
Good ideas credential

  • 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

WWIC (Coimbra, Portugal)

Translation into practice l.jpg
Translation into Practice credential

  • Relay model

    • research  advanced development  product

    • information loss rate of 95%?

    • lack of sense of ownership

    • hand-off: original owners have moved on to next project

  • Google model

    • repeated, continuous refinement

    • public beta

    • no separate “research”

    • still has problems with polish & completion

WWIC (Coimbra, Portugal)

Impact of networking research l.jpg
Impact of networking research credential

  • 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

WWIC (Coimbra, Portugal)

Why do good ideas fail l.jpg
Why do good ideas fail? credential

  • 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

  • WWIC (Coimbra, Portugal)

    Aside the hockeystick problem l.jpg
    Aside: The Hockeystick Problem credential




    security risks



    WWIC (Coimbra, Portugal)

    Conclusion l.jpg
    Conclusion credential

    • 2nd systems economics problems, not just technology

    • Challenges are in reliability and maintainability, rather than performance or packet-loss & jitter QoS

    • Is networking research becoming like civil engineering: large, important infrastructure, but resistant to fundamental change?

    • Existing management tools of limited use to most enterprises and end users

    • Transition to “self-service” networks

      • support non-technical users

    • As a community, need to learn more from our collective and individual mistakes…

      • Need series “The design mistakes in [(formerly) popular system or protocol]”

    WWIC (Coimbra, Portugal)