Evolution of end-to-end: why the Internet is not
like any other network

Leslie Daigle, moderator.
Chief Internet Technology Officer
The Internet Society

http://www.internetsociety.org
We are…
Not at the IETF
!  Taking discussion up a level
!  Taking any identified work items to the appropriate IETF WGs

On the air
!  Streaming
!  Recording

Stopping at 12:45pm so you can all get back to the
IETF…

2

The Internet Society
Agenda outline
Overview of the panel
Panelists’ predictions
Panel discussion
Open mic

3

The Internet Society
Panel overview

http://www.internetsociety.org
From the IAB’s RFC3724 (2004)
One of the key architectural guidelines of the Internet
is the end-to-end principle in the papers by Saltzer,
Reed, and Clark [...]. The end-to-end principle was
originally articulated as a question of where best not to
put functions in a communication system.
Yet, in the ensuing years, it has evolved to address
concerns of maintaining openness, increasing reliability
and robustness, and preserving the properties of user
choice and ease of new service development as
discussed by Blumenthal and Clark in [...]; concerns that
were not part of the original articulation of the end-toend principle.”

The Internet Society
Current realities
We still want to build an Internet that features:
!  “increasing reliability and robustness, and preserving the

properties of user choice and ease of new service development “

Significant challenges to that include
!  Business evolution
!  Reactions to the revelations of pervasive monitoring

–  “Encrypt everything everywhere always”
–  Localization of data based on physical geography

6

The Internet Society
At the heart of the matter

[How] Does the end-to-end
principle matter in today’s
Internet and going forward?

7

The Internet Society
The Panel
Leslie Daigle (Moderator)
Fred Baker – network
Andrew Sullivan – infrastructure
Harald Alvestrand – endpoint

8

The Internet Society
Panelists predictions

http://www.internetsociety.org
Fred Baker
Network

10
http://www.internetsociety.org
End$to$End$principle$
•  Mul$ple'statements'in'the'same'paper:'
•  “The$principle,$called$the$end2to2end$argument,$suggests$that$
func8ons$placed$at$low$levels$of$a$system$may$be$redundant$or$of$
li=le$value$when$compared$with$the$cost$of$providing$them$at$
that$low$level.”$
–  General'statement'of'the'end5to5end'argument'or'principle'

•  “The$func8on$in$ques8on$can$completely$and$correctly$be$
implemented$only$with$the$knowledge$and$help$of$the$applica8on$
standing$at$the$end$points$of$the$communica8on$system.$
Therefore,$providing$that$ques8oned$func8on$as$a$feature$of$the$
communica8on$system$itself$is$not$possible.”$
–  This'formula$on'applies'in'cases'in'which'end'system'applica$on'
knowledge'and'help'is'required'to'implement'func$onality'
The$Stupid$Smart$Predictable$Network$
•  My'understanding'of'the'End'to'End'principle:'
–  One'could'describe'it'as'a'“principle'of'least'surprise”'or'a'
“plea'for'simplicity”.'
–  A"lower"layer"should"do"what"an"upper"layer"expects.""
•  Operate'correctly'per'the'protocol'
•  Recursive!'
•  Second5guessing'layers'above,'and'introducing'state,'creates'
unintended'consequences'for'operators'and'users.'

–  Lower'layer'performance'enhancements,'implemented'by'
including'equivalent'func$onality'in'two'layers,'are'explicitly'
allowed;''
•  They%should%measurably%enhance%performance…%
Examples$of$things$the$predictable$
network$does:$
•  When$handed$a$packet$des8ned$to$a$unicast$or$anycast$address,$it$
delivers$the$packet$to$the$address$unchanged$
–  It,'however,'intelligently'determines'the'route,'something'the'
applica$on'does'not'do'
–  If'it'has'mul$ple'reasonable'routes,'it'uses'them'effec$vely'without'
applica$on'interven$on'

•  It$may$route$traffic$in$a$manner$that$enhances$the$opera8on$and$
profit$of$its$administrator$
–  Example:'BGP'rou$ng'may'op$mize'the'cost'to'an'administra$on'
–  Example:'a'load'balancer'may'balance'load'among'many'hosts'

•  It$operates$transparently$
–  When'a'predictable'network'does'something'unusual'with'a'session'or'
packet,'it'tells'the'sender'
Examples$of$things$the$predictable$network$
does$not$do$
•  Behave$contrary$to$predic8on,'and'in'so'doing'cause'a'user'
or'operator'to'have'to'diagnose'its'behavior'
–  When'asked,'in'DNS,'for'the'address'of'party'A,'return'the'address'of'
party'B.'
–  When'given'a'packet'intended'for'delivery'to'party'A,'deliver'it'to'
another'party'
–  When'given'a'packet'containing'a'quantum'of'data,'deliver'a'packet'
containing'an'unintended'quantum'of'data'

•  Note$that$intermi=ent$behavior$is$contrary$to$predic8on$
–  While'it'may'change'its'behavior'(such'as'a'route),'it'doesn’t'oscillate'
The$network$in$2020$
•  Simplicity$Principle$
–  “Complexity'is'the'primary'mechanism'which'impedes'efficient'
scaling,'and'as'a'result'is'the'primary'driver'of'increases'in'both'capital'
expenditures'(CAPEX)'and'opera$onal'expenditures'(OPEX).”''
–  RFC'3439,'quo$ng'Mike'O’Dell'
–  Complexity'is'also'an'enemy'to'security'–'more'things'to'analyze'

•  I$see$some$operators$moving$in$the$direc8on$of$drama8cally$
simplifying$their$networks$
–  Their'arguments'have'to'do'with'reducing'opera$onal'expense'
–  IPv4'networks'tend'to'be'more'complex'and'less'predictable''than'
IPv6,'due'to'NAT'
–  Drama$c'simplifica$on'leads'to'drama$cally'improved'predictability'

•  I$do$not$see$operators,$or$their$vendors,$making$the$network$less$
able$to$deliver$value$either$to$its$users$or$its$administra8ons$
Andrew Sullivan
Infrastructure

http://www.internetsociety.org
Isn’t this just the network?
Distinguish bits flowing on the wire + basic
routing with everything else
!  Infrastructure specialization is unlikely to go
away
! 

! 
! 
! 

Capital expenditure & economies of scale
“Core business” concerns
Cattle not pets
1
A great compromise
“You got it buddy: the large print giveth, and
the small print taketh away” (Tom Waits,
“Step Right Up”)
Infrastructure providers rely on something like
Fred’s “predictable network”
!  Infrastructure providers have to alter their
behaviour depending on the user
! 

! 

They’re all doing this at once
2
Know your customer in
2020
! 

Technologies that give hints will be embraced
! 
! 
! 

! 

Identify certain properties of network user
Correlate user across different services
Not very end-to-endy

Technologies that are invasive with be
eschewed
! 
! 
! 

Customers hate intrusion
Corner cases == support costs == no profit
End-to-endy
3
Wishful thinking

Protocol development provides exactly
enough hint to do good, and not enough to
do harm.
!  The cracks in “network neutrality” don’t
become a complete breach.
! 

4
Harald Alvestrand
Endpoint

http://www.internetsociety.org
General discussion

http://www.internetsociety.org
At the heart of the matter

[How] Does the end-to-end
principle matter in today’s
Internet and going forward?

14

The Internet Society

Evolution of end-to-end: why the Internet is not like any other network