Presentation is loading. Please wait.

Presentation is loading. Please wait.

Publish/Subscribe Internetworking Transport Abstractions & Congestion Control Somaya Arianfar & Pasi Sarolahti 26.9.2011.

Similar presentations


Presentation on theme: "Publish/Subscribe Internetworking Transport Abstractions & Congestion Control Somaya Arianfar & Pasi Sarolahti 26.9.2011."— Presentation transcript:

1 Publish/Subscribe Internetworking Transport Abstractions & Congestion Control Somaya Arianfar & Pasi Sarolahti

2 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 Outline Congestion History An Information-centric protocol (at the transport layer) -Receiver oriented -Request/response-based model -Pull-based General congestion control issues -Environmental and algorithmic differences -High level PURSUIT approach 2

3 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 Congestion Congestion might happen in the network -When one part of the subnet (e.g. one or more routers in an area) becomes overloaded, congestion results Because routers are receiving packets faster than they can forward them, one of two things must happen: –The subnet must prevent additional packets from entering the congested region until those already present can be processed. –The congested routers can discard queued packets to make room for those that are arriving 3

4 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 Result of Congestion What will occur? Performance degradation Multiple packet loss Low link utilization High queuing delay Congestion collapse Traditionally the role of the TCP to control the congestion 4

5 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 A bit of history TCP & IP RFC 793 & TCP described by Vint Cerf and Bob Kahn In IEEE Trans Comm 1983 BSD Unix 4.2 supports TCP/IP 1984 Nagel’s algorithm to reduce overhead of small packets; predicts congestion collapse 1987 Karn’s algorithm to better estimate round-trip time 1986 Congestion collapse observed 1988 Van Jacobson’s algorithms congestion avoidance and congestion control (most implemented in 4.3BSD Tahoe) BSD Reno fast retransmit delayed ACK’s 1975 Three-way handshake Raymond Tomlinson In SIGCOMM 75 Ref: Aditya Akella, CC presentation

6 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 TCP’s environmental assumptions Upper layer DNS mapping of the other end beforehand -It is known who will serve what Communication abstraction (which affects congestion control): –Reliable –Ordered –Unicast point-to-point –Byte-stream –Full duplex –Flow control Protocol implemented entirely at the ends –Fate sharing 6

7 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 TCP’s congestion control model (The packet conservation principle) Inject packet into network only when one is removed –Sliding window and not rate controlled –But still need to avoid sending burst of packets  would overflow links Need to carefully pace out packets Helps provide stability -One of the reasons Internet is working properly Need to eliminate spurious retransmissions –Accurate RTO estimation 7

8 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 TCP’s sliding window Effective window = max window – (last byte sent – last byte acked) The receiver is returning two parameters to the sender The interpretation is: I am ready to receive new data with SeqNo= AckNo, AckNo+1, …., AckNo+Win-1 Receiver can acknowledge data without opening the window Receiver can change the window size without acknowledging data 8

9 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 Network TCP’s algorithmic assumptions Lost or out-of-order packets signs of congestion Slow down enough till the congested part gets empty RTT dependent algorithm -The wait time is window_max/ (2.C) == 1 * RTT 9 Transport ClientServer

10 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 TCP’s Congestion control 10 Transport Network Transport Network Ack packet Data packet ClientServer A retrofit design without modularity No assumption on the network side All the functionality and notifications at the end- point

11 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 The E2E Request/Response Model (ICN based) 11 Transport Network Transport Network Request packet Response packet RequesterResponder CPU Memory Bandwidth Packet-based content granularity Request/response similar to data/Ack Similar set of resources as today

12 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 The ICN environment in PURSUIT No pre-identified connection end-point -Merged lookup and forwarding Every forwarding node can: -Interpret request and response packets -Cache/reuse packets (content-items) 12

13 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 Network The ICN-based request/response model Any one can respond to a content request -No primarily assigned unicast point-to-point -Not ordered Not all responses traverse the same path (different RTTs) -window_max/ (2.C) != 1 * RTT 13 Transport RequesterResponder

14 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 Ease environmental assumptions Support innovation and extensibility (only for CC) Control loop elements -Reaction point (RP) Keeps the state -Feedback point (FP) Reports to the reaction point -Midpoint (MP) Adds information to the reports P ATHLET : BLOCK OF THE PATH BETWEEN ANY TWO MIDPOINTS, OR MIDPOINT AND THE FEEDBACK / REACTION POINT 14

15 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 A congestion control framework A control loop is defined between a RP and a FP At least one identifiable pathlet between the RP and the FP Midpoint’s roles -Responsible for the downstream pathlet -Reports the supported algorithm by the pathlet -Negative and positive feed backing (resource availability reporting) 15

16 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 Pathlet MP Pathlet 1Pathlet 2Pathlet 3 Network The RP/FP/MP model 16 Transport RequesterResponder FP & MP RPFP Network Transport ClientServer FPRP

17 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 The PURSUIT context Pathlet-based identifiers in each packet Resource availability reporting in each packet Reaction point at the subscriber -Uses best possible algorithm -No interference with other algorithms Ease the assumption on: -Unicast point-to-point -Specific algorithm 17

18 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 Negative feed backs (Explicit Congestion Marking) Implicit congestion indication -Use packet drop to indicate congestion -source infer congestion implicitly ECN -Traditionally to give less packet drop and better performance -Use packet marking rather than drop -Needs co-operation between sources and network -Needs extra bits in the header 18

19 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 Explicit Congestion Marking E.g. Explicit wait time at the end-point matches the RTT of the ECN marked packet 19 Network Transport FPRP MP P = Current queue size/ threshold ECN marking

20 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 Positive feed backs: e.g. XCP, RCP, etc. Ease the assumption on: -Ordered delivery -Dropped packets as sign of congestion 20 Network Transport FPRP MP ~ Available bandwidth/ #flows

21 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 Packet structure in PURSUIT 21 FIDRID/PIDCongestion info Other fields Payload

22 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 Other approaches Based on the TCP logic everything is flow based Smart-market [Mackie-Mason 1995] –A price is set for each packet depends on the level of demand for bandwidth –Admit packets with bid prices that exceed the cut-off value –The cut-off is determined by the marginal cost Paris metro pricing (PMP) [Odlyzko] –To provide differentiated services –The network is partitioned into several logical separate channels with different prices –With less traffic in channel with high price, better QoS would be provided. 22

23 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 Re-feedback Re-ECN is a low level architectural enabler -designed to solve an information visibility problem 23 Bob Briscoe, Re-ECN, IETF 75

24 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 Open issues Is Congestion still the same? -The role of cache memory in router Fairness -Per flow -Per user -Per packet Separation of reliability and Congestion control -The proper RTO estimation Other thoughts… 24

25 Publish/Subscribe Internetworking Transport & Congestion Control © Somaya Arianfar 2011 Summary TCP’s congestion control -A retrofit to the existing design -Implicit congestion signs -Mixed with reliability and fairness PURSUIT and ICN context -Different assumptions compared to TCP -Pathlet-based model -Explicit feed baking -Still open issues 25

26 Questions? Thanks! Publish/Subscribe Internetworking Transport & Congestion Control Somaya Arianfar,


Download ppt "Publish/Subscribe Internetworking Transport Abstractions & Congestion Control Somaya Arianfar & Pasi Sarolahti 26.9.2011."

Similar presentations


Ads by Google