Thoughts on a next-generation Internet and next-generation network management

1
Thoughts on a next-generation Internet and
next-generation network management

• Henning Schulzrinne
• Dept. of Computer Science
• Columbia University
• April 2006

2
Overview

• The transformation in keynote big pictures
• The transition in cost metrics
• What has made the Internet successful?
• Some Internet problems
• Simplicity wins
• Architectural complexity
• New protocol engineering
• End-to-end application-visible reliability still
  poor ( 99.5)
• even though network elements have gotten much
  more reliable
• particular impact on interactive applications
  (e.g., VoIP)
• transient problems
• Lots of voodoo network management
• Existing network management doesnt work for VoIP
  and other modern applications
• Need user-centric rather than operator-centric
  management
• Proposal peer-to-peer management
• Do You See What I See?
• Also use for reliability estimation and
  statistical fault characterization

3
Philosophy transition
PC era cell phone era
One computer/phone, many users
One computer/phone, one user
mainframe era home phone party line
Many computers/phones, one user
ubiquitous computing
anywhere, any time any media
right place (device), right time, right media
4
Evolution of VoIP
how can I make it stop ringing?
does it do call transfer?
long-distance calling, ca. 1930
going beyond the black phone
amazing the phone rings
catching up with the digital PBX
1996-2000
2000-2003
2004-
5
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
• 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

Ethernet web server
6
IP hourglass
email WWW phone... SMTP HTTP RTP... TCP
UDP IP ethernet PPP CSMA async
sonet... copper fiber radio...
Steve Deering, IETF Aug. 2001
7
User issues (guesses)

• Lack of trust
• small mistakes ? identity gone
• waste time on spam, viruses, worms, spyware,
• Lack of reliability
• 99.5 instead of 99.999
• even IETF meeting cant 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

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

9
In more detail

• Deployment problems
• 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

10
The transformation of protocol stacks
11
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 ? ? ? ?
12
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,

13
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 dont do APIs ? we dont worry about whether
  a simple API can be written that can be taught in
  Networking 101

14
Possible complexity metrics

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

15
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"
  formatflowed
• 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)

16
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)
RFC 822 protocol (SMTP, HTTP, RTSP, SIP, )
use XML for protocol bodies (IETF IM presence)
SOAP and other XML protocols
ASN.1-based (SNMP, X.400)
17
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 didnt 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

Corba
DCOM
SunRPC
() we hope
18
Time for a new protocol stack?

• Now add x.5 sublayers and overlay
• HIP, MPLS, TLS,
• Doesnt 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)

19
(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

20
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
• SLP/Jini/UDDI service location ? ontology-based
  data store
• network file storage ? for temporarily-disconnecte
  d mobiles
• network computation ? translation, relaying
• trust services (? IRT trust paths work)

21
Security

• More than just encryption!
• Need identity and role-based certificates
• May want reverse-path reachability (bank ?
  customer)

asking user network
user do I know this person? is he a likely sender of spam? is this really a bank? am I connected to a real network or an impostor?
network is this a customer? is this BGP route advertisement legitimate?
22
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

23
Network Management ? Transition in cost balance

• Total cost of ownership
• Ethernet port cost ? 10
• about 80 of Columbia CSs 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

24
Circle of blame
ISP
probably packet loss in your Internet connection
? reboot your DSL modem
probably a gateway fault ? choose us as provider
OS
VSP
must be a Windows registry problem ?
re-install Windows
app vendor
must be your software ? upgrade
25
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?

26
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

27
Traditional network management model
X
SNMP
management from the center
28
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 dont need management
• DMI SNMP never succeeded
• each application does its own updates

29
Management
what causes the most trouble?
network understanding
fault location
weve only succeeded here
configuration
element inspection
30
Managing the protocol stack
protocol problem authorization asymmetric conn
(NAT)
media
echo gain problems VAD action
RTP
SIP
protocol problem playout errors
UDP/TCP
TCP neg. failure NAT time-out firewall policy
IP
no route packet loss
31
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)

32
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 dont allow port 25 vs. SMTP server
  temporarily unreachable

33
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

34
Architecture
not working (notification)
request diagnostics
orchestrate tests contact others
inspect protocol requests (DNS, HTTP, RTCP, )
ping 127.0.0.1 can buddy reach our resolver?
DNS failure for 15m
notify admin (email, IM, SIP events, )
35
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
• initially, well be using make
• TBD remote diagnostic
• fixed set (do DNS lookup) or
• applets (only remote access)

media
RTP
UDP/TCP
IP
36
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

37
Conclusion

• Hypothesis network reliability as single largest
  open technical issue ? prevents (some) new
  applications
• Existing management tools of limited use to most
  enterprises and end users
• Transition to self-service networks
• support non-technical users, not just NOCs
  running HP OpenView or Tivoli
• Need better view of network reliability