Re-thinking the Control Architecture of the...

Re-thinking the Control Architecture of the Internet

Mark Handley

University College London

Fiber, Cat 5, wireless

Ethernet, WiFi, etc

IP

TCP, UDP, SCTP

SMTP, HTTP, RTP

The Data Plane

The Internet Stack

RTCP

BGP OSPF

MPLS-TE

RSVP RSVP-TE

LDP ARP L2TP

PPP ICMP ICMPv6 IGMP

MLD

IS-IS

DNS

MIP

Shim6 DHCP

SIP SDP NTP SNMP

NetConf

RIP PIM-SM PIM-DM

PWE3

IKE

PCN

RADIUS Diameter

IPsec MPLS

The Control Plane

IGRP

LEAP

MGCP SLP EAP

GRE

GSMP

STUN TURN

ICE

The Internet Control Architecture

Routing

  Find best route that complies with policy Congestion Control

  Match offered load to available capacity Traffic Engineering

  Tune routing policies, establish peerings, provision links, QoS.

Security   Access control, authentication


Routing

Congestion Control

Traffic Engineering

Medium Timescales

Long Timescales

Short Timescales


Routing

Congestion Control

Traffic Engineering

BGP Policies

Deep packet inspection, Traffic shaping

Not much at all


Routing

Congestion Control

Traffic Engineering

DDoS Attacks

Congestion Control


Routing

Congestion Control

Traffic Engineering


Routing

Traffic Engineering

Congestion Control Load

balancing of multihomed sites

The Internet Control Architecture was not a carefully planned separation of functionality, but an accumulation of fixes to specific problems.

Congestion Control (in TCP)

  Late addition by Jacobson et al., 1988. Policy Routing (EGP, BGP)

  Late addition by Rekhter et al., 1989 onwards.

Traffic Engineering   No explicit design prior to mid 1990s   Rise of multihoming not foreseen by CIDR, 1993.


Ethernet, WiFi, etc

IP

TCP, UDP, SCTP

SMTP, HTTP, RTP

The Data Plane

The Internet Stack

RTCP

BGP OSPF

MPLS-TE

RSVP RSVP-TE

LDP ARP L2TP


MLD

IS-IS

DNS

MIP

Shim6 DHCP

SIP SDP NTP SNMP

NetConf

RIP PIM-SM PIM-DM

PWE3

IKE

PCN

RADIUS Diameter

IPsec

The Control Plane

IGRP

LEAP

MGCP SLP EAP

GRE

GSMP

STUN TURN

ICE

INCREMENTAL FIXES

The Power of Legacy

(Pictures courtesy NASA, Darlington Railway Centre)

Network Effect

Metcalfe’s Law:   The utility of a

telecommunications network grows with the square of the number of users.

Picture by Derrick Coetzee


Ethernet, WiFi, etc

IP

TCP, UDP, SCTP

SMTP, HTTP, RTP

The Data Plane

The Internet Stack

RTCP

BGP OSPF

MPLS-TE

RSVP RSVP-TE

LDP ARP L2TP


MLD

IS-IS

DNS

MIP

Shim6 DHCP

SIP SDP NTP SNMP

NetConf

RIP PIM-SM PIM-DM

PWE3

IKE

PCN

RADIUS Diameter

IPsec

The Control Plane

IGRP

LEAP

MGCP SLP EAP

GRE

GSMP

STUN TURN

ICE

INCREMENTAL FIXES Evolution by random mutation and natural selection?

You are here

You are here

Is it possible to change the Internet architecture in a planned way,

so as to achieve long-term goals?

(or is it only possible to patch the pieces repeatedly until it gets too expensive and unreliable, and eventually something better comes

along and replaces it?)

Spectrum of Networking Research

Cool Hot

Incremental improvement

Blue-sky research

Slow death by a thousand fixes

Undeployable due to network

effects

Possibility to effect planned change


Cool Hot


Blue-sky research

Slow death by a thousand

fixes


effects


Cool Hot


Blue-sky research

Slow death by a

thousand fixes


effects

Poss. to

effect planned change

Opportunities to change the game

Routing

Congestion Control

Traffic Engineering

Nearly impossible to replace BGP. Huge network effect.

Nearly impossible to replace TCP. Must co-exist with TCP congestion control, etc

Wish List for Control Mechanisms

  Very high robustness,   Minimal impact from failures, no downtime.   Resists attack.

  Load-dependent routing,   Move traffic away from congestion   Scalable to billions of multihomed mobile nodes

  Diverse traffic mix,   Even for as yet unforeseen applications and protocols.

  Sane economics,   Reward network operators for investment.

This talk: opportunities to change the game…

Routing

Congestion Control

Traffic Engineering

The problem of multihoming

Routing

Traffic Engineering

Congestion Control Load

balancing of multihomed sites

Edge links exposed via BGP for fast

recovery

Stresses routing and doesn’t solve the problem well.

Multihoming and Redundancy

  Multihoming does provide redundancy.

But routing isn’t a good way to access that redundancy.

  Can we access this redundancy better in other ways?

  In particular, can we access it at the transport layer, where congestion control can see it?

Smartphone

Mobile client Server

Wifi

3G celltower

Multi-homed server

Client

Server

Load balances between access links

Stripe data from one connection across both paths.

Sending simultaneously across more than one path can provide robustness. ��

If any path dies, TCP can detect it immediately and switch all traffic to the working path.

Client

Server

Sending simultaneously across more than one path can balance load and pool resources.

Each path runs its own congestion control, to detect and respond to the congestion it sees.

But link the congestion control parameters, so as to move traffic away from the more congested paths.

[Kelly & Voice, Key, Massoulie & Towsley]

be less aggressive

be more aggressive

MP-TCP allows a set of disparate links to behave just as if they were a single pooled resource.

The ARPAnet pooled link resources rather than using circuits.

Multipath TCP pools multiple link resources.

ARPAnet resource pooling:

Multipath resource pooling:

Linking the subflows allows a set of disparate links to behave just as if they were a single pooled resource.

This talk: opportunities to change the game…

Routing

Congestion Control

Traffic Engineering

Multipath transport

Economics

  Very roughly, the cost of using the Internet is composed of two parts: Access: giving you the possibility to send.

Usage: based on what you send and when you send it.

What is the marginal cost of a packet?

  If no-one else wanted to send at that time, there is no cost imposed on anyone from sending a packet.

  It only makes sense to charge for usage if that traffic displaces another user’s traffic.   Hence we should be charging for congestion.

Common current charging models

  Rate-based charging.   Eg. charge for 95% percentile rate used.

  Volume-based charging.   x gigabytes/month volume cap (then some penalty)

These are rough proxies for the real marginal cost:   They don’t have the right incentives to cause better user or

application behaviour.   They’re inefficient - more efficient players will do better

Example: some applications are latency sensitive, some only care about long-term throughput.

time

b/w

BitTorrent

Windows Update Web page

download

Current incentive model

time

b/w

Incentives when charging for congestion volume

Charging for congestion volume encourages machine-to-machine traffic to move to uncongested times.

  Users probably won’t change their behaviour.

  Want to watch TV at peak time.

  But a lot of apps are flexible in when they send.

  And even the interactive ones may be able to get creative with prefetching, etc.

The missing mechanism

  ISPs can’t charge for congestion, because they can’t see it properly.   End-system can see it.

  Router that drops packets has some idea.

  No-one else can see the big picture, so there’s no framework to pass on the costs of congestion.

Congestion Exposure��(general term for Bob Briscoe’s re-feedback, re-ECN, etc)

  Indicate to an ISP the congestion seen by traffic downstream of them.

Congested Links

Feedback: x packets saw congestion

Downstream congestion Upstream congestion

Congestion Exposure is an enabler for sane economics.

  Allows everyone forwarding packets to see the cost those packets will impose on the downstream networks.   Enables a network-neutral response that differentiates

traffic based on its real cost.   Encourages well-behaved applications.   Needs to be some pass-on of the cost to customers for

them to prefer well-behaved applications.   Lots of potential for innovation here.

Opportunities to change the game…

Routing

Congestion Control

Traffic Engineering

Multipath transport

Congestion exposure

Changing the Game: Potential Outcomes

Multipath transport moves traffic away from congested paths onto uncongested paths.

Congestion exposure encourages well-behaved applications that move traffic from congested times to uncongested times.

  Between the two, the network can be much more robust, cope with much wider ranges of load, and better handle the demanding applications of tomorrow.

Re-thinking the Internet Control Architecture.

Routing

Congestion Control

Traffic Engineering

  By taking a holistic view of control, we can enable whole new degrees of freedom.

  By working with existing protocols we can do this in a way that stands some chance of being deployed.


Cool Hot


Blue-sky research

Slow death by a thousand fixes


effects

Possibility to effect planned change

Don’t neglect phase two of

your research!

Thanks

Especially to:   Damon Wischik   Costin Raiciu   Bob Briscoe   Phil Eardley

  Lars Eggert   Sebastian Barre   Alan Ford   Marcelo Bagnulo

Multipath TCP: http://nrg.cs.ucl.ac.uk/mptcp/

Re-thinking the Control Architecture of the...

Documents

Transcript of Re-thinking the Control Architecture of the...