Publish/Subscribe Internetworking Transport Abstractions & Congestion Control

Publish/Subscribe Internetworking Transport Abstractions & Congestion Control

Somaya Arianfar & Pasi Sarolahti26.9.2011

Publish/Subscribe InternetworkingTransport &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



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



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



A bit of history

5

1975 1980 1985 1990

1982TCP & IP

RFC 793 & 791

1974TCP described by

Vint Cerf and Bob KahnIn IEEE Trans Comm

1983BSD Unix 4.2

supports TCP/IP

1984Nagel’s algorithmto reduce overhead

of small packets;predicts congestion

collapse

1987Karn’s algorithmto better estimate

round-trip time

1986Congestion

collapseobserved

1988Van Jacobson’s

algorithmscongestion avoidance and congestion control(most implemented in

4.3BSD Tahoe)

19904.3BSD Renofast retransmitdelayed ACK’s

1975Three-way handshake

Raymond TomlinsonIn SIGCOMM 75

Ref: Aditya Akella, CC presentation



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



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



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

AckNo window size(win)

32 bits 16 bits



NetworkNetwork

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

TransportTransport

Client Server



TCP’s Congestion control

10

Transport

Network

Transport

NetworkAck packet

Data packet

Client Server

• A retrofit design without modularity• No assumption on the network side• All the functionality and notifications at the end-

point



The E2E Request/Response Model (ICN based)

11

Transport

Network

Transport

Network

Request packet

Response packet

Requester Responder

CPUMemoryBandwidthPacket-based content granularity

Request/response similar to data/AckSimilar set of resources as today



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



NetworkNetwork

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

TransportTransport

Requester Responder

ResponderResponder



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

14



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



PathletMPMP

Pathlet 1 Pathlet 2 Pathlet 3

NetworkNetwork

The RP/FP/MP model

16

TransportTransport

Requester Responder

FP & MPFP & MP

RP FP

NetworkNetwork

TransportTransport

Client ServerFP RP



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



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



Explicit Congestion Marking

• E.g. Explicit wait time at the end-point matches the RTT of the ECN marked packet

19

NetworkNetwork

TransportTransportFP RP

MPMP MPMP

P = Current queue size/ thresholdECN marking



Positive feed backs: e.g. XCP, RCP, etc.

• Ease the assumption on:- Ordered delivery- Dropped packets as sign of congestion

20

NetworkNetwork

TransportTransportFP RP

MPMP MPMP

~ Available bandwidth/ #flows



Packet structure in PURSUIT

21

FID RID/PIDCongestion info

Other fields

Payload



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



Re-feedback• Re-ECN is a low level architectural enabler

- designed to solve an information visibility problem

23

Bob Briscoe, Re-ECN, IETF 75



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



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

Questions?

Thanks!


Somaya Arianfar, 201126

Publish/Subscribe Internetworking Transport Abstractions & Congestion Control

Documents

Transcript of Publish/Subscribe Internetworking Transport Abstractions & Congestion Control