Publish/Subscribe Internetworking Transport Abstractions & Congestion Control Somaya Arianfar & Pasi...
-
Upload
katherine-hincks -
Category
Documents
-
view
213 -
download
0
Transcript of Publish/Subscribe Internetworking Transport Abstractions & Congestion Control Somaya Arianfar & Pasi...
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
Publish/Subscribe InternetworkingTransport &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
Publish/Subscribe InternetworkingTransport &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
Publish/Subscribe InternetworkingTransport &Congestion Control
© Somaya Arianfar 2011
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
Publish/Subscribe InternetworkingTransport &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
Publish/Subscribe InternetworkingTransport &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
Publish/Subscribe InternetworkingTransport &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
AckNowindow size
(win)32 bits 16 bits
Publish/Subscribe InternetworkingTransport &Congestion Control
© Somaya Arianfar 2011
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
Publish/Subscribe InternetworkingTransport &Congestion Control
© Somaya Arianfar 2011
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
Publish/Subscribe InternetworkingTransport &Congestion Control
© Somaya Arianfar 2011
The E2E Request/Response Model (ICN based)
11
Transport
Network
Transport
Network
Request packet
Response packet
Requester Responder
CPUMemoryBandwidth
Packet-based content granularityRequest/response similar to data/AckSimilar set of resources as today
Publish/Subscribe InternetworkingTransport &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
Publish/Subscribe InternetworkingTransport &Congestion Control
© Somaya Arianfar 2011
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
Publish/Subscribe InternetworkingTransport &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
• PATHLET: BLOCK OF THE PATH BETWEEN ANY TWO MIDPOINTS, OR MIDPOINT AND THE FEEDBACK/REACTION POINT
14
Publish/Subscribe InternetworkingTransport &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
Publish/Subscribe InternetworkingTransport &Congestion Control
© Somaya Arianfar 2011
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
Publish/Subscribe InternetworkingTransport &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
Publish/Subscribe InternetworkingTransport &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
Publish/Subscribe InternetworkingTransport &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
NetworkNetwork
TransportTransport
FP RP
MPMP MPMP
P = Current queue size/ thresholdECN marking
Publish/Subscribe InternetworkingTransport &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
NetworkNetwork
TransportTransport
FP RP
MPMP MPMP
~ Available bandwidth/ #flows
Publish/Subscribe InternetworkingTransport &Congestion Control
© Somaya Arianfar 2011
Packet structure in PURSUIT
21
FID RID/PIDCongestion info
Other fields
Payload
Publish/Subscribe InternetworkingTransport &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
Publish/Subscribe InternetworkingTransport &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
Publish/Subscribe InternetworkingTransport &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
Publish/Subscribe InternetworkingTransport &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
Questions?
Thanks!
Publish/Subscribe InternetworkingTransport &Congestion Control
Somaya Arianfar, 201126