npa10 future internet arch - net.t-labs.tu-berlin.de€¦ · 35 Usenet – NNTP rExchange of...

Future Internet

Revisiting the Internet architecture?

Prof. Anja Feldmann, Ph.D.Deutsche Telekom Laboratories

TU Berlin

The “Internet”

The “Internet”: What is itr Visualization (2002)

~ 535,000 Nodes > 600,000 Links

r Social phenomenam Cyperspacem Changing/redefining

communication • Human to human,

human to computer, ….

The “Future Internet”?r Information and Media

Societym Everyone generates contentm Sensors and cameras

everywherem New distribution channels

r Challengesm Verificationm Fusion/filtering of

informationm Situation adaptationm Incentives, trust, privacy

What makes the Internet so sexy

r Applications can be deployed by anybody that is connected to the Internet(Fundamentally different to the Telephone world)

rMulti-service network: Everything over the Internet

TCP/IP protocol structure

Transport(Hosts)

Network

Application(Processes)

TCP UDP

Telnet FTP

DNSHTTP SMTP

FDDI ATM

Tokenring Ethernet

What makes the Internet so sexy

r Applications can be deployed by anybody that is connected to the Internet(Fundamentally different to the Telephone world)

rMulti-service network: Everything over the Internet

m Every application protocol over IPm IP over any network technology

Internet design goals

(in decreasing order of importance)mConnect existing networks mSurvivabilitymSupport multiple types of servicesmMust accommodate a variety of networksmAllow distributed managementmAllow host attachment with a low level of

effortmBe cost effectivemAllow resource accountability

Today’s Internet – out of shape!!!

rRedesign needed?

Data plane Control plane

Picture due to Rui Aguilar

Today’s Internet: Architectural limitsr Trust assumptions

m Internet assumes cooperation

r Competitionm Original Internet assumed no commercial considerations

r Edge diversitym Original Internet is host-centricm Ignores mobility, sensors, ...

r Network servicesm Original Internet exposes limited informationm Limits new servicesm Limits network managementm Almost no changes in the network core

r Designed to be a open, cooperating systemr Focus on data plane

Today’s Internet: Challenges

r Heterogeneity any which way you lookm Users, applications, hardware, traffic

r An immense moving targetr Highly interacting systemsm Temporal: between users, hosts and networks

m Spatial: among different components

m Vertical: across different networking layers

Why rethink the Internet architecture

r Reliability and availabilitym E-Commerce increasingly depends on fragile Internetm Debuggability

r Securitym Known vulnerabilities lurking in the Internetm Addressing security has a significant cost

r Scale & Diversitym Cyberspace (everything is networked)

r Support for new applications/servicesm Mobility / Quality of servicem High speed connections to the home

r Economicsm Cost-effectivelym Business models

FAll are control plane issues!

Rethinking the Internet architecturer Explore alternative architecturesr Approachm Incremental

• Apply point-solutions to the current architecture

m Clean slate design (CSD)• Start from scratch

r Advantage CSDm No limitations: enables rethinking of the network and

service architecturem Architecture not intrinsicm Experiments and failures are possible

How to get there?r How to determine that one has a good new architecture?m Paperware? Nom Built, evaluated, used? Yes

r Approach:m Experimental facilitym Research into new architectures

r Benefit:m Intellectual challenge:

uncover otherwise ignored system aspectsm Research how to build/operate an experimental facility

FGo beyond point solutions

Clean slate design: DriversrTechnicalm Virtualization techniquesm Cloud computing / networkingm Significant computational resources in the networkm Fast packet forwarding hardware, e.g., OpenFlow

rStarting pointsm PlanetLab / OneLabm Geant2/Internet2m Emulabm Vinim…

Future Internet: Sample initiatives and projects

EU IST FP7 Future Internet projects http://www.future-internet.eu/activities/fp7-projects.html

Future Internet network design –FIND http://find.isi.edu/ Future Internet network design –FIND http://find.isi.edu/

Clean Slate Program (Stanford University) Clean Slate Program (Stanford University)

AKARI Project (Japan) AKARI Project (Japan)

Groupe de Reflexion Internet du Futur (France)Groupe de Reflexion Internet du Futur (France)

ANR (France) ANR (France) it839/u-it839 (Korea) it839/u-it839 (Korea)

NICTA (Australia) NICTA (Australia)

G-LAB funded by BMBF (Germany) G-LAB funded by BMBF (Germany)

Super Janet funded by EPSRC (UK) Super Janet funded by EPSRC (UK)

Internet del Futuro (SP)Internet del Futuro (SP)

CNGI Project (China) CNGI Project (China)

Revisiting traffic characteristics: Why?

r Constantly changingr Basis of most architectural changes

r Residential broadband access popular/widespreadrDiffers from well-studied campus and enterprise

trafficm Not subject to acceptable-use policies

Motivation

Usage changes: „Killer application?“

rWWW and the Internetm 1993: ... Hardly any WWW traffic on the Internetm 1994: ... About 10% of total Internet traffic is WWWm 95/96: ... Up to 60-70% of overall Internet traffic is

WWWm…??????...

Application mix?

However: MWN traffic by port(24 hours of traffic to/from MWN clients in 2006)

0.00%0.00%1.66%10421.71%1.05%1.85%Mail 251.71%1.75%2.12%SSH 221.29%2.08%2.34%Web 443

0.00%0.00%1.06%1433

0.00%0.01%3.53%445

72.59%68.13%70.82%Web 80

20.95%4.08%16.32%> 102479.05%73.73%83.68%< 10240.00%0.00%1.04%135

% Payload% Success% ConnsPort

Application mix – today?

Outline

r Revisiting traffic characteristicsm Data setsm Dominant characteristics

• Application usage• HTTP usage• NNTP usage• Performance/path characteristics

r Revisiting ISP – application relationship r Revisiting Routingr Revisiting Network structurer Revisiting Splitting control and forwarding

Outline

Data sets (1)

r Large European ISP (>10M customers in total)r Anonymized packet level tracesm Covering >20,000 DSL customersm One urban area

rOverview of packet level tracesm 14 x 90min; twice per day over 1 week in Aug 2008m 24hr in Sep 2008 (>4TB)m 24hr in Apr 2009 (>4TB)

r Bro Intrusion Detection System for analysis

Data sets

Data sets (2)

r Anonymized DSL session tracesm DSL connect / disconnect timesm Anonymized line-card IDm Access bandwidthm Augments packet data

rOverview of session tracesm One for each packet tracem 10 day in Feb 2009

Data sets

Outline

Methodology

r Using Bro's Dynamic Protocol Detection (DPD)m Protocol semantics and/orm Signatures

r 85% of bytes classifiedr Another 3.6% on well-known portsr No dominant day-of-week effectsr VerificationmWith NetFlow data (port based)mWith commercial Deep Packet Inspection (DPI)

system at different location

Application Usage

Application usage per hour

Application Usage

unclassified

well-known

other DPD

eDonkey

BitTorrent

Application usage per b/w

unclassified

well-known

other DPD

eDonkey

BitTorrent

Key results

rHTTP dominates? : 57% of bytesr P2P less than 14%r Unclassified: 11%rOther significant protocolsm NNTP 2–5%m Streaming (non-HTTP) 5%m Voice-over-IP 1.3%

r Port based classification works well for non-P2P protocols

Application Usage

? Erman et al. found very similar results in cotemporaneous work presented at WWW'09

Outline

Motivation & methodology

rWhy is HTTP so popular (again)?m HTTP offers popular high-volume content?m HTTP as transport protocol for other applications?

r Anonymized HTTP headers extracted via BrorDetermine content-typem Content-type headerm Libmagic

r Second level domain (from Host header)r User-Agent header

HTTP Usage

Key resultsr Popular content-types by volume

rDomain popularity:m One-click-hoster is top domain: 15% of HTTP bytesm Video portals (using flash-video) follow

r No significant hiding / tunneling via HTTPØHTTP dominance due to popular high-volume

content

HTTP Usage

flash-video25.2%

RAR14.7%

image11.5%

video7.6%

other23.4%

unclass. 17.6%

0 20 40 60 80 100

Flash-Video clearly dominates

Outline

Usenet – NNTPr Exchange of news/messages

m Subsumed by forums, wikis and blogs

m Said to be outdated and only used by “geeks”

m Most servers do not allow binary content and have short retention times.

r What has changed?m Fee-based NNTP server

operators, e.g., UseNeXT or GigaNews

m 99 % NNTP volume is binarym Competes with One-Click-

Hosters as client/server based alternative for file-sharing

Application Usage

Outline

TCP options / performance

rWindow scalingm Approx. 50% of host advertise scaling; most non-zeromMaximal advertised window often 64KB

r Loss/reordering in 10% of connectionsr Bandwidth-delay product > max. rcv. windowm Affects 44% of connections with >50KB volume

(downstream)

rMost lines only use small fraction of bandwidth

Performance/Path Characteristics

Round-trip-times (RTT)r Assessed during TCP handshake

m Local component dominates (DSL interleaving)

m Median: 74msm 99th perc: 1328msm Wireless equipment

can cause significant delays

Achieved flow throughputApplication Usage

Achieved throughput

rMost lines only use small fraction of bandwidthr Throughput by application and flowm HTTP, NNTP have order of magnitude higher

throughput than P2P

rMean number of parallel flowsm P2P has 5 times as many as HTTPm P2P and NNTP similar

Summary – Residential traffic study

r High IP address churn (4% assigned > 10 times)r HTTP dominates traffic: >57%

m P2P only 14%m NNTP noticeable

r Flash-video (video portals) most popular in HTTP: >25% m RAR-archives (One-click-hosters): >14%

r Performancem DSL bandwidth in general not fully utilizedm Window advertisements might limit performancem Local RTT component dominates (DSL interleaving)

Summary

Outline

Internet and traffic engineering

Source: Arbor Networks 2009

Internet and traffic engineering

Source: Arbor Networks 2009à Offline Process

Adjust routing or peering, dimension the network

Traffic Engineering:

The new Internet

à New core of interconnected content and consumer networks

The new Internet

à New core of interconnectedcontent and consumer networks

Google, Google, AkamaiAkamai, ,

RapidShareRapidShare, , ……

The new Internet

Moving Target I :

Popular Applications

The new Internet

Moving Target I :

Moving Target II :

Bottlenecks

The new Internet

Moving Target II :Bottlenecks

à ISPs lost control of their traffic

Moving Target I :

The new Internet

Moving Target II :Bottlenecks

à ISPs lose control of their network

Moving Target I :

“Telekom’s chief executive, said Google and others shouldpay telecoms groups for carrying content on their networks”

Challenge

Content-aware Traffic Engineering

ISPs re-gain control of their traffic by biasing host selection

Grand challenge

àOnlineàNo routing re-configurationàNo additional investmentsà Possible reduction of operational costà Potential negotiation tool

Content-aware Traffic Engineering

ISPs re-gain control of their traffic by biasing host selection

Roadmap

Measurements

System

Design & Deployment

Field TestISP-Application Collaboration

Measurements

System

Design & Deployment

Field Test

System

Design & Deployment

Field Test

System

Design & Deployment

Residential traffic

Source: Maier et al, IMC’09

àRecall: HTTP is responsible for around 60% of total traffic

à This trend should continue (flash video, cloud applications, datacenters)

Client

External DNS

Provider DNS

Internet Service ProviderInternet Service Provider(ISP)(ISP)

Content Distribution and DNS

Client

External DNS

Provider DNS

DNS Reply Aggregator

Content Distribution and DNS

$ dig photos-h.ak.fbcdn.net<<>> DiG 9.7.0-P1 <<>> photos-h.ak.fbcdn.net;; QUESTION SECTION:photos-h.ak.fbcdn.net. IN A;; ANSWER SECTION:photos-h.ak.fbcdn.net. 6099 IN CNAME photos-

d.ak.facebook.com.edgesuite.net.photos-d.ak.facebook.com.edgesuite.net. 20492 IN

CNAME a998.mm1.akamai.net.a998.mm1.akamai.net. 7 IN A 62.41.85.74a998.mm1.akamai.net. 7 IN A 62.41.85.90...

Reply anatomyàRequesting a photo from Facebook

2nd Level Domain à Application

Redirection à Content Provider

Consolidation of content

àTop-10 applications or content providers are responsible for around 50% the HTTP traffic.

Diversity of paths

àMore than 60% of the HTTP traffic can be download from at least 3 different locations

Measurements

System

Design & Deployment

Client

External DNS

Provider DNS

6PaDISPaDIS

Provider-aided Distance Information System

Client

External DNS

Provider DNS

6PaDISPaDIS

Full View Full View of the ISP of the ISP NetworkNetwork

Client

External DNS

Provider DNS

6PaDISPaDIS

Content can be downloaded from any eligible host!

Client

External DNS

Provider DNS

6PaDISPaDIS

Client

External DNS

Provider DNS

6PaDISPaDIS

Host4 Host2

Client

External DNS

Provider DNS

6PaDISPaDIS

68Client

Host A

Host B

Host C

Network load balancing

Client

Host A

Host B

Host C

Network load balancing

Client

Host A

Host B

Host C

Path diversity

0.5% 5% 50%

à Top-10 content providers and applications

àReduction up to 30%on congested link

à 5-10% reduction in total traffic

àNo increase in path length

à Improve locality of HTTP traffic from 25% à 50%

Link Utilization

Rebalance of traffic to less congested links

Measurements

System

Design & Deployment

Roadmap

Improving content access timeCase study: CDN

Improving content access time Case study: One-Click Hosters

Measurements

System

Design & Deployment

Field Test

ISP-Application Collaboration

Roadmap

Client

External DNS

Provider DNS

6PaDISPaDIS

ISP applications collaboration

Client

External DNS

Provider DNS

6PaDISPaDIS

ISP-applications collaboration

Client

External DNS

Provider DNS

6PaDISPaDIS

Host2Host2

Host3Host3

Host1Host1

Host4Host4

Summaryr Alternative traffic engineering

m Do not change the routingm Change the traffic matrix!

r Benefitsm ISPs: Regain control of network trafficm User: Performance improvements

à Win-win situation for ISPs and end-users à ISPs can share benefits with content and application providers

r PADIS m Simple and easy to implementm Prototype running

Outline

Exploring Alternative Architectures

HAIR: Hierarchical Architecturefor Internet Routing

Routing scalability: Problems

r IP addresses usagem Locator within the Internetm Identifier for applications

r Routing table size growthm Multi-homingm Traffic engineeringm Prefix disaggregation

Routing scalability: Problems

r Churn: High update ratesm Due to mobilitym Due to global visibilitym Due to „overuse“ of policym ...

Routing scalability: Current workarounds

staticlarge RTlarge RT

high upd ratehigh

upd rate

dynamic

Scalability issues

expensive TCAMexpensive TCAM

high workloadto maintain RThigh workloadto maintain RT

control plane

data plane

Consequences limited TE

limited TE

limitedmobilitylimitedmobility

Problems

massivefilteringmassivefiltering

dampeningdampening

Workarounds

static

dynamic

Approach

r Key ideasm Separation of locator/identifier function of IP address

=> separation of routing and location mapping

130.149.220.23TU-Berlin

Approach

mHierarchy for routing and location mapping

Approach

mHierarchy for routing and location mapping

r Two componentsm Routing system based on locatormMapping system to map an identifier to a locator

Hierarchical routing

r Network is organized in multiple levelsr Levels are separated by separatorsr Routers only know the details about their level

Separator

Hierarchical routing: Internet

rWhere do we have small separators?r Internet structurem Core

• Set of interconnected autonomous systems (ASs)• Tier-1, tier-2 ASs, …• Transit ASs

Stub ASAccess Provider

EnterpriseNetwork

TransitAS 1

TransitAS 2

ISP2ISP3

r AS corem ~5000 ASs

r AS edgem ~30000 AS

EnterpriseNetwork

ISP2ISP3

TransitAS 1

TransitAS 2

r AS corem ~5000 ASs

r AS edgem ~30000 AS

EnterpriseNetwork

ISP2ISP3

TransitAS 1

TransitAS 2

Potential large

separator

Potential small

separator

rWhere do we have small separators?r Internet structurem Core

• Set of interconnected autonomous systems (ASs)• Tier-1, tier-2 ASs, …• Transit ASs

m Intermediate• Stub ASs, e.g., metropolitan area networks• Enterprise networks• Content distribution networks

m Edge• Local area networks

r Separator sizem Core -> Intermediate

• Stub ASs, e.g., metropolitan area networks: < 10 links• Enterprise networks: < 10 links• Content distribution networks: < 1000 links

m Intermediate -> Edge• Local area networks: < 10 links

r Terminologym Core /WANm Intermediate / MANm Edge / LANm Separator / Attachment point (AP)

Hierarchical network

r Example: Three levels of hierarchym Routing via intermediate points – the separators

=> specify attachment pointsmWAN APs: WAP

• Provider access links

mMAN APs: MAP• Firewalls

Sending a packet

r Routing via intermediate access pointsmMapping service: resolve identifier to locatorm 3 locator parts: WAP|MAP|ID

Routing scalabilityr Core

m Routing based on WAPsm Stable business relationshipsm Almost no churnm Aggregatable addresses m Common routing protocol (e.g., BGP)

r Intermediate (smaller ISPs/enterprises)m Routing based on MAPsm Separate addresses and routingm Local changes à local impact

r Edge (e.g., Ethernet LAN)m Standard L2 switching

Mapping system

rDesign requirementsm Scales with number of hostsm Fast response timesm Easy to update

r Approachm Clients are responsiblem Hierarchical design

• Global DHT or DNS like system– For each identifier: pointer to MMS– WANs contribute resources

• MAN mapping service (MMS) – Stores locators for attached nodes – Provided by MAN(s)

Mapping identifiers to locators

r Stepsm Client queries

• Global DHT• MMS

r To avoid lookupsm Use cachingm Include source

locators in packetm …

r Global DHT/MMSm Can store multiple

alternatives

r Failure recoverym Via multiple

alternatives

Discussion (1)

r Scalabilitym Hierarchical routing AND mapping systemm Updates are localized => low update ratesm No manual configuration

rMobility: local visibility of changesm Intra-MAN mobility: frequent

• Updates restricted to MMS

m Inter-MAN mobility: less frequent• Update global DHT (fast)• Move locators to new MMS

Discussion (2)

rMultihomingm Inherent support: APs exposed to routing system

rMultipathm Use multiple locators in parallel

r Inbound traffic engineering m Per-host basismMANs/MMS have control

rMigration pathm To support legacy hosts

Migration via NATs/Firewalls: Sending

r Firewalls/NAT act as MAPsr Legacy packet arrives from LANm Treat dst address as dst IDm Resolves locator for IDm Add source locator

to packet headerm Encapsulate original packet

and sends it

Migration: Receiving

rWAP strips encapsulationrMAP/NAT strips the second layermMay get the mapping for the source locator

r Packet is routed onward

To: WAP

To: MAP

Loc(A)

From: ATo: B

To: MAP

Loc(A)

From: ATo: B

A => Loc(A)

From: ATo: B

What’s different here

r Routing hierarchy based on structure of the Internetm Smaller table sizesm Lower update rates

rMapping service is hierarchicalmWith local control and responsibility

rHosts are responsible for obtaining mappingr Incremental deployment possible

Lessons learned

rMain goalsm Scalabilitym Support for multi-homing, TE, mobility, etc.m Smooth migration, support for legacy hosts

r Key ideasm Separation of locator/identifier function of IP addressm Hierarchical routing and location mapping scheme

r Two componentsm Routing system based on locatormMapping system to map an identifier to a locater

Outline

Enabling Alternative Architectures

Network Virtualization Architecture: Proposal and Initial Prototype

Network virtualization scenarios

r Virtual networkm Resource isolationm Different architecture/protocol per virtual network

• Does not have to be IP protocol• Some with some QoS and security

m Expose network components to applications and services• Overcome Internet impassé

m Dynamic • New ones will come and old ones will go• Migration / Expansion / Contraction

m Multiple networks in parallel == diversity

r Simplify network management and service offeringsr Virtual networks != VPN – VPN is just a service!

Virtual networks != P2P network – P2P is just an overlay

Virtualization: Vision

Virtualization Management

Provisioning of Virtual Networks(on-demand instantiation of virtual networks)

Infrastructure

VirtualizedSubstrate

VirtualNetworkVirtual

Network

Virtualization of Resources(partitioning of physical infrastructure into “slices”)

Virtualization Management

Provisioning of Virtual Networks(on-demand instantiation of virtual networks)

Infrastructure

VirtualizedSubstrate

VirtualNetworkVirtual

Network

Virtualization of Resources(partitioning of physical infrastructure into “slices”)

Benefits of virtualization

rOvercome ossification of network core m Isolation as enabler for new technologies

• Traditional: IPv6, multi-cast, …• CSD: novel network architectures

m Deployment of innovative productsm Network diagnosis

r Efficient utilization of resourcesmMigration of devices (such as routers)

– similar to server virtualizationm Traffic load balancing (“migration” of links)

r New business opportunities m Sharing of physical resources

(e.g., T-Mobile UK and 3 UK)

Virtual network – terminology

Virtual linksInfrastructure provider link

Virtual nodes

Physical node

Legacy nodesInfrastructure provider A

Infrastructure provider B

Substrate nodes

Virtual node – terminology

Physical Resources

InfrastructureProvider

VNet User

Substrate node control

per VNetcontrol

PhysicalLink

Roles in the Internet

r Traditional roles: m Service providers (SP)

• Google, World of Warcroft, …

m Internet Service Providers (ISPs)• Deutsche Telekom, AT&T, …

r Recently: m Physical infrastructure provider (PIPs)m Bit-pipe providers m Service providers (SP)

Roles with network virtualization

VNet Operator

VNet Provider

Infrastructure provider Infrastructure provider…..

Service Provider

Tasks: Birdseye view

r Physical Infrastructure Provider (PIP)m Provides Virtual Resources + Resource Control

Interface

r VNET Provider (VNP)m Assembles virtual networksm Intuitively: provides layer of indirection

r VNET Operator (VNO)m Operates, controls, manages virtual networks

(e.g., comparable to NOC)

r Service provider (SP)m Offers the service

Physical Infrastructure Provider

r Services:mProvides Virtual ResourcemResource Control Interface

r Input: Requests for virtualized resources from VNP

r Task: m Creation of topology (constituents)m Pointers to virtual resourcesm Resource Control Interface

• Virtual Node Bootstrapping• Interconnection

VNET Provider (VNP)

r Service: m Instantiated virtual networks

(interconnected virtual nodes with bootstrapping environment)

m Handles contracts with PIP and VNO.

r Input: Abstract request for VNetr Task: m Identify appropriate PIPsm Negotiate contractsm Partition network topology and acquire partial VNETs

and Control Interfaces m Assemble virtual networks and control interfaces from

partial VNETs provided by PIPs

VNET Operator (VNO)

r Service: m Bootstraps, operates, controls, manages fully

instantiated virtual networkm Operates on virtual resources, identified by Identifiers

(not Locators)

r Input: Interconnected virtual networkr Task: operating, managing of virtual network

Control interfaces

VNET Provider

Management PIP1

Management VNP

Management PIP2

Management entity Console proxy

VNET signaling and control

VNET Operator

VNET Provider

Management PIP1

Management VNP

NYC LondonSpec includespolicy (e.g. pref IP)priceetc.

Management PIP2

VNET Operator

VNET Provider

Management PIP1

Management VNP

NYC LondonSpec includespolicy (e.g. pref IP)priceetc.

Management PIP2

1 2(1) (2) ID

Management PIP1

Management VNP

Management PIP2

London NYC

London

Management PIP1

Management VNP

Management PIP2

London NYC

London

Management PIP1

Management VNP

Management PIP2

London NYC

London

ID.1 ID.2

ID’ ID’’(4)

VNET Provider

Management PIP1

Management VNP

Management PIP2

[ID’.ID.1, console1](5)

console1

VNET operator

VNET Provider

Management IP1

Management VP

Management IP2

console1

console1 console2

[[ID.1,console1];[ID.2, console2]](6)

VNET operator

VNET Provider

Management IP1

Management VP

Management IP2

console1

console1 console2

NYC LondonSpec includespolicy (e.g. pref IP)priceetc.1 2

Lessons learned

r Isolate tasks => business opportunitiesm E.g.: Magnitude of the investment cost

• AT&T plans to invest 17–18 Bn $ in 2009 compared to a revenue of 124 Bn $ in 2008

• Deutsche Telekom plans to invest 8.7 Bn Euro compared to revenues of 62 Bn Euro in 2008

1% is substantial!

rDon’t forget control interfacesr Interprovider issues are trickyr Indirection and resource isolation are great tools

Case study: Locating performance problems

aided by network virtualization

Network debugging: Motivation

rHow do you test an update to the configuration or software of your system?

simulation

?scalable?cheap? accuracy?

testbed

?may be more accurate? but user behavior?? expensive to run? on large scale?? longtime?

Network diagnosis/debugging

r Problem: Implementation/configuration issue surface in large-scale, long-term deployments with real user traffic

r Goal:m Do not change network under testm Avoid probe effect

rDiagnosis methods:m Instrumentationm Regression tests

Instrumentation

Moni Moni

SubstrateVhost

Vhost Vhost

VNET 1Monitoring

r Pair production VNet with monitoring VNetr Copy all/selected packets to monitoring VNetr Processing is accounted to monitoring VNet

Regression testing – Shadow Vnet

V1.1 V1.1

Substrate

V1.0 V1.0

VNet running V1.0

VNet running V1.1

Ctrl Ctrl

Ext 1Ext 2

Control Vnet

Input dist'ed to Vnet 1.0and Vnet 1.1

Output of Vnet 1.0 dist'edto ext entities

Regression testing – Shadow Vnet

r Run VNet1.0, VNet1.1 monitoring VNetr Distribute external input to both VNet1.0 and VNet1.1r Ctrl compares output behavior of VNet1.0 and VNet1.1

for semantic equalityr Only output of VNet1.0 is distributed to external entities

V1.1 V1.1

Substrate

V1.0 V1.0

VNet running V1.0VNet running V1.1

Ctrl Ctrl

Ext 1Ext 2

Control Vnet

Input dist'ed to Vnet 1.0and Vnet 1.1

Output of Vnet 1.0 dist'edto ext entities

Example: VoIP with background load

r Phase 1: Minimal background trafficr Phase 2: Background traffic increasesr Phase 3: Start ShadowVNet: VNET Br Phase 4: Enable QoS in VNET Br Phase 5: VNET B becomes operational

Example: VoIP with background load

r User perceived quality is restored when the ShadowVNet is activated

Lessons learned

r New network debugging featuresm Instrumentationm Regression testsm Distributed debugger

r Goalsm To not change network under testm Avoid probe effect

r Solution: Network virtualizationm Isolationm Accounting of resources

Outline

Case Study: OpenFlow

An exciting new technology for separating hardware and software

OpenFlow – An enabler for open control of the network

rOpenFlow moves control path in each switch/router (middlebox) to an external controller, which makes policy decisions at the flow level (flow is defined by Layer 2, Layer 3 and/or Layer 4 header fields).

rWith OpenFlow, each switch speaks a separate control protocol with an external controller over SSL

Forwarding Table Calculation

Packet Forwarding Engine Traditional

Switch

headerLocal forwarding decision per packet a flow of today consists of 100th of packets

OpenFlow Switch

SecureChannelSecure

Channel SSLsw

OpenFlowSwitch

FlowTableFlowTable

Network Control

Network Control Generic concept

of per flowswitching

Network Control

r Interface between the OpenFlow network and the client enables, e.g., on demandm Constraints on routem Temporary upgrade in service/QoS.

Example service using OpenFlowPer-flow policy and QoS on demand

Controller

OpenFlow devices

QoS/privacy contraints: §Delay < 10ms§Bandwidth > 1Mbps§Not through region X

QoS boost: Increase bandwidth for this specific flow.

Controller

OpenFlow usage – Simple virtualization. Dedicated OpenFlow network.

OpenFlow Switch

Peter’s codePeter’s code

Decision?OpenFlowProtocol

OpenFlow Switch

Peter’s RulePeter’s Rule

Peter’s RulePeter’s Rule Peter’s RulePeter’s Rule

OpenFlow is already supported on routers/switches.

Cisco Catalyst 6k

NEC IP8800

HP Procurve 5400

Juniper MX-series WiMax (NEC)

PC Engines

Quanta LB4G

An OpenFlow based Router

Taking advantage of + OpenSource Routing Software+ Inexpensive Switch Hardware

OpenFlow based router: FIBIUM.Evaluation of open-source routers.

§ ISPs spend significant annual CAPEX for routers etc.§ Currently a quasi-monopoly

vendor market for backbone routers and routers in huge data centers.§ Modularization/standardization of

router components/open-source software may open the market § Similar to Linux§ Industry standards for blade

servers

§ ISPs spend significant annual CAPEX for routers etc.§ Currently a quasi-monopoly

vendor market for backbone routers and routers in huge data centers.§ Modularization/standardization of

router components/open-source software may open the market § Similar to Linux§ Industry standards for blade

servers

Levers and current situation

§ Understand if low cost switches with open-source software can be suitable replacement for high-cost routers.§ Build and evaluate prototype

router using low-cost components and open-source software.

§ Understand if low cost switches with open-source software can be suitable replacement for high-cost routers.§ Build and evaluate prototype

router using low-cost components and open-source software.

Our Approach

The OpenFlow might be a low cost, flexible alternative

OpenFlow based router: FIBIUM.Today’s inflexible routers.

§ Proprietary software§ Limited features customization§ No access to datapath§ Optimized but not programmable

hardware

§ Proprietary software§ Limited features customization§ No access to datapath§ Optimized but not programmable

hardware

Current IP routers§ Carrier-grade open-source based

routers, e.g., Vyatta, IPInfusion, Quagga§ High-performance and inexpensive

Ethernet layer-3 switches with OpenFlowsupport, e.g. HP, NEC, Cisco

§ Carrier-grade open-source based routers, e.g., Vyatta, IPInfusion, Quagga§ High-performance and inexpensive

Ethernet layer-3 switches with OpenFlowsupport, e.g. HP, NEC, Cisco

Observations

OpenFlow based router: FIBIUM.Divide and conquer.

§ Decouple routing and datapath§ Combine inexpensive OpenFlow-

enabled switch with open-source routing software on commodity hardware

§ Decouple routing and datapath§ Combine inexpensive OpenFlow-

enabled switch with open-source routing software on commodity hardware

Principles§ Current switches have sufficient

datapath performance§ Switch control logic is limited§ Current commodity hardware better than

route controllers on routers

§ Current switches have sufficient datapath performance§ Switch control logic is limited§ Current commodity hardware better than

route controllers on routers

Observations

OpenFlow based router: FIBIUM.From concept to reality.

§ Leverages OpenFlow interface of switch:§ RouteVisor programs the switch§ Route cache management ensures

good fast path performance despite limited switch control logic

§ Slow path handled by PC

§ Leverages OpenFlow interface of switch:§ RouteVisor programs the switch§ Route cache management ensures

good fast path performance despite limited switch control logic

§ Slow path handled by PC

FIBIUM§ Ensures that switch and PC combination

appears as a router to the outside world§ Interface between route control

logic on PC and switch§ Collects traffic statistics from switch

and updates data path on switch

§ Ensures that switch and PC combination appears as a router to the outside world§ Interface between route control

logic on PC and switch§ Collects traffic statistics from switch

and updates data path on switch

RouteVisor

OpenFlow based router: FIBIUM.Prototype.

§ Test: 2 HP switches, commercial routers (Cisco and Juniper) and Linux routers§ RouteVisor tasks:

§ Switch configuration§ Handle OSPF and BGP messages§ Route Cache management

§ Test: 2 HP switches, commercial routers (Cisco and Juniper) and Linux routers§ RouteVisor tasks:

§ Switch configuration§ Handle OSPF and BGP messages§ Route Cache management

Test lab

§ Control plane: 100K BGP updates per minute§ Communication channel between PC and

switch: § Traffic statistics: 100K per second§ Switch data path updates: 1000

modifications per second

§ Control plane: 100K BGP updates per minute§ Communication channel between PC and

switch: § Traffic statistics: 100K per second§ Switch data path updates: 1000

modifications per second

Prelim. performance evaluation

Lessons learned

rOpen interface == new opportunitiesr Flexibility of software wins over closed systemsr Example: FIBIUMm Control: Open source routing softwaremData path: Hardware

Rethinking the Internet architecturer Explore alternative architecturesr Approachm Incremental

• Apply point-solutions to the current architecture

m Clean slate design (CSD)• Start from scratch

r Advantage CSDm No limitations: enables rethinking of the network and

service architecturem Architecture not intrinsicm Experiments and failures are possible

CSD: Reshaping the Internetr Impact on users:

m Ease of access to relevant informationm New control plane with new capabilitiesm Easy to introduce new applications with new features

• Security, mobility, quality of service

r Impact of new economic models:m New interfaces between providers (network/service)m New value-chain and new roles for providersm Open interfaces may enable new ecosystems of business alliances

r Impact on society:m Information society

r Impact on operators: m Easier network management

npa10 future internet arch - net.t-labs.tu-berlin.de€¦ · 35 Usenet – NNTP rExchange of...

Documents

Transcript of npa10 future internet arch - net.t-labs.tu-berlin.de€¦ · 35 Usenet – NNTP rExchange of...

Explaining BubbleStorm: Resilient, Probabilistic, and Exhaustive …net.t-labs.tu-berlin.de/teaching/ss09/IR_seminar/talks/... · 2016-08-31 · data list of all peers among them.

Protocols: DNS, TELNET, e-Mail, FTP, WWW, NNTP, SNMP, NTP etc.

Injecting SMS Messages into Smart Phones for Security … · Injecting SMS Messages into Smart Phones for Security Analysis Collin Mulliner

Introduction · Web view Section 1.3: The NNTP Extension server role is supported on Windows 2000 Server and Windows Server 2003. The NNTP Extension client role is supported

Introduction - Microsoft... · Web view[MS-NNTP]: NT LAN Manager (NTLM) Authentication: Network News Transfer Protocol (NNTP) Extension. Intellectual Property Rights Notice for

Anatomy of a Large European IXP - net.t-labs.tu-berlin.de · Part of this work was done while employed at TU Berlin / T-Labs. ACM, 2012. This is the author’s version of the work.

Firewalls and NAT - net.t-labs.tu-berlin.de · Firewalls isolates organization’s internal net from larger Internet, allowing some packets to pass, blocking others. firewall privately

Report from Dagstuhl Seminar 12363 SoftwareDeﬁnedNetworking · Report from Dagstuhl Seminar 12363 SoftwareDeﬁnedNetworking Editedby Pan Hui1 and Teemu Koponen2 1TUBerlin,DE,ben@net.t-labs.tu-berlin.de

SIP and VoIP - net.t-labs.tu-berlin.de · 6 Example: Simple SIP call Alice uses VoIP provider 1 (VP1) as proxy Bob uses VoIP provider 2 (VP2) as proxy Alice sends SIP URI to VP1 via

Ausarbeitung - net.t-labs.tu-berlin.de · Das UPnP-Protokoll beschreibt mehrere Schritte f¨ur den erfolgreichen Netzwerk- betrieb (siehe Abb. 1). Der erste Schritt ist besteht aus

Protokoll-Erkennung - net.t-labs.tu-berlin.de · Protokoll-Erkennung, Andreas Floß, Internet Measurement Seminar. 30.07.2007 11 M3: Common Substring Graphs • Idee: Sessions gleicher

Protocols: DNS, TELNET, e-Mail, FTP, WWW, NNTP, SNMP, NTP etc. Lecture #21: Application Layer.

OSPF (Open Shortest Path First) - net.t-labs.tu-berlin.de file1 OSPF (Open Shortest Path First) “Open”: specification publicly available RFC 1247, RFC 2328 Working group formed

Static Analysis as a Fuzzing Aid - net.t-labs.tu-berlin.destefan/raid17_slidedeck.pdf · RAID’17 | Static Analysis as a Fuzzing Aid Summary In a nutshell, I will tell you Why handwritten

The Need for Collaboration between ISPs and P2Pnet.t-labs.tu-berlin.de/teaching/ss08/IM_lecture/PDF/im08_10_p2p_d... · Benign reasons and malicious reasons ... Detecting IRC-based

Ein generisches IDS/IPS - net.t-labs.tu-berlin.de · WS 2006 / 2007 Seminar Internet Security Ullrich Kresse Ein generisches IDS/IPS Am Beispiel des Münchner Wissenschaftsnetz -

Internet Transport Protocols UDP / TCP - TU Berlin › ... › npa11_03_tcp.pdf · 1 Internet Transport Protocols UDP / TCP Prof. Anja Feldmann, Ph.D . anja@net.t-labs.tu-berlin.de

DOUGLAS ENGELBART · ftp, http, imap, irc, nfs, nntp, ntp, pop3, smb/cifs, smtp, snmp, ssh, telnet, sip,

Cloud Networks - net.t-labs.tu-berlin.denet.t-labs.tu-berlin.de/~stefan/scibo-cloudnets.pdfIntroductionTopicsMigrationResource DescriptionPrototypeDiscussion Cloud Networks A.Feldmann,

Classic TCP/IP applications: TELNET, FTP, SMTP, NNTP and SNMP