Transcript Talk Slides on Services Architectures

Services Architectures –
Network Intermediaries
and End-to-end
Abstractions
Dan Duchamp
Stevens Institute of Technology
Tilman Wolf
University of Massachusetts Amherst
Outline


Premise: The next-generation Internet needs
to do more than provide end-to-end bit pipes
Three topics:
1.
2.
3.

Process




Network services and incentives (Dan)
Implementation challenges (Tilman)
Trust and naming (guest speaker: Paul Francis)
Questions
Brief presentation of context
Long discussion
Comments and questions welcome anytime!
Network Services
and Incentives
Questions




What services should the network provide?
Should the network offer service at the application level
rather than at the datagram level?
Should anybody be allowed to provide services or not
(and thus reduce potential for spam, phishing, spyware,
etc.)?
Will ease/speed of new service deployment be as
important in the future as it has been in the past? Will the
rate increase or decrease?
Questions (cont.)





Capitalists would like to know: how should
accounting/billing work?
Should we construct a network that could, for example,
bill per page view?
Socialists would like to know: how can "undesirable
uses" of the Internet be limited?
What is the appropriate position for network architects to
take regarding the design of censor-able, tap-able, spyable Internet?
What is the right technical tradeoff point between (1) a
"civilized" appropriately-governable Internet, and (2) an
Internet permitted "free expression"?
Session Layer Management
of Network Intermediaries
Dan Duchamp
Computer Science Department and
Wireless Network Security Center (WiNSeC)
Stevens Institute of Technology
Hoboken, NJ
The Discrete Internet

Original Internet:
 Infrastructure
supported by US government
 Users like-minded, like-behaving
 Intelligent hosts at edges of dumb routing fabric

Current Internet:
 Commercially
owned
 Subject to government oversight
Why Deploy Intermediaries?

Commercial incentives:
 “Added
value” – avoid being “dumb pipe”
 Place service hosts closer to client hosts to
improve latency (e.g., Akamai)

Customer incentives:
 Enforce
customer policies on customer-owned
networks (e.g., firewall)
 IP address flexibility/security (NAT)

Government incentives:
 Law
enforcement & surveillance
The Point Is …
Internet has already been broken into
discrete pieces
 Situation is not going to change
 We can either complain about it (end-toend zealots) or deal with it

Basic Idea


End-to-end layer 5 (L5) session runs over
sequence of layer 4 (L4) transport connections
Intermediaries explicitly addressed, each
terminates an L4 connection
Consequences
Easier to manage intermediaries if they
are explicitly addressed
 Easier to manage network too
 Transport connections now long-lived &
heavily used—that’s how they work best:

 Amortize
Path MTU discovery
 Maintain sstresh/cwnd settings
 More statistical multiplexing = less burstiness
Hypothesized Benefits
Cleaner programming model
 Improved congestion control
 Improved core link utilization
 More efficient physical/routing design
 Improved session performance via pipeline
parallelism

 Important
qualification: improved performance
after session has been established

Easier traffic engineering
Foreseen Technical Problems
How to locate desired intermediate service?
 Session setup too slow
 Study buffer management
 How to manage intermediary state?
 Additional points of failure & types of failures
 What is right app-intermediary control
semantics/protocol?
 Want “piecewise security”—service X should
see only one part of payload, service Y only
another part

Foreseen Philosophical Problems
Unambitious: just what we don’t need—
another hack to the socket/TCP/IP model
 Network is still pretty dumb: should know
more about session semantics?
 If L5 handles end-to-end delivery
semantics, what does L4 do?

Relation to FIND/GENI
Yes, it’s true—L5 is just a tweak, not a new
architecture
 But: gives a concrete base for experiments
with certain architectural issues:

 What
is a service? Where is it implemented?
Who really provides it—network or host?
 State management
 Semantics/protocol for control signaling
between end system & intermediary
 Mapping of function to layers
Questions




What services should the network provide?
Should the network offer service at the application level
rather than at the datagram level?
Should anybody be allowed to provide services or not
(and thus reduce potential for spam, phishing, spyware,
etc.)?
Will ease/speed of new service deployment be as
important in the future as it has been in the past? Will the
rate increase or decrease?
Questions (cont.)





