Title: Services Architectures
1Services Architectures Network Intermediaries
and End-to-end Abstractions
- Dan Duchamp
- Stevens Institute of Technology
- Tilman Wolf
- University of Massachusetts Amherst
2Outline
- Premise The next-generation Internet needs to do
more than provide end-to-end bit pipes - Three topics
- Network services and incentives (Dan)
- Implementation challenges (Tilman)
- Trust and naming (guest speaker Paul Francis)
- Process
- Questions
- Brief presentation of context
- Long discussion
- Comments and questions welcome anytime!
3Network Services and Incentives
4Questions
- 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?
5Questions (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, spy-able Internet? - What is the right technical tradeoff point
between (1) a "civilized" appropriately-governable
Internet, and (2) an Internet permitted "free
expression"?
6Session Layer Management of Network Intermediaries
- Dan Duchamp
- Computer Science Department and
- Wireless Network Security Center (WiNSeC)
- Stevens Institute of Technology
- Hoboken, NJ
7The 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
8Why 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
9The Point Is
- Internet has already been broken into discrete
pieces - Situation is not going to change
- We can either complain about it (end-to-end
zealots) or deal with it
10Basic 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
11Consequences
- Easier to manage intermediaries if they are
explicitly addressed - Easier to manage network too
- Transport connections now long-lived heavily
usedthats how they work best - Amortize Path MTU discovery
- Maintain sstresh/cwnd settings
- More statistical multiplexing less burstiness
12Hypothesized 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
13Foreseen 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 securityservice X should see
only one part of payload, service Y only another
part
14Foreseen Philosophical Problems
- Unambitious just what we dont needanother 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?
15Relation to FIND/GENI
- Yes, its trueL5 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 itnetwork or host? - State management
- Semantics/protocol for control signaling between
end system intermediary - Mapping of function to layers
16Questions
- 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?
17Questions (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, spy-able Internet? - What is the right technical tradeoff point
between (1) a "civilized" appropriately-governable
Internet, and (2) an Internet permitted "free
expression"?
18Implementation Challenges
19Questions
- 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?
20Questions (cont.)
- Should all services be visible to end-systems?
Should all data modifications be reported to
end-systems? - 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)
21Service-Centric End-to-End Abstractions
inNext-Generation Networks
- Tilman Wolf
- Department of Electrical and Computer Engineering
- University of Massachusetts Amherst
22Information vs. Data
- Current Internet considers data as unchangeable
entity - Information encoded on end-systems
- Network unaware of semantics
- End-systems want to transfer information
- Use of explicit information transfer semantics
- Network communicates and processes information in
suitable way - High-level semantics sufficient
- 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
23Information Transfer and Data Services
- Processing of data not limited to end-systems
anymore - Data processing throughout the network
- Services
- Reliability
- Privacy
- Congestion control
- Caching
- Security (e.g., firewall, IPS/IDS)
- Quality of service
- Multicast
- Payload transcoding
24Services
- Services can be combined for end-to-end
information transfer - Example 1
- Reliable and private communication
- Example 2
- Web caching
25Services
- Example 3
- Content distribution and transcoding
- How can all this be implemented?
26Service Platforms
- Network processors are specialized processing
system for packet processing - System-on-a-chip multiprocessor
- Optimized for networking workloads
- Typical configurations
- Tens to hundreds of processing engines
- Multiple memory interfaces, co-processors
- Commercially available
- Intel, AMCC, Freescale, Hifn, etc.
Control processor
Multiple data path processors
Memory
I/O
27Service Specification
- Abstraction for services along connection
- Similar to UNIX pipe concept
- Example 1 transfer between nodes
- N1 gt N2
- Example 2 reliable transfer between nodes
- N1 TCP_TX gt N2 TCP_RX
- Example 3 transcoding at arbitrary intermediate
node - N1 TCP_TX gt TXP_RX TRANSCODE TCP_TX
gt N2 TCP_RX - Leads to placement problem
- Assignment of processing tasks to underlying
infrastructure
28Service Placement
- Mappingproblemappears onall layersof system
- End-to-end
- Routers
- Port processors
29Service Placement
- Layered graph approach
- Single metric for communication and computation
Source of connection
Extra layer with vertical processing steps
Destination of connection
30Service Placement
- Ramdomized mapping approach
- Random placement
- Fast analytics evaluation
- Repeat
- Performance
- Incrementallybetter results
31Summary 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
32Questions
- 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?
33Questions (cont.)
- Should all services be visible to end-systems?
Should all data modifications be reported to
end-systems? - 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)
34Trust and Naming
35Questions
- 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?
36End-Middle-End Architectures
- Paul Francis
- Cornell University
37Most basic function in the Internet
- Send a packet from an app on one host to an app
on another host - Often doesnt work
- Sometimes an unwanted connection can be made
- Often a wanted connection cannot be made
38What is the problem?
- IPv6 folks think (thought?) the problem is NATs
- But firewalls often err
- Port number only meaningful at the endhost
- Addresses change
- Shouldnt access control be done at the hosts?
- Argument of IPv6ers and E2E purists
39We still need firewalls
- DoS
- Privacy of endhost
- IP address gives away private information
- Study of 100K mobile dyndns users
- Reality of infrastructure evolution
- Sometimes its just easier to put a box in the
middle
40Other reasons to put stuff in the middle
- Proximity (web caches)
- Benefits of scale (spam filtering)
- Centralized control
- Ease of deployment
41End-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
42Do 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
43EME 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
44EME Architecture
- Demote 5-tuple connection
- Ephemeral
- Use name-based signaling to manage connections
- Make this name-based approach part of the common
sockets API
45Slightly 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
46Questions
- 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?