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