Publish/Subscribe Internetworking Transport Abstractions & Congestion Control

1. Publish/Subscribe Internetworking Transport Abstractions & Congestion Control SomayaArianfar & PasiSarolahti 26.9.2011

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

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

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

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

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

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

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

9. TCP’s algorithmic assumptions Client Server • 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 Transport Transport Network Network

10. TCP’s Congestion control • A retrofit design without modularity • No assumption on the network side • All the functionality and notifications at the end-point Client Server Transport Data packet Transport Ack packet Network Network

11. The E2E Request/Response Model (ICN based) Requester Responder Transport Request packet Transport Response packet Network Network CPU Memory Bandwidth Packet-based content granularity Request/response similar to data/Ack Similar set of resources as today

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

13. The ICN-based request/response model Requester Responder • Any one can respond to a content request • No primarily assigned unicastpoint-to-point • Not ordered • Not all responses traverse the same path (different RTTs) • window_max/ (2.C) != 1 * RTT Transport Transport Responder Responder Network Network

14. 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 • Pathlet: block of the path between any two midpoints, or midpoint and the feedback/reaction point

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

16. The RP/FP/MP model Client Server FP RP Transport Transport Pathlet MP MP Network Network Requester Responder RP FP Transport Transport FP & MP FP & MP Network Network Pathlet 2 Pathlet 3 Pathlet 1

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

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

19. Explicit Congestion Marking • E.g. Explicit wait time at the end-point matches the RTT of the ECN marked packet FP RP Transport Transport MP MP MP MP Network Network ECN marking P = Current queue size/ threshold

20. Positive feed backs: e.g. XCP, RCP, etc. • Ease the assumption on: • Ordered delivery • Dropped packets as sign of congestion FP RP Transport Transport MP MP MP MP Network Network ~ Available bandwidth/ #flows

21. Packet structure in PURSUIT FID Congestion info RID/PID Other fields Payload

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

23. Re-feedback • Re-ECN is a low level architectural enabler • designed to solve an information visibility problem Bob Briscoe, Re-ECN, IETF 75

24. 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…

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

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