1 Lecture 2 – Networking Paradigms University of Nevada – Reno Computer Science &...

1

Lecture 2 – Networking Paradigms

University of Nevada – RenoComputer Science & Engineering Department

Fall 2015

CS 791 Special Topics:Network Architectures and Economics

2

Outline

Tussle Granularity

Contract-Switching

3

Tussle Granularity Tussle:

“a physical contest or struggle”, www.m-w.com

Effects everything else designed on it

A way of expressing “value”

Does it have to be “physical”?

How about economic tussle in the net?

4

Tussle Granularity Spatial

Where on the network is involved in the tussle? Where are the entities tussling with each other? How “large” is the unit of tussle?

Paradigm Between Where

Unit

Circuit-Switching

End-to-End Circuits

Packet-Switching

Hop-to-Hop Datagrams/Packets

Paradigm

5

Tussle Granularity Temporal

How frequent does the tussle take place? How “long” is the unit of tussle?

Paradigm Frequency Unit

Circuit-Switching

Per flow/session

Minutes

Packet-Switching

Per packet Milliseconds

Are these two paradigmatic tussle granularities enough to handle current

challenges in the Internet?

6

Tussle Granularity: Value Economic granularity?

How flexible is it to express your Willingness-to-pay Value of the data/bit

Current: only at the access level all application traffic is treated the same (except VoIP,

which requires extra payments)

Paradigm

7

Tussle Granularity: Trust Security granularity?

How flexible is it to express your sense of Security of the data Privacy of your ID

Always tradeoffs Too private: cannot track criminals (e.g. anonymizers) No privacy: 911 calls possible

Paradigm

8

Tussle Granularity: Trust Are you comfortable with sending your financial

information over WiFi links? Do you “trust” the network? Or do you just no trust the WiFi link? Can you express this to the network provider?

Trust levels: Can we quantify?

If not quantifiable, can it be part of the paradigm or even architecture?

Paradigm

9

Implied Challenges

Tussle Granularity: Edge-to-Edge

Some of the current architectural problems: Users cannot express

value choices at sufficient granularity – only at access level

Providers do not have economic knobs to manage risks involved in

• investing innovative QoS technologies and

• business relationships with other providers

flexibility in time:forward/option pricing

flexibility in space:user-defined inter-domain

routes

capability to provide e2e higher quality services

money-back guarantees, risk/cost sharing

10

Inter-domain struggles…

When crossing domains, all bets are off..

End-to-end reliability or performance-criticality requires assurance of single-domain performance, i.e., “contract”s efficient concatenation of single-domain contracts

Inter-domain routing needs to be aware of economic semantics contract routing + risk management

How to address translation of these struggles to architectural problems?

11

Contract-switching: A paradigm shift…

Circuit-switching

Packet-switching

Contract-switching

ISPA

ISPC

ISPB

e2e circuits

ISPA

ISPC

ISPB routable

datagrams

ISPA

ISPC

ISPB contracts

overlaid on routable datagrams

12

A Contract-Switched Network Core

Contracts: a practical way to manage “value flows”

Technologies to Support QoS

Economic considerations for service definition and delivery Scalability, Efficiency

and Fairness Contract timescales Cost recovery Pricing the risk in QoS

guarantees Single-domain and

end-to-end contracts

13

Basic Building Block: Intra-domain dynamic contracts

Contract components performance component, e.g.,

capacity financial component, e.g., price time component, e.g., term

Network Coreaccessed onlyby contracts

Cu

stom

ers

EdgeRouter

EdgeRouter

EdgeRouter

EdgeRouter

EdgeRouter

EdgeRouter

Stations of the provider computing

and advertising local prices for edge-to-

edge contracts.

Stations of the provider computing

and advertising local prices for edge-to-

edge contracts.

14

Contract Link

An ISP is abstracted as a set of “contract links”

Contract link: an advertisable contract between peering/edge

points i and j of an ISP with flexibility of advertising

different prices for edge-to-edge (g2g) intra-domain paths

capability of managing value flows at a finer

granularity than point-to-anywhere deals