Capitalists would like to know: how should
accounting/billing work?
Should we construct a network that could, for example,
bill per page view?
Socialists would like to know: how can "undesirable
uses" of the Internet be limited?
What is the appropriate position for network architects to
take regarding the design of censor-able, tap-able, spyable Internet?
What is the right technical tradeoff point between (1) a
"civilized" appropriately-governable Internet, and (2) an
Internet permitted "free expression"?
Implementation
Challenges
Questions




If services are (partially) provided in the network,
what is the appropriate "cut" between what is
done in the network and what is done at the
host? Does one “cut” fit all?
How should services be accessed? Should the
end-system application choose or should the
network enforce service use?
How much should the network know about data
semantics?
Is the web browser the "last application"? That
is, every future service will have its host
implementation as a browser plugin?
Questions (cont.)




Should all services be visible to end-systems?
Should all data modifications be reported to endsystems?
Should communication between services be
allowed?
How should service state be handled?
What services are necessary at the edges of
networks with different operating principles (e.g.,
Internet to/from sensor net)
Service-Centric
End-to-End Abstractions in
Next-Generation Networks
Tilman Wolf
Department of Electrical and Computer Engineering
University of Massachusetts Amherst
Information vs. Data

Current Internet considers data as unchangeable entity




End-systems want to transfer information
Use of explicit “information transfer” semantics


Network communicates and processes information in suitable
way
High-level semantics sufficient





Information encoded on end-systems
Network unaware of semantics
Streaming vs. random access
Point-to-point vs. multipoint
Interactive vs. “canned”
Bandwidth-sensitive vs. delay-sensitive
Requires network to do more than forward bits
Information Transfer and Data Services



Processing of data not limited to end-systems anymore
Data processing throughout the network
Services:
Application Layer
Application Layer








Reliability
Privacy
Congestion control
Caching
Security (e.g., firewall,
IPS/IDS)
Quality of service
Multicast
Payload transcoding
processing
processing
Transport Layer
Transport Layer
Network Layer
Network Layer
Network Layer
Link Layer
Link Layer
Link Layer
Physical Layer
Physical Layer
Physical Layer
Information Transfer and Data Services Layer
processing
processing
processing
processing
Network Layer
Network Layer
Network Layer
Link Layer
Link Layer
Link Layer
Physical Layer
Physical Layer
Physical Layer
Services


Services can be combined for end-to-end information
transfer
Example 1:

Reliable and private communication
information
encoding

encryption
decryption
privacy
service
privacy
service
reliability
service
reliability
service
information
decoding
Example 2:

Web caching
information
encoding
reliability
service
reliability
service
reliability
service
information
encoding
reliability
service
reliability
service
web
caching
reliability
service
information
decoding
Services

Example 3:

Content distribution and transcoding
reliability
service
information
encoding
reliability
service
payload
transcoding
reliability
service
reliability
service
information
decoding
reliability
service
information
decoding
reliability
service
multicast

reliability
service
reliability
service
How can all this be implemented?
Service Platforms

Network processors are specialized processing system
for packet processing



Typical configurations



Control processor
System-on-a-chip
multiprocessor
Optimized for networking
workloads
Tens to hundreds of
processing engines
Multiple memory interfaces,
co-processors
Commercially available

Intel, AMCC, Freescale,
Hifn, etc.
Memory
I/O
Multiple
data path
processors
Service Specification

Abstraction for services along connection


Example 1: transfer between nodes


{N1 | TCP_TX > N2 | TCP_RX}
Example 3: transcoding at arbitrary intermediate node


{N1 > N2}
Example 2: reliable transfer between nodes


Similar to “UNIX pipe” concept
{N1 | TCP_TX > * | TXP_RX | TRANSCODE | TCP_TX
> N2 | TCP_RX}
Leads to placement problem

Assignment of processing tasks to underlying infrastructure
Service Placement

Mapping
problem
appears on
all layers
of system



