Services Architectures –Network Intermediaries and End-to-end AbstractionsDan Duchamp Stevens Institute of Technology

Tilman WolfUniversity of Massachusetts Amherst

Outline Premise: The next-generation Internet needs

to do more than provide end-to-end bit pipes Three topics:

1. Network services and incentives (Dan)

2. Implementation challenges (Tilman)

3. Trust and naming (guest speaker: Paul Francis)

Process 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, spy-able 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 DuchampComputer Science Department andWireless Network Security Center (WiNSeC)Stevens Institute of TechnologyHoboken, NJ

The Discrete Internet Original Internet:

Infrastructure supported by US governmentUsers like-minded, like-behaving Intelligent hosts at edges of dumb routing fabric

Current Internet:Commercially ownedSubject 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-to-

end 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 discoveryMaintain sstresh/cwnd settingsMore 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 managementSemantics/protocol for control signaling

between end system & intermediaryMapping 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, spy-able 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 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)

Service-Centric End-to-End Abstractions inNext-Generation Networks

Tilman WolfDepartment of Electrical and Computer Engineering

University of Massachusetts Amherst

Information 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

Information 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

Network Layer

Link Layer

Physical Layer

Transport Layer

Application Layer

Network Layer

Link Layer

Physical Layer

Transport Layer

Application Layer

Network Layer

Link Layer

Physical Layer

processing processing

Network Layer

Link Layer

Physical Layer

Information Transfer and Data Services Layer

Network Layer

Link Layer

Physical Layer

Network Layer

Link Layer

Physical Layer

processing processing processing processing

Services Services can be combined for end-to-end information

transfer Example 1:

Reliable and private communication

Example 2: Web caching

information decoding

information encoding

reliabilityservice

reliabilityservice

privacy service

privacyservice

encryption decryption

information decoding

web caching

information encoding

reliabilityservice

reliabilityservice

information encoding

reliabilityservice

reliabilityservice

reliabilityservice

reliabilityservice

Services Example 3:

Content distribution and transcoding

How can all this be implemented?

multicast

information encoding

payloadtranscoding

reliabilityservice

reliabilityservice

reliabilityservice

information encoding

information decoding

reliabilityservice

reliabilityservice

reliabilityservice

information decoding

reliabilityservice

reliabilityservice

Service 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.Multiple data path

processors

Memory

I/O

Control processor

Service Specification Abstraction for services along connection

Similar to “UNIX pipe” concept Example 1: transfer between nodes

{N1 > N2} Example 2: reliable transfer between nodes

{N1 | TCP_TX > N2 | TCP_RX} Example 3: transcoding at arbitrary intermediate node

{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

problemappears onall layersof system End-to-end Routers Port processors

Router

Router

Router

End-system End-

system

End-system

Router

Router

Router

Router

Router

Router

End-system End-

system

End-system

Router

Router

End-to-end Information Transfer

network

mapping

Router

Data ServicesRouter

Router

Router

End-system End-

system

End-system

Router

Router

End-to-end Information Transfer

network

mapping

Router

Data Services

Service Provisioning on Routers

mapping

Data service

Router

Switchingfabric

Port

Port Port

Port

Router

Router

Router

End-system End-

system

End-system

Router

Router

End-to-end Information Transfer

network

mapping

Router

Data Services

Service Provisioning on Routers

mapping

Data service

Router

Switchingfabric

Port

Port Port

Port

Mapping Computation on Network Processors

mapping

Data service

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 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)

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

madeOften 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 endhostAddresses 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 informationStudy of 100K mobile dyndns users

Reality of infrastructure evolutionSometimes its just easier to put a box in the

middle

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 onAssert 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 HandleyChaired by Tilman WolfEarly 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?