+ All Categories
Home > Documents > Resource Pooling and the Trilogy Project · BGP traffic engineering slow, manual process to pool...

Resource Pooling and the Trilogy Project · BGP traffic engineering slow, manual process to pool...

Date post: 09-Jul-2020
Category:
Upload: others
View: 1 times
Download: 0 times
Share this document with a friend
12
Resource Pooling and the Trilogy Project Lars Eggert (with thanks to Mark Handley, Damon Wischik and Marcelo Bagnulo) The IEEE 22 nd Annual Computer Communications Workshop (CCW) Steamboat Springs, CO, USA October 22-24, 2008
Transcript
Page 1: Resource Pooling and the Trilogy Project · BGP traffic engineering slow, manual process to pool resources across peering links OSPF/MPLS traffic engineering slow, mostly manual process

Resource Pooling and the Trilogy Project

Lars Eggert (with thanks to Mark Handley, Damon Wischik and Marcelo Bagnulo)

The IEEE 22nd Annual Computer Communications Workshop (CCW) Steamboat Springs, CO, USA October 22-24, 2008

Page 2: Resource Pooling and the Trilogy Project · BGP traffic engineering slow, manual process to pool resources across peering links OSPF/MPLS traffic engineering slow, mostly manual process

Develop a unified control architecture for the Future Internet that can adapt in a scalable, dynamic and robust manner to local operational and business requirements

Develop and evaluate new technical solutions for key Internet control elements: reachability & resource control

Assess commercial and social control aspects of our architecture & technical solutions, including internal & external strategic evaluation

2008-10-23 Lars Eggert | © Nokia 2008 1

load-dependent multi-path traffic

engineering

re-feedback

reachability mechanisms

resource control business

Funded by the EU under FP7 for 3 years (2008-10)

Total volume: 9.15M€ EU: 5.82M€

~60 person-years total

http://www.trilogy-project.eu/

congestion control

topology discovery, reachability

routing policy

economic drivers

Page 3: Resource Pooling and the Trilogy Project · BGP traffic engineering slow, manual process to pool resources across peering links OSPF/MPLS traffic engineering slow, mostly manual process

The architectural requirements have changed

we need a more robust Internet than we can get from simply making better components

traditional routing can’t solve this in a scalable way

applications are becoming more demanding (VoIP, TV, Games)

most of the end-systems will be mobile, with multiple radios that can be used simultaneously

2008-10-23 Lars Eggert | © Nokia 2008 2

Page 4: Resource Pooling and the Trilogy Project · BGP traffic engineering slow, manual process to pool resources across peering links OSPF/MPLS traffic engineering slow, mostly manual process

Resource pooling

make a network's resources behave like a single pooled resource

aim is to increase reliability, flexibility and efficiency

method is to build mechanisms for shifting load between the various parts of the network

6 Mb/s

10 Mb/s

10 Mb/s

10 Mb/s

6

6

4

8

2

10

Srca

Srcb

Srcc

Dsta

Dstb

Dstc

2008-10-23 3 Lars Eggert | © Nokia 2008

Page 5: Resource Pooling and the Trilogy Project · BGP traffic engineering slow, manual process to pool resources across peering links OSPF/MPLS traffic engineering slow, mostly manual process

Resource pooling is not new…

Routing

BGP traffic engineering slow, manual process to pool resources across peering links

OSPF/MPLS traffic engineering slow, mostly manual process to pool resources across internal ISP links

BT, AT&T and others dynamic alternative routing

Elsewhere

multi-homing pool reliability & capacity

Google, Akamai, CDNs pool reliability & bandwidth

BitTorrent pool capacity & reliability

2008-10-23 4 Lars Eggert | © Nokia 2008

Theoretical foundations

Kelly and Voice

Key, Massoulié and Towsley

Page 6: Resource Pooling and the Trilogy Project · BGP traffic engineering slow, manual process to pool resources across peering links OSPF/MPLS traffic engineering slow, mostly manual process

Resource pooling for the Internet

multipath only real way to get robustness is redundancy

multi-homing, via multiple addresses can aggregate routing information

mobility, via adding and removing addresses no need to involve the routing system or use non-aggregatable addresses

2008-10-23 Lars Eggert | © Nokia 2008 5

Page 7: Resource Pooling and the Trilogy Project · BGP traffic engineering slow, manual process to pool resources across peering links OSPF/MPLS traffic engineering slow, mostly manual process

Approach

multipath-capable transport layers use multiple subflows within transport connections congestion control subflows independently traffic moves to the less congested paths

note: the involvement of congestion control is crucial link the back-off parameters for stability and fairness (Kelly+Voice) you can’t solve this problem at the IP layer

moves some of the stresses out of the routing system might be able to converge slowly and no-one cares

eventually, routing system should expose in-network multipath availability, so single-homed end systems benefit

2008-10-23 6 Lars Eggert | © Nokia 2008

Page 8: Resource Pooling and the Trilogy Project · BGP traffic engineering slow, manual process to pool resources across peering links OSPF/MPLS traffic engineering slow, mostly manual process

Multipath transport

multipath transport allows multiple links to be treated as a single pooled resource

traffic moves away from congested links

larger bursts can be accommodated

ARPAnet resource pooling:

multipath resource pooling:

2008-10-23 7 Lars Eggert | © Nokia 2008

Page 9: Resource Pooling and the Trilogy Project · BGP traffic engineering slow, manual process to pool resources across peering links OSPF/MPLS traffic engineering slow, mostly manual process

Resource pooling allows a wider range of traffic matrices

Srcb Dsta

Dstb

100Mb/s

100Mb/s

100Mb/s

100Mb/s

Srca

Flow

a

(Mb/

s)

Flow b (Mb/s)

possible bandwidth consumption

100

100 Fl

ow a

Flow b (Mb/s)

possible bandwidth consumption

100

100

Flow

a

Flow b (Mb/s)

possible bandwidth consumption

100

100

no multi-path flows only flow a is multi-path both flows are multi-path

2008-10-23 8 Lars Eggert | © Nokia 2008

Page 10: Resource Pooling and the Trilogy Project · BGP traffic engineering slow, manual process to pool resources across peering links OSPF/MPLS traffic engineering slow, mostly manual process

Multipath traffic engineering

Balancing across dissimilar speed links

Balancing across dissimilar cost links

Dst

Src

Dst

Src

Add congestion

marking $$$

2008-10-23 9 Lars Eggert | © Nokia 2008

Page 11: Resource Pooling and the Trilogy Project · BGP traffic engineering slow, manual process to pool resources across peering links OSPF/MPLS traffic engineering slow, mostly manual process

End-systems can optimize globally (often ISPs cannot)

A C

B A

C

B ISP1 ISP2

X Y Z

2008-10-23 10 Lars Eggert | © Nokia 2008

Page 12: Resource Pooling and the Trilogy Project · BGP traffic engineering slow, manual process to pool resources across peering links OSPF/MPLS traffic engineering slow, mostly manual process

Where are we today?

good theoretical understanding of the issues (past work by others) Kelly and Voice; Key, Massoulié and Towsley

Trilogy is working on the details for TCP & BGP how well does this work in practice? are there cases where multipath does worse? how much of the traffic engineering problems does this solve? how much remains to be done in routing? how to manage such dynamic networks?

(Trilogy is also investigating other topics)

http://www.trilogy-project.eu/

2008-10-23 11 Lars Eggert | © Nokia 2008


Recommended