Surmounting obstacles by arm maneuver for unmanned power ...
THE POWER OF ABSTRACTION, A OR,€¦ · THE POWER OF ABSTRACTION: OUTLINE ONE WAY TO IMPROVE...
Transcript of THE POWER OF ABSTRACTION, A OR,€¦ · THE POWER OF ABSTRACTION: OUTLINE ONE WAY TO IMPROVE...
AAA
A
A
A
© 2013 AT&T Intellectual Property. All rights reserved. AT&T and the AT&T logo are trademarks of AT&T Intellectual Property.
THE POWER OF ABSTRACTION,
OR,
A CASE FOR DOMAIN MODELING
Pamela Zave
AT&T Laboratories—Research
Bedminster, New Jersey USA
AAA
A
A
A
RESEARCHERS IN COMPUTER SCIENCE . . .
. . . ALL HAVE THE SAME PROBLEM
GOVERNMENT
LABORATORIES
UNIVERSITIES INDUSTRY
LABORATORIES
How can we persuade those who build large software systems
to use what we produce?
Most of us are asking people to change their own process,
not just handing them a product.
probably not theright role for research
AAA
A
A
A
THE POWER OF ABSTRACTION: OUTLINE
ONE WAY TO IMPROVE RESEARCH
AND FACILITATE ITS USE
OVERCOMING THE OBSTACLES TO DOMAIN
MODELING AS UNIVERSITY RESEARCH
1
2
A CASE FORDOMAIN
MODELING
I won’t be telling you anythingyou don’t already know, . . .
. . . but maybe I can reinforce a healthy trendand give you a few new examples.
AAA
A
A
A
THE INTERFACES TOCOMPUTER SCIENCE
programming languages
specification languages
schema andquery languages
rule-based languages
machine learning
operating systems
networks
LARGE SOFTWARE SYSTEMSIN THE REAL WORLD
financial services
healthcare services
aerospace systems
air traffic control
automotive systems
factory automation
retail sales
environmental monitoring
energy grids
communication networks
. . . and every other aspectof modern life
THERE IS A
VERY LARGE GAP
BETWEEN THEM,
FILLED BY:
application code
BUT THIS IS
NOT ENOUGH!
WE NEED . . .
requirements
specifications
architectures
. . . WHICH ARE
DOMAIN MODELS
AAA
A
A
A
CONTENTS OF A FULL DOMAIN MODEL
SPECIFICATION:description ofthe behavior of
the system
DOMAIN KNOWLEDGE:description ofthe system’senvironment
REQUIREMENTS:description of howthe environment
should work whenthe system is installed
ARCHITECTURE:functions, modules,
platforms, frameworks,performance
constraints, etc.
all are based on coordinatedabstractions and terminology
all are re-usable artifacts,intended for a family of systems
all are structured andorganized to serve several purposes
some parts are formalized,but they need not be
complete or completely formalized
ENVIRONMENT SYSTEM
AAA
A
A
A
A SLEEKER DOMAIN MODEL
DOMAIN-SPECIFICSPECIFICATION
LANGUAGE
DOMAIN KNOWLEDGE:description ofthe system’senvironment
REQUIREMENTS:description of howthe environment
should work whenthe system is installed
COMPILER ORINTERPRETER
FOR SPECIFICATIONSplus runtime
platform
ENVIRONMENT SYSTEM
programs in domain-specific languagecan be analyzed for inconsistencies,
can be verified to havedesirable properties
although the domain knowledgeand requirements may be implicit,
without them there are nooperating assumptions,
properties to verify,or even tests!
AAA
A
A
A
GREATEST SUCCESS STORY:THE SEMICONDUCTOR INDUSTRY
Verilog and VHDL(circa 1984) become
the standarddomain-specific
specificationlanguages
design automation(logic synthesis
and verification) is afundamental technology forthe semiconductor industry
continual researchon the important
problems improvesdesign automation
continual improvements
in semiconductorfabrication
demand morecomplex domain
models
fabricators do not needto worry about gettinglocked into one tool
an easy start: initial domainmodel only needs to describethe processor and memoryarchitectures of the early1980s
by now the domain andits models are vastlymore complex, . . .
. . . because the modelsand domain havegrown up together
AAA
A
A
A
WHY INDUSTRY HAS TROUBLE DEVELOPINGDOMAIN MODELS
DOMAIN MODELING IS A “HARD SELL”TO MANAGEMENT
takes time and repetition to get it right
domain modeling is an investmentthat does not pay off quickly
INDUSTRY DOES NOT HAVE THERIGHT KIND OF PEOPLE
practitioners are good at solving whateverproblem is put in front of them, while domainmodeling questions what the problem is
practitioners are good at masteringcomplexity, while domain modeling requiresabstraction (extracting simplicity)
practitioners are good at optimizing, whiledomain modeling requires separating concerns
INDUSTRY DOES NOT HAVEPEOPLE WITH THE RIGHTTRAINING
requires formal methods
the conclusion isthat if industry cannot
do domain modeling, . . .
. . . then researchersmust do it!
AAA
A
A
A
WHY RESEARCHERS SHOULD BE HAPPY TO DEVELOPDOMAIN MODELS
because this is how to find the bestresearch problems
because domain models are the keyto making agile development methods work well
because domain models solve the“plumbing problem”—computerscience contributes something valuable and tangible to the domain
“plumbing problem”: when computerscientists collaborate with researchersin other domains, they are perceivedas providing no more than theplumbing that allows data to flow
(BESIDES THE OBVIOUS INTELLECTUAL CHALLENGES)
INTERNET ARCHITECTURE AND SOFTWARE-DEFINED NETWORKING (SDN)
SDN IS BEST KNOWN FROM THEOpenFlow STANDARD
controller
router router
WHY SDN IS POPULAR
industry sees it as the key tovirtualization of routers—andbig savings because routersare so expensive
researchers see it as a place toapply knowledge of programminglanguages and formal methodsas well as networking
routers forward packets(”the data plane”)
a controller for a subnetworkmaintains a centralizedabstraction of the network andwrites to the forwarding tablesin the routers (”the control plane”)
OpenFlowstandardizesthe interface
THE “CLASSIC” INTERNET ARCHITECTURE
APPLICATION LAYER
TRANSPORT LAYER
NETWORK LAYER
LINK LAYER
PHYSICAL LAYER
this architecture hassucceeded (beyondmost peoples’ wildestdreams) in fosteringinnovation and shaping the world welive in
however, it is nowwidely agreed thatit does not meetsociety’s present andfuture requirements
security
dependability
mobility
scalability
quality of service
resource management
the trend is towarda more pluralisticarchitecture . . .
. . . with multiple,customized protocolstacks
WHAT IS REALLY GOING ON
headers in a typical AT&T packet, one header per layer: 12 instead of 4
Application
HTTP
TCP
IP
IPsec
IP
GTP
UDP
IP
MPLS
MPLS
Ethernet
multiple layers ofresource management
cellular service(mobility, QoS, billing)
security
HTTP being used as a transportprotocol because it is theonly way to traverse NAT boxesand firewalls
© 2013 AT&T Intellectual Property. All rights reserved. AT&T and the AT&T logo are trademarks of AT&T Intellectual Property.
THE GEOMORPHIC VIEWOF NETWORKING
CLASSIC LAYERS OROSI REFERENCE MODEL
there is a fixed number of levels there can be any number of levels
each layer/level has a specialized function
each layer is a microcosm of networking, containing all the basicfunctions (state components andmechanisms)
the scope of each layer is global,so layer = level
some layers have small or localscopes
WE CALL THIS THE “GEOMORPHIC VIEW”OF NETWORKING . . .
. . . BECAUSE THE COMPLEX ARRANGEMENT
OF LAYERS RESEMBLES THE EARTH’S CRUST
TODAY’S INTERNET, CLASSIC AND GEOMORPHIC VIEWS
Even if the implementation looks like this,the geomorphic view is a better abstractionfor structuring the software and analyzing itsproperties.
CLASSIC VIEW:
Stuff all the new complexity intothe network layer, which is theonly place for it.
SO FAR, this is the approach thatSDN research is taking.
GEOMORPHIC VIEW:
accurately describes the structure oftoday’s Internet
relatively simple layers modularizethe complexity
THOUGHTS ON SDN
WHAT I OBSERVE
repertoire of “properties to prove”is a bit boring
many conflicting requirements(from different stakeholders), withlittle help in resolving the conflicts
serious complexity problems in allaspects: modeling networks,expressing desired properties,deciding properties
“tunneling makes the state explode”
WHAT NICK McKEOWN SAID
One of the three major benefits of SDNis a well-defined control abstractionthat can be implemented separatelyfrom the forwarding plane . . .
. . . so that software engineering can beapplied to this implementation.
WHAT IS SOFTWARE ENGINEERING?
Above all, software engineering isabout . . .
. . . modularity
. . . separation of concerns,
which is what you get from layers inthe geomorphic view.
It can help you . . .
. . . develop re-usable theories that apply at many levels for many different purposes
. . . understand where the requirements come from and how conflicts should be resolved
. . . manage complexity
. . . extend SDN beyond the most basic aspects of networking.
AAA
A
A
A
THE POWER OF ABSTRACTION: OUTLINE
ONE WAY TO IMPROVE RESEARCH
AND FACILITATE ITS USE
OVERCOMING THE OBSTACLES TO DOMAIN
MODELING AS UNIVERSITY RESEARCH
1
2
A CASE FORDOMAIN
MODELING
I won’t be telling you anythingyou don’t already know, . . .
. . . but maybe I can reinforce a healthy trendand give you a few new examples.
OBSTACLES TO DOMAIN MODELING ASRESEARCH IN UNIVERSITIES
LEARNING ABOUT THE DOMAIN
no access to domain experts, or . . .
. . . domain experts do not havetime for you
need long-term stable funding tocommit to learning a domain
PUBLICATION
work in cooperation with industrymay not be released for publication
domain-specific results are inter-disciplinary—there is no place topublish them
a descriptive model is not a newresult
comparing models of a domain isnot science, it is religion
the pressure to publish in quantityis too great to take any risks
what matters is citation by fellowresearchers, not real-world impact
IT’S A BIG, OPEN WORLD OUT THERE
no access to domain experts
domain experts do not havetime for you
need long-term stable funding tocommit to learning a domain
work in cooperation withindustry may not be released forpublication
CHALLENGING THESE OBSTACLES: IMPORTANT DOMAINS HAVE MANYPLAYERS
established companies
start-ups
standards bodies
government regulators
INFORMATION IS WIDELY AVAILABLE
open-source software
standards documents
(almost) everything is on the Web!
collaboration between universitydepartments
people working in and with industrydo get their papers released
a new technology is arousing commercial interest,
but the customers (e.g., Internet service providers)are holding back
CUSTOMERS WANT:
to be sure the technology will succeed before adopting it
to avoid interoperability problems
to avoid being the captive of one vendor
VENDORS WANT:
to bring their products to marketfirst
to differentiate their productsfrom those of other vendors
to capture customers so that theycannot change vendors
obviously standards benefitthe customers morethan the vendors . . .
. . . and vendors accept thembecause the customers
demand them
TALES FROM THE INTERNET ENGINEERING TASK FORCE
VENDORS WANT:
to make the processas fast as possible,by finishing a fewbasic use cases first
to standardize as little as possible
WHICH HAS THESEUNFORTUNATESIDE-EFFECTS:
with no early thoughtabout generality,each new incrementof capability requiresa similar or greaterincrement of complexity
the standard has manyrecommendations andoptional extensions
a protocol with N optionalextensions has, in effect,2 versionsN
THE ABSENCE OFFORMAL METHODSMAKES THESEPROBLEMS MUCH WORSE
once the standardsprocess has begun, thevendors try to control it
"A Hitchhiker's Guide to SIP" is asnapshot of SIP RFCs and drafts asof 2009 . . .
. . . which lists 142 documents, totaling many thousands of pages
THE MEDIUM
the base document (IETF RFC 3261)is 268 pages
specifications are written inEnglish, augmented only bymessage sequence charts thatusually look like this (IETF macros):
process1 process2
IETF philosopy is to standardize based on "rough consensus andworking code"
finite-state machines are rarelyused
note how this forces youto forget race conditions!
THE MESSAGE
it is continually being extended,bottom-up, in response to an endless series of new use cases
THE SIP STANDARD dominant protocol for IP-based voice, multimedia
it sometimes takes hours to getan answer to a simple questionabout SIP (and even then youare not sure)
test cases are insufficient toinsure interoperation ofproducts (which is the mainpurpose of a standard)
many people don’t want to useSIP because it is too complex,are looking for simpleralternatives
the overall inefficiency andand waste are staggering
FOR COMPUTER SCIENCE,THIS IS LOW-HANGINGFRUIT
working with SIP, straightforwardmodeling and model-checking . . .
. . . provided unambiguous, searchable documentation
. . . revealed many inconsistencies and unknown race conditions
. . . suggested simplifications
. . . automatically generated thousands of test cases
at the same time, the diverse aspectsand scale of real standards meansthat there are many interestingresearch questions to work on
THE EFFECTS ARE PREDICTABLE
HOW TO INFILTRATE THE STANDARDS PROCESS
provide up-to-date, searchable,unambiguous documentation
generate test cases automatically
go to work for a vendor andconvince your colleagues thatformal methods are a secretweapon
go to work for a customer andconvince your colleagues thatformal methods are a protectiveshield
1
2
34
5
7
6
get involved with new standards,where the mess is not yet hopeless
tell your granting agency that youwant to improve commercialstandards
achieve credibility (withoutattending endless meetings) withthe results of automated analysis
AN INDUSTRY PERSPECTIVE ON PUBLICATION
CHALLENGING THESE OBSTACLES:
domain-specific results are inter-disciplinary—there is no place topublish them
a descriptive model is not a newresult
comparing models of a domain isnot science, it is religion
the pressure to publish inquantity is too great to makelong-term investments or takeany risks
what matters is citation byfellow researchers, notreal-world impact
THESE ATTITUDES SEEM SOMEWHATOUT-OF-BALANCE
the world of computing already hasfar too many mechanisms, toolittle ability to compose them intosomething of lasting value
most published models are toys,which is why there are fewinteresting differences betweenthem—there are many importantdifferences between industriallyuseful models
if the system discourages workon the most important problems,then maybe the system should bechanged