1. 1 Lecture 2 – Networking Paradigms University of Nevada – Reno Computer Science & Engineering Department Fall 2015 CS 791 Special Topics: Network Architectures and Economics

2. 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? 3

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? ParadigmBetween Where Unit Circuit-SwitchingEnd-to-EndCircuits Packet-SwitchingHop-to-HopDatagrams/Packets Paradigm 4

5. Tussle Granularity  Temporal  How frequent does the tussle take place?  How “long” is the unit of tussle? ParadigmFrequencyUnit Circuit-SwitchingPer flow/sessionMinutes Packet-SwitchingPer packetMilliseconds Are these two paradigmatic tussle granularities enough to handle current challenges in the Internet? 5

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 6

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 7

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 8

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 9

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? 10

11. Contract-switching: A paradigm shift… Circuit-switching Packet-switching Contract-switching ISP A ISP C ISP B e2e circuits ISP A ISP C ISP B routable datagrams ISP A ISP C ISP B contracts overlaid on routable datagrams 11

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 12

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 Core accessed only by contracts Customers Edge Router Edge Router Edge Router Edge Router Edge Router Edge Router Stations of the provider computing and advertising local prices for edge-to- edge contracts. 13

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 14

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 15

16. Link-State Contract Routing: Macro-level, proactive User X 2 3 5 ISP A ISP C ISP B 1 Owner ISP LinkQoSTermOffered After Price ($/term) A1-210Mb/s2hrs1hr$10 A1-340Mb/s5hrs15mins$80 B2-4100Mb/s3hrs2hrs$110 C3-520Mb/s1hr30mins$8 C4-560Mb/s1day2hrs$250 4 Most cost- efficient route Max QoS route 16

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 ISP A ISP C ISP B 14 [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] path announcement path announcement path announcement 17

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 ISP C ISP B 14 [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 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. reply 18

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. 19

20. Contract-Switching: A generalization  A generalization of packet-switching  A packet is a little contract with a very short duration? ParadigmBetween Where Unit Circuit-SwitchingEnd-to-EndCircuits Packet-SwitchingHop-to-HopDatagrams/Packets Contract-SwitchingEdge-to-EdgeContracts 20

21. 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

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