Download presentation
Presentation is loading. Please wait.
Published byArthur Jones Modified over 9 years ago
1
February 2005Proprietary Content1 The Role of PCE in the Evolution of Transport Protocols Pfldnet 2005, Lyon, France M. Y. “Medy” Sanadidi http://www.cs.ucla.edu/~medy http://www.cs.ucla.edu/NRL/hpi/tcpw/
2
February 2005Proprietary Content2 Recent Issues in Transport Protocols Large Pipes Utilization Steady state Start-up Impact of Wireless Links: Last-hop wireless Multihop contention networks Fairness for asymmetric flows Protocols Co-Existence New Paradigms: Voice/Video Store-and-forward at Transport layer (e.g. PEPs, P2P/Overlays)
3
February 2005Proprietary Content3 Example: Satellite/802.11 Networks
4
February 2005Proprietary Content4 Outline Path Characteristics Estimation (PCE) Prospects for Higher Efficiency Future of Friendly Co-Existence Addressing the New Paradigms Summary
5
February 2005Proprietary Content5 Path Characteristics Estimation (PCE) Characteristics of Interest: Links capacity Path ‘dynamic range’, i.e. buffering capacity Cross traffic level, path-persistence, responsiveness Random loss Multihop wireless connectivity, contention, route diversity Participating Nodes: Sources only Sources and Destinations Forwarding nodes (routers, base stations, multihop wireless nodes)
6
February 2005Proprietary Content6 Sharing a Link Flow2 Flow1 2 flows, red one is non- responsive fair share ? bandwidt h residual bandwidth bottleneck interface queue backlog Buffer space Propagation Time
7
February 2005Proprietary Content7 A Hierarchy of Characteristics Achieved rate Delay/Dynamic Range Packet loss Intensity Path persistence Elasticity Links capacities Propagation times Buffer space Errors Cross Traffic Load Architecture Flow Behavior +
8
February 2005Proprietary Content8 Path Capacity Estimation Path Capacity: capacity of narrow link Pathrate: rely on packet pair dispersion measurements followed by statistical processing of results CapProbe: use dispersion measurements; perform on line filtering of results based on end-to-end delay TcpProbe: an adaptation of CapProbe into TCP with minimal sender side only changes
9
February 2005Proprietary Content9 DelAck TCP Probe: CapProbe: CapProbe and TcpProbe
10
February 2005Proprietary Content10 Prospects for Higher Efficiency Steady State: Congestion avoidance (FAST): stable at high throughput, co-existence ??, and random loss impact ?? Scaling up congestion recovery (HSTCP, STCP): higher throughput, but fairness and stability ?? Scaling up congestion recovery (BIC): improves on the above in fairness Forwarder Based (XCP): superb, when we are done with implementation issues PCE reliance (TCP Westwood, TCP Peach): Peach requires forwarder priority support, TCPW requires good estimation at high speeds
11
February 2005Proprietary Content11 Using PCE Tahoe/Reno/NewReno estimate: Packet loss via Dup Acks RTT average and variance Maintain a pipe size (or bandwidth-delay product) estimate: ssthresh Vegas/FAST: Achieved Rate and its relation to the Expected Rate, or equivalently RTT and RTTmin, or Queuing delay HSTCP/STCP/BIC: Use current window size (Expected Rate) in addition to all items above in Reno
12
February 2005Proprietary Content12 Using PCE (2) TCPW estimates Packet loss and type of loss Narrow link capacity, or Path capacity Achieved Rate “Dynamic Range” resulting from buffering space: (RTTmax-RTTmin) XCP measures at forwarders the actual: Links capacities Load intensity RTT (obtained from sources)
13
February 2005Proprietary Content13 Large Pipes Measurements Results
14
February 2005Proprietary Content14 Acceptable Long Term Efficiency
15
February 2005Proprietary Content15 Some Difference in Completion Times
16
February 2005Proprietary Content16 Co-Existence at Gbps Speed
17
February 2005Proprietary Content17 Random Loss Impact
18
February 2005Proprietary Content18 Effect of Random Loss
19
February 2005Proprietary Content19 TCPW: Mining ACK Streams for PCE Rely on PCE ( e.g. capacity, achieved rate, dynamic range) to determine an Eligible Rate Estimate (ERE) ERE is used to size the congestion window after a packet loss Receiver Sender Internet Bottleneck packets ACKs measure
20
February 2005Proprietary Content20 TCPW BE (2001) BE Sampling : With Saverio Mascolo (P. Bari) and Claudio Casetti (P. Torino) ~ Packet pair a noisy estimate of achieved rate/capacity Provides throughput boost under random loss, overestimates under congestion Efficient but not friendly TkTk
21
February 2005Proprietary Content21 TCPW RE (2002) TkTk RE Sampling : ~ Packet train Fair estimate under congestion, underestimates under random loss Used in TCPW RE and inTCP Westwood+ (S. Mascolo) Friendly
22
February 2005Proprietary Content22 Adaptive Estimation in TCPW TCPW CRB: ERE BE if random loss, else ERE RE TCPW ABSE: ERE RE <X < BE by continuously adapting the bandwidth sample width to congestion level TCPW Astart: use ERE to help short lived flows TCPW BBE: ERE u * C + (1-u) * RE, where u is a congestion measure taking into account path dynamic range
23
February 2005Proprietary Content23 TCPW CRB (2002) Combined “Rate” and “Bandwidth” Binary adaptive Congestion measure: Expected Rate/Achieved Rate Clarified Efficiency/Friendliness tradeoff Congestion measure Packet Loss Detected ssthresh, cwnd = BE x RTT min over a threshold under a threshold Binary adaptation Ssthresh, cwnd = RE x RTT min
24
February 2005Proprietary Content24 TCPW ABSE (2002) Under Congestion Under No Congestion TkTk TkTk Adaptive Bandwidth Share Estimation Adapt the sample interval T k according to congestion level Congestion measure, similar to Vegas T k ranges from one ‘interACK’ interval to current RTT Better Efficiency/Friendliness profile than CRB
25
February 2005Proprietary Content25 Helping Short Lived Connections Approaches: Cached ssthresh Larger initial window PCE based: Hoe’s; TCPW Astart Negotiation: Quick-Start No problems here for XCP!
26
February 2005Proprietary Content26 TCPW Astart (2003) Take advantage of ERE : Adaptively and repeatedly reset ssthresh ERE until sender window reaches estimated pipe size, or encounters packet loss 420 430 440 450 460 470 480 490 500 510 1.61.71.81.922.12.2 cwnd in packets Time (sec) Linear increase phases Exponential increase phases cwnd Includes multiple mini ‘exponential increase’, and mini ‘linear increase’ phases cwnd grows slower as it approaches BDP Connection converges faster to its pipe size with less buffer overflow, since it adapts to pipe size and transient loading
27
February 2005Proprietary Content27 Astart: First 20 Seconds Throughput RTT =100ms, Buffer =BDP RTT =100ms, Bottleneck =40 Mbps Bottleneck capacity = 40 Mbps, Buffer =BDP Good scaling with capacity and propagation time Robust to buffer size variation
28
February 2005Proprietary Content28 TCPW BBE (Work in Progress) With H. Shimonishi (NEC, Tokyo) “Buffer” and “Bandwidth” Estimation Estimates Capacity using TcpProbe (much more accurate than BE!!) Higher efficiency at higher random loss rates (e.g. 5- 10%) Estimates Dynamic Range (related to buffer size) Improves TCPW control as a function of congestion The result is higher efficiency and robust friendliness even at small buffers!
29
February 2005Proprietary Content29 TCPW BBE Algorithms (ICC 2005) Dynamic Range estimate D max = RTT cong loss - RTT min Current Delay Distance D = RTT – RTT min RTT before packet loss Relative Frequency RTT cong_loss RTT min Congestion loss Random loss Eligible Rate estimate ERE = u * C + (1-u) * RE Note: u=0 if D and D max are small
30
February 2005Proprietary Content30 Opportunistic Friendliness of TCPW-BBE If Reno under-perform: use all the opportunity provided without hurting co-existing Reno flows TCP-Reno Sender Receiver 10M-1Gbps TCPW-BBE Sender 0.001% loss Receiver RTT 40msec If Reno performs: achieve similar to Reno
31
February 2005Proprietary Content31 The Future of Friendly Co-Existence Defining Friendliness: TCP Friendliness: Achieve throughput equal to that of TCP Reno under some conditions (RTT, packet loss rate) Problematic if Reno under-perform; e.g. under random losses Opportunistic Friendliness: If Reno performs, achieve similar to Reno If Reno under-perform: use all the opportunity provided without hurting co-existing Reno flows
32
February 2005Proprietary Content32 Evaluating a New Proposed Protocol: The Efficiency/Friendliness Profile Each point in the graph is obtained as follows: N legacy flows => legacy throughput t R1 total utilization U 1 N/2 legacy, N/2 proposed flows => legacy throughput t R2 Total utilization U 2 Efficiency Improvement E = U 2 / U 1 Friendliness F = t R2 / t R1
33
February 2005Proprietary Content33 E/F Profiles of TCPW BE, CRB and ABSE
34
February 2005Proprietary Content34 E/F Profile of Vegas 1 1.1 1.2 1.3 1.4 1.5 0.40.60.811.21.4 Utilization Ratio G (Efficiency) Throughput Ratio L (Friendliness) N=2 N=4 N=8 N=16 N=24 Vegas vs. NewReno (RED) Vegas uses fixed targeted queue length => varying friendliness depending on number of connections!
35
February 2005Proprietary Content35 Addressing New Paradigms Audio/Video Streaming: Increasing portion of the total traffic with distinct requirements Multihop Wireless: Difficult fundamental issues Store-and-forward at the Transport Layer: Revisit early problems and new opportunities
36
February 2005Proprietary Content36 Continuous Media Transport Requirements: Minimum bandwidth Upper bound on delay Lower reliability requirements than in FTP Adaptive streaming objectives: Delivered quality Congestion control Support for adaptive coding
37
February 2005Proprietary Content37 Addressing Continuous Media Issues Issues with the standard protocols: UDP: no congestion or error control TCP: AIMD behavior undesirable due to fluctuation in rate, and consequently delay, and intolerance to random loss DCCP provides an excellent framework, recommends TFRC as one possible protocol, but allows for alternatives TFRC is equation based, rate-equivalent to Reno, with smoother delivery suitable for streaming SCTP enables multiple streams with different congestion control mechanisms, among other features
38
February 2005Proprietary Content38 Streaming Over Wireless Under random loss, Reno and its rate-equivalent TFRC, will both under-perform Approaches, some with loss discrimination, have been proposed: TFRC Wireless: Combination of loss discrimination schemes, Multi-TFRC Multiple TFRC connections until link is congested VTP Rate estimation and loss discrimination
39
February 2005Proprietary Content39 Performance Comparison Efficiency in presence of errors 5% error rate, single connection Rate adaptation 5% error rate, single connection with on/off CBR cross traffic
40
February 2005Proprietary Content40 TCP over Multihop Wireless Packet losses due to: Contention due to hidden terminals Varying channel quality Route collapse Buffer overflow ?? Solution approaches: Neighborhood RED Delayed ACK extension Sizing the TCP window for contention reduction
41
February 2005Proprietary Content41 Store & Forward at the Transport Layer Overlays/P2P tunneling through TCP connections PEPs breaking ETE path into concatenated TCP connections, e.g. satellites New(?) Requirements: Buffer management and priority schemes for better ETE application protocol performance TCP Receiver advertised window role Related item: Prioritized TCP for QOS at the Transport layer (TCP-LP, TCPW-LP)
42
February 2005Proprietary Content42 Summary Excellent progress by many approaches for scaling efficiency with pipe size Focus on PCE techniques is promising, e.g. TCPW provides: Scalable efficiency Robustness to random loss Tunable opportunistic friendliness Streaming, multihop wireless, and forwarding at the Transport layer to receive attention and make good progress
43
February 2005Proprietary Content43 Steady State Characteristics (TCPW RE) For small loss rate, TCPW has much larger window than NewReno. More scalable!
44
February 2005Proprietary Content44 Fairness (TCPW RE) For small loss rate, TCPW is more fair than NewReno
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.