End-to-end
Routers
Port processors
End-to-end Information Transfer
Endsystem
Router
Endsystem
Router
Router
Data Services
mapping
Router
Router
Endsystem
network
Router
Service Provisioning on Routers
Data service
Mapping Computation on
Network Processors
Data service
mapping
mapping
Router
Port
Port
Switching
fabric
Port
Port
Network processor
Proc.
Proc.
Proc.
Proc.
Proc.
Proc.
Service Placement

Layered graph approach

Single metric for communication and computation
Source of
connection
Extra layer
with vertical
“processing
steps”
Destination
of
connection
Service Placement

Ramdomized mapping approach:




Random
placement
Fast analytics
evaluation
Repeat
Performance

Incrementally
better results
Summary and Next Steps

Abstraction based on information and data
services
 Network
can provide best setup for end-to-end
communication
 Requires processing capabilities throughout the
network

Tackle implementation issues
 Service
specification
 Service placement
 Prototype demonstration
Questions




If services are (partially) provided in the network,
what is the appropriate "cut" between what is
done in the network and what is done at the
host? Does one “cut” fit all?
Is the web browser the "last application"? That
is, every future service will have its host
implementation as a browser plugin?
How should services be accessed? Should the
end-system application choose or should the
network enforce service use?
How much should the network know about data
semantics?
Questions (cont.)




Should all services be visible to end-systems?
Should all data modifications be reported to endsystems?
Should communication between services be
allowed?
How should service state be handled?
What services are necessary at the edges of
networks with different operating principles (e.g.,
Internet to/from sensor net)
Trust and Naming
Questions







Should the Internet provide "trust"?
Should we have source/identity validation?
If application creators (apparently) want source/identity
validation, why not provide it?
Is a better tradeoff between trust/flexibility achievable?
How?
What should we use to identify end-system processes,
users, etc.?
How should we maintain identity mapping under
mobility?
Should the network understand the semantics of a data
exchange?
End-Middle-End
Architectures
Paul Francis
Cornell University
Most basic function in the Internet:

Send a packet from an app on one host to
an app on another host

Often doesn’t work…
 Sometimes
an unwanted connection can be
made
 Often a wanted connection cannot be made
What is the problem?
IPv6 folks think (thought?) the problem is
NATs
 But firewalls often err

 Port
number only meaningful at the endhost
 Addresses change

Shouldn’t access control be done at the
hosts?
 Argument
of IPv6’ers and E2E purists
We still need firewalls
DoS
 Privacy of endhost

 IP
address gives away private information
 Study of 100K mobile dyndns users

Reality of infrastructure evolution
 Sometimes
middle
its just easier to put a box in the
Other reasons to put stuff in the middle
Proximity (web caches)
 Benefits of scale (spam filtering)
 Centralized control
 Ease of deployment

End-Middle-End architecture

Need an architecture that allows all
stakeholders in a connection to:
 Know
what is going on
 Assert their policies
 Access control policies
 Steering policies
 Security policies
 Transport policies
Do we need a blank slate?

Maybe

But lots of progress can be made on the
existing infrastructure

Formed EME IRTF Research group
 Initiated
by Francis and Handley
 Chaired by Tilman Wolf
 Early stages
EME requirements

Authentication, access control, and privacy
 Name-based
Middlebox discovery and control
 Steering through middleboxes
 Anycast, multicast
 Mobility, multihoming
 Multi-party negotiation
 Performance
 Incremental deployability

EME Architecture

“Demote” 5-tuple connection
 Ephemeral
Use name-based signaling to manage
connections
 Make this name-based approach part of
the common sockets API

Slightly more detail

Two types of signaling
 Off-path
Used when IP address(es) not known
 Or to obtain (optional) credentials
 SIP is a good model

 On-path
Used when IP address(es) known and have
credentials
 Get through firewalls
 Steer connections

Questions







Should the Internet provide "trust"?
Should we have source/identity validation?
If application creators (apparently) want source/identity
validation, why not provide it?
Is a better tradeoff between trust/flexibility achievable?
How?
What should we use to identify end-system processes,
users, etc.?
How should we maintain identity mapping under
mobility?
Should the network understand the semantics of a data
exchange?