Principles and Lessons for a New
Internet and 4G Wireless Networks
Prof. Henning Schulzrinne
Dept. of Computer Science
Columbia University
May 2007
WWIC (Coimbra, Portugal)
1
Overview
• 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
May 2007
WWIC (Coimbra, Portugal)
2
Outline
•
•
•
•
•
Applications and upper layers
Internet protocol infrastructure
Network management
Network standards
Networking research
May 2007
WWIC (Coimbra, Portugal)
3
The three Cs of Internet applications
grossly simplified...
communications
research
focus
May 2007
commerce
community
what users care about
WWIC (Coimbra, Portugal)
5
Killer Application
• 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
May 2007
WWIC (Coimbra, Portugal)
6
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
May 2007
WWIC (Coimbra, Portugal)
7
Completing the migration of comm. applications
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
Qui ckTime™ and a
TIFF (U ncompr essed) decompressor
are needed to see thi s pi cture.
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
May 2007
QuickTi me™ and a
TIFF ( Uncompressed) decompressor
are needed to see thi s pi ctur e.
WWIC (Coimbra, Portugal)
8
Migration of applications
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
QuickTi me™ and a
TIFF ( Uncompressed) decompressor
are needed to see thi s pi ctur e.
Qui ckTime™ and a
TIFF (U ncompr essed) decompressor
are needed to see thi s pi cture.
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
QuickTi me™ and a
T IFF (Uncom pressed) decom pressor
are needed to see t his pict ure.
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
May 2007
text, still
images
audio
video
synchronous
IM
VoIP
video
conferencing
asynchronous
email
email,
voicemail
YouTube
WWIC (Coimbra, Portugal)
9
Building Internet applications
80% care
about this
level
extensible CMS,
Wiki
(Drupal, Mambo, Joomla, ...)
Ruby on Rails, Spring, ...
Ajax, SOAP
PHP, Java w/libraries
Java RMI, HTTP
C/C++ with sockets
taught in
Networking
101
custom protocols on UDP, TCP
May 2007
WWIC (Coimbra, Portugal)
10
User issues (guesses)
•
•
•
•
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
May 2007
WWIC (Coimbra, Portugal)
11
Left to do: glue protocols
• Lots of devices and services
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
– cars
– household
– environment
• Generally, stand-alone
– e.g., GPS can’t talk to camera
• Home
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
– home control networks have generally
failed
• cost, complexity
• Environment
– “Internet of things”
– tag bus stops, buildings, cars, ...
May 2007
WWIC (Coimbra, Portugal)
12
Left to do: event notification
• 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
May 2007
WWIC (Coimbra, Portugal)
13
GEOPRIV and SIMPLE architectures
rule
maker
DHCP
XCAP
(rules)
target
presentity
caller
May 2007
publication
interface
PUBLISH
INVITE
location
server
presence
agent
notification
interface
location
recipient
GEOPRIV
watcher
SIP
presence
SUBSCRIBE
NOTIFY
INVITE
WWIC (Coimbra, Portugal)
callee
SIP
call
14
Configuration complexity
• 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)
May 2007
WWIC (Coimbra, Portugal)
15
Open issues: Configuration
•
•
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
• SMTP, IMAP, POP, ...
• security variations
– policy information (“sorry,
no video”)
– user data (address book)
May 2007
• 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
WWIC (Coimbra, Portugal)
16
Mobile systems - reality
GPS
•
idea: special purpose (phone) --> universal
communicator
–
•
idea is easy...
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
mobile equipment: laptop + phone
–
•
•
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
sufficiently different UI and capabilities
location data
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
•
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
e.g., phone book access
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
QuickTime™ and a
TIFF (Uncompress ed) dec ompres sor
are needed to s ee this pic ture.
May 2007
WWIC (Coimbra, Portugal)
17
Outline
•
•
•
•
•
Applications and upper layers
Internet protocol infrastructure
Network management
Network standards
Network research
May 2007
WWIC (Coimbra, Portugal)
18
What has made the Internet successful?
•
36 years  approaching mid-life crisis  time for selfreflection
–  next generation suddenly no longer finds it hip
•
Transparency in the core
– new applications (web, VoIP, games)
•
Narrow interfaces
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
– 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
May 2007
WWIC (Coimbra, Portugal)
19
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?
May 2007
WWIC (Coimbra, Portugal)
20
In more detail…
• 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
May 2007
WWIC (Coimbra, Portugal)
21
Internet design principles
Original DARPA Internet Design principle
The Internet must support multiplexed utilization of existing
interconnected networks.
Internet communications must continue despite loss of networks
or gateways.
The Internet architecture must accommodate a variety of
networks.
did not anticipate
cyber attack,
exfiltration,
malicious control
cooperative
protocols --> insider
threat
The Internet must permit distributed management of its resources.
The Internet architecture must be cost effective.
The Internet architecture must permit host attachment with low
level of effort.
The resources used in the Internet architecture must be
accountable.
“permit-by-default”
instead of “deny-bydefault”
malicious use of
resources remains
anonymous &
untraceable
J Christopher Ramming, IAMANET briefing, April 2006, based on D. Clark, SIGCOMM 1998
May 2007
WWIC (Coimbra, Portugal)
22
Core goals for new networks
•
•
•
•
•
reliability
diagnosability
sustainability
adaptability
survivability
May 2007
WWIC (Coimbra, Portugal)
23
Survivability
• Real world: locks keep out the
honest
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
– until the police arrives
• Internet: assumption of lawlessness
– no global law enforcement
– carriers have little interest in policing
their users
• bots, spam
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
– must survive extended periods of
attacks
• From permit-by-default to deny-bydefault
May 2007
WWIC (Coimbra, Portugal)
24
Reliability
• 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?
May 2007
WWIC (Coimbra, Portugal)
25
The transformation of protocol stacks
Internet
ca. 1995
Internet
ca. 2005
application
presentation
session
application
application
SOAP
HTTP
transport
TCP
TCP
network
IP
IP-in-IP
IP
H. Zimmermann
ca. 1980
May 2007
link
802.3
physical
physical
WWIC (Coimbra, Portugal)
MPLS, PoE
PoS, ATM
physical
26
Cause of death for the next big thing
QoS
multicast
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

mobile
IP

active
networks
IPsec
IPv6
















(NAT)
increase system vulnerability
May 2007


WWIC (Coimbra, Portugal)


27
Simple wins (mostly)
•
•
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, …
May 2007
WWIC (Coimbra, Portugal)
28
Measuring complexity
•
•
•
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
May 2007
WWIC (Coimbra, Portugal)
29
Possible complexity metrics
•
new code needed (vs. reuse)  less likely to be buggy or have buffer
overflows
–
–
–
–
•
•
new identities and identifiers needed
number of configurable options + parameters
–
–
–
–
–
•
e.g., new text format almost the same
numerous binary formats
security components
necessary transition: bespoke  off-the-rack protocols
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
May 2007
WWIC (Coimbra, Portugal)
30
Democratization of protocol engineering
•
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)
May 2007
WWIC (Coimbra, Portugal)
31
The transformation of protocol design
•
•
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
(ftp)
May 2007
ASN.1based
(SNMP,
X.400)
RFC 822 protocol
(SMTP, HTTP, RTSP,
SIP, …)
use XML for
protocol bodies
(IETF IM &
presence)
WWIC (Coimbra, Portugal)
SOAP and
other XML
protocols
32
Why are web services succeeding(*) after
RPC failed?
•
•
•
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
May 2007
WWIC (Coimbra, Portugal)
(*) we hope
33
Time for a new protocol stack?
•
•
•
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)
May 2007
WWIC (Coimbra, Portugal)
34
NSF “Green Field” approach
•
•
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
May 2007
WWIC (Coimbra, Portugal)
35
NSF: FIND and GENI, cont’d
•
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”
May 2007
WWIC (Coimbra, Portugal)
36
(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
May 2007
•
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
WWIC (Coimbra, Portugal)
37
More “network” services
•
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
–
–
–
–
May 2007
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)
38
Security
• More than just encryption!
• Need identity and role-based certificates
• May want reverse-path reachability (bank  customer)
asking
user
user
do I know this person? is he a am I connected to a
likely sender of spam?
“real” network or an
impostor?
is this really a bank?
network
is this a customer?
May 2007
network
WWIC (Coimbra, Portugal)
is this BGP route
advertisement
legitimate?
39
NGN or what’s wrong with 3G
• 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
May 2007
WWIC (Coimbra, Portugal)
40
What’s (my) 4G?
• 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
May 2007
WWIC (Coimbra, Portugal)
41
Internet (re)engineering: summing up
•
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
May 2007
WWIC (Coimbra, Portugal)
42
Outline
•
•
•
•
•
User perspective
Internet protocol infrastructure
Network management
Network standards
Networking research
May 2007
WWIC (Coimbra, Portugal)
43
Network Management  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 SNMPenabled, but no suggestion that this would help at all
May 2007
WWIC (Coimbra, Portugal)
44
Circle of blame
probably packet
loss in your
Internet connection 
reboot your DSL modem
ISP
VSP
OS
must be a
Windows registry
problem  re-install
Windows
May 2007
probably a gateway fault
 choose us as provider
app
vendor
WWIC (Coimbra, Portugal)
must be
your software
 upgrade
45
Diagnostic undecidability
• 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?
May 2007
WWIC (Coimbra, Portugal)
46
VoIP user experience
•
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
May 2007
WWIC (Coimbra, Portugal)
47
Traditional network management model
X
SNMP
“management from the center”
May 2007
WWIC (Coimbra, Portugal)
48
Old assumptions, now wrong
•
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
May 2007
WWIC (Coimbra, Portugal)
49
Management
what causes the
most trouble?
network understanding
fault location
configuration
we’ve only
succeeded
here
element inspection
May 2007
WWIC (Coimbra, Portugal)
50
Managing the protocol stack
media
RTP
UDP/TCP
IP
May 2007
echo
gain problems
VAD action
protocol problem
playout errors
protocol problem
authorization
asymmetric conn
(NAT)
SIP
TCP neg. failure
NAT time-out
firewall policy
no route
packet loss
WWIC (Coimbra, Portugal)
51
Types of failures
• 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)
May 2007
WWIC (Coimbra, Portugal)
52
Examples of additional problems
• 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”
May 2007
WWIC (Coimbra, Portugal)
53
Proposal: “Do You See What I See?”
• 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
May 2007
WWIC (Coimbra, Portugal)
54
Architecture
“not working”
(notification)
inspect protocol requests
orchestrate tests
contact others
request diagnostics
(DNS, HTTP, RTCP, …)
ping 127.0.0.1
can buddy reach our
resolver?
“DNS failure for 15m”
notify admin
(email, IM, SIP events, …)
May 2007
WWIC (Coimbra, Portugal)
55
Failure detection tools
• 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
media
RTP
UDP/TCP
– initially, we’ll be using ‘make’
• TBD: remote diagnostic
– fixed set (“do DNS lookup”) or
– applets (only remote access)
May 2007
WWIC (Coimbra, Portugal)
IP
56
Failure statistics
• 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
May 2007
WWIC (Coimbra, Portugal)
57
Outline
•
•
•
•
•
User perspective
Internet protocol architecture
Network management
Network standards
Networking research
May 2007
WWIC (Coimbra, Portugal)
58
The role of standards
• Most users won’t see network improvements until
standard emerges
– gatekeeper
• Exceptions
– De-facto standards (Microsoft)
– TCP enhancements -- via OS
– Some new tools (Skype)
May 2007
WWIC (Coimbra, Portugal)
59
Standards Work
•
•
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
May 2007
WWIC (Coimbra, Portugal)
60
SIP, SIPPING & SIMPLE –00 drafts
80
70
60
50
SIP
SIPPING
SIMPLE
40
30
20
10
0
1999 2000 2001 2002 2003 2004 2005 2006
includes draft-ietf-*-00 and draft-personal-*-00
May 2007
WWIC (Coimbra, Portugal)
61
RFC publication
14
12
10
8
SIP
SIPPING
SIMPLE
6
4
2
0
May 2007
2001
2002
2003
2004
2005
WWIC (Coimbra, Portugal)
2006
62
Trouble in Standards Land
•
Proliferation of transition standards: 2.5G,
2.6G, 3.5G, …
– true even for emergency calling…
•
Splintering of standardization efforts
across SDOs
OASIS
W3C
ISO (MPEG)
– primary:
• IEEE, IETF, W3C, OASIS, ISO
data
exchange
IETF
L2.5-L7
protocols
IEEE
L1-L2
– architectural:
• PacketCable, ETSI, 3GPP, 3GPP2, OMA,
UMA, ATIS, …
data
formats
– specialized:
• NENA
3GPP
• SIP Forum, IPCC, …
May 2007
WWIC (Coimbra, Portugal)
PacketCable
– operational, marketing:
63
IETF issues
•
SIP WGs: small number (dozen?)
of core authors (80/20)
– some now becoming managers…
– or moving to other topics
•
IETF: research  engineering 
maintenance
•
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)
– many groups are essentially
maintaining standards written a
decade (or two) ago
• DNS, IPv4, IPv6, BGP, DHCP;
RTP, SIP, RTSP
• constrained by design choices
made long ago
– often dealing with transition to
hostile & “random” network
– network ossification
May 2007
– some efforts such as SAML and
SASL
•
tendency to re-invent the wheel in
each group
WWIC (Coimbra, Portugal)
64
IETF issue: timeliness
•
Most drafts spend lots of time in 90%complete state
–
–
lack of energy (moved on to new -00)
optimizers vs. satisfiers
•
•
–
–
•
multiple choices that have noncommensurate trade-offs
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
–
May 2007
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
Notorious examples:
–
•
•
•
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
WWIC (Coimbra, Portugal)
65
Outline
•
•
•
•
•
User perspective
Internet protocol infrastructure
Network management
Network standards
Networking research
May 2007
WWIC (Coimbra, Portugal)
67
Lifecycle of technologies
COTS
(e.g., GPS)
traditional technology propagation:
IM, digital photo
military
opex/capex
doesn’t
matter;
expert
support
Can it be done?
May 2007
corporate
capex/opex
sensitive,
but
amortized;
expert
support
Can I afford it?
WWIC (Coimbra, Portugal)
consumer
capex
sensitive;
amateur
Can my mother use it?
68
Science vs. Engineering
•
•
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
–
–
–
–
–
•
Engineering
–
–
–
–
•
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?
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
May 2007
WWIC (Coimbra, Portugal)
69
Traditional research
• 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
May 2007
WWIC (Coimbra, Portugal)
70
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
May 2007
WWIC (Coimbra, Portugal)
71
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
May 2007
WWIC (Coimbra, Portugal)
72
Translation into Practice
• 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
–
–
–
–
May 2007
repeated, continuous refinement
public beta
no separate “research”
still has problems with polish & completion
WWIC (Coimbra, Portugal)
73
Impact of networking research
• Very low publication-to-impact ratio
• Brilliant idea, magically transformed into reality
– by somebody else
• Research as point scoring
–
–
–
–
May 2007
publication count
citation by other papers, also without impact
read mostly by other researchers
goal: graduate/get tenure
WWIC (Coimbra, Portugal)
74
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:
QoS
– deployment costs of any new L3 technology is
probably billions of $
– coordination costs
quality-ofservice
IEEE
10,377
12,876
ACM
3,487
4,388
• 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
May 2007
WWIC (Coimbra, Portugal)
75
Aside: The Hockeystick Problem
utility
1.0
complexity
security risks
bandwidth
May 2007
WWIC (Coimbra, Portugal)
adoption
76
Conclusion
• 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]”
May 2007
WWIC (Coimbra, Portugal)
77