15

Can we achieve e2e QoS? Contract Routing:

Compose e2e inter-domain “contract paths” over available contract links satisfying the QoS requirements

Calculate the contract paths by shortest-path algos with metrics customized w.r.t. contract QoS metrics

Two ways: link-state contract routing at macro time-scales path-vector contract routing at micro time-scales

Monitor and verify that each ISP involved in an e2e contract path is doing the job

Punish the ISPs not doing their job, e.g. as a money-back guarantee to the others involved in the e2e contract path

16

Link-State Contract Routing: Macro-level, proactive

User X

2

3

5

ISPA

ISPC

ISPB

1

OwnerISP

Link

QoS Term

OfferedAfter

Price($/term)

A 1-2 10Mb/s 2hrs 1hr $10

A 1-3 40Mb/s 5hrs 15mins $80

B 2-4 100Mb/s

3hrs 2hrs $110

C 3-5 20Mb/s 1hr 30mins $8

C 4-5 60Mb/s 1day 2hrs $250

4

Most cost-efficient route

Max QoS route

17

Path-Vector Contract Routing: Micro-level, on-demand, reactive

Provider initiates… ISP C wants to

advertise availability of a short-term contract link

User X

2

3

5

ISPA

ISPC

ISPB

1 4

[C, 5-4, 30Mb/s,

45mins, $9]

[C-B, 5-4-2, 20Mb/s, 45mins, $6+$5]

[C-B-A, 5-4-2-1, 20Mb/s, 30mins, $7.3+$3]

[C, 5-3, 10Mb/s, 30mins, $5]

[C-A, 5-3-1, 5Mb/s, 15mins, $1.25+$1.2]

pathannouncement

path

announcement pathannouncement

18

Path-Vector Contract Routing: Micro-level, on-demand, reactive

User initiates… User X wants to know if it can

reach 5 with 10-30Mb/s for 15-45mins in a $10 budget

User X

2

3

5

ISP A

ISPC

ISPB

1 4

[5, A-B, 1-2-4, 15-20Mb/s, 20-30mins, $4]

[5, A, 1-2, 15-30Mb/s, 15-30mins, $8]

[5, 10-30Mb/s, 15-45mins, $10]

[5, A, 1-3, 5-10Mb/s, 15-20mins, $7]

Paths to 5 are found and ISP C sends replies to the user with

two specific contract-path-vectors.

path requestpath request

path request

[A-B-C, 1-2-4-5, 20Mb/s, 30mins]

[A-C, 1-3-5, 10Mb/s, 15mins]

Paths to 5 are found and ISP C sends

replies to the user with two specific contract-

path-vectors.

replyreply

reply

19

Deployment Issues

How to motivate ISPs to participate? ISPs are very protective of their contracting

terms – due to competition.• But, BGP has similar risks too..• Observation of opportunity costs

PVCR can be done at will..• Not much to loose if ISPs participate with their

leftover bandwidth.

Monitoring and verification of contracts Who is breaking the e2e performance? Active measurements can be OK for LSCR,

but PVCR needs lightweight techniques.

20

Contract-Switching: A generalization

A generalization of packet-switching A packet is a little contract with a very short duration?

Paradigm Between Where

Unit

Circuit-Switching End-to-End Circuits

Packet-Switching Hop-to-Hop Datagrams/Packets

Contract-Switching

Edge-to-Edge Contracts

1-21

Lecture 2: Summary Tussle Granularity

Temporal Spatial Economic

Contract-Switching Edge-to-edge Contract as a unit of tussle Potential to offer end-to-end QoS services Value and risk management at fine-enough granularity

1-22

Lecture 2: Reading Clark, Wrocklawski, Sollins, and Braden, Tussle in

Cyberspace: Defining Tomorrow's Internet, IEEE/ACM Transactions on Networking, 2005.

Yuksel, Gupta, and Kalyanaraman, Contract-Switching Paradigm for Internet Value Flows and Risk Management, IEEE Global Internet Symposium, 2008. (also in Ramamurthy, Rouskas, and Sivalingam, Chapter 7)