Review & intRoduction
tcP FRiendly PRotocols & congestion contRol
RAP: An end-to-end RAte-bAsed congestion contRol MechAnisM FoR ReAltiMe stReAMs in the inteRnet by RezA RejAie et Al. Also discussion on otheR ARticles
Rahat
outline
RFID & Discussion on Papers
outline The TCP Concept Congestion Control Mechanisms Single-rate Protocols Multi-rate Protocols
The RAP Paper RAP: Basic Idea RAP Architecture A few details
Some Other Discussion & Reference
the tcP concePt
inteRnet & FRoM 5000/6000 level couRse
tcP-FRiendly behAvioR “The growth of TCP is larger than expected”
The Internet has recently been experiencing an explosive growth in the use of audio and video streaming. Such applications are delaysensitive, semi-reliable and rate-based. Thus they require isochronous processing and quality-of-service (QoS) from the end-to-end point of view. End-to-end congestion control mechanisms have been critical to the robustness and stability of the Internet. Most of today’s Internet traffic is TCP, and we expect this to remain so in the future. Thus, having “TCP-friendly” behavior is crucial for new applications. However, the emergence of non-congestion-controlled realtime applications threatens unfairness to competing TCP traffic and possible congestion collapse.
whAt is tcP? TCP: Transport Layer Protocol – The way the majority of data on the Internet is passed around – Web pages, file transfers, chat programs – Used because its reliable and fair
One TCP connection Packets sent / second
•
Congestion Max Bandwidth
Time (seconds)
whAt is tcP? TCP: Transport Layer Protocol – The way the majority of data on the Internet is passed around – Web pages, file transfers, chat programs – Used because its reliable and fair
A second TCP connection Packets sent / second
•
Congestion Max Bandwidth
Time (seconds)
whAt is udP? UDP: User Datagram Protocol – The way video and audio streams are passed around – No congestion control, thus not fair – Not reliable at all
One Innocent TCP connection Packets sent / second
•
Congestion
Max Bandwidth
Time (seconds)
whAt is udP? UDP: User Datagram Protocol – The way video and audio streams are passed around – No congestion control, thus not fair – Not reliable at all
A Mean UDP Connection Comes In Packets sent / second
•
Max Bandwidth
Innocent TCP Connection
Time (milliseconds)
why wAsn’t this An issue beFoRe? • Lots of unused bandwidth (not anymore) • Little number of users (not anymore) • Video streams? Audio Streams? Who’ll use it? (Cable/DSL increased the demand)
UDP
TCP
the iMPoRtAnce oF being tcPFRiendly • Since the majority of the Internet uses TCP, other protocols must behave fairly towards it • A protocol is TCP-Friendly if its “long-term throughput does not exceed the throughput of a conformant TCP connection under the same conditions” • Thus, UDP is out of the picture
A tcP-FRiendliness equAtion
• • • • •
Calculates estimated TCP throughput (packets/second) lact is the ‘actual packet loss fraction’ of TCP packets tRTT is the TCP round trip time t0 is the TCP timeout value Source: Padhye et al.
AlteRnAtive solution: dcP • Datagram Control Protocol – Variable reliability • Reliable for initial connection rate negotiations • No guarantees on other data
– Congestion Control Mechanisms • each direction of flow gets to choose what kind of congestion control they wish to use • The algorithms used for most congestion control mechanisms ensure TCP-friendliness
– Lightweight, like UDP
Also congestion contRol • New research has come up with better ways of detecting and dealing with congestion • TFRC: TCP-Friendly Rate Control – When packet is lost in TCP, throughput fluctuates a lot – TFRC attempts to alleviate this, while maintaining TCP-friendliness
• TEAR: TCP Emulation At Receivers – Claims that it will be more TCP-friendly than TFRC
congestion contRol MechAnisMs Lack of support for QoS has not prevented rapid growth of realtime streaming applications and this is expected to continue. Many of these applications playback stored video or audio for a client over the network. Examples include continuous media servers, digital libraries, distant learning and shopping. These playback clients can afford to slightly delay the playback point and buffer some data to partially absorb variation of the network bandwidth and end-to-end delay - Hence came Congestion Control
congestion contRol Algo Congestion control is not a new topic and a large body of work has accumulated describing various mechanisms. However, the critical work for TCP-friendly congestion control mechanism in best-effort networks is somewhat more limited.
Congestion control algorithms prevent the network from entering Congestive Collapse. Congestive Collapse is a situation where, although the network links are being heavily utilized, very little useful work is being done
whAt is congestion The state of sustained network overload Congestion collapse Traffic dominated by overhead such as packet retransmissions
Current internet
Dominated by best-effort traffic TCP for guaranteed delivery; Congestion-aware UDP for streaming applications; Congestion-unaware
Packets sent / second
Two TCP connection Max Bandwidth
Congestion
Time (seconds)
contRolling congestion • End-hosts – Advantages: cheap, scalable – Disadvantage: requires cooperation
• Routers – Advantages: can be more aggressive, has a complete picture of network traffic – Disadvantages: expensive, algorithms difficult to implement in hardware
tcP congestion contRol • Implemented at end hosts • Relies on feedback – Implicit: packet drops indicate congestion – Explicit: ECN flags in header
• Congestion controlled by changing window size: additive increase, multiplicative decrease (AIMD) • Problem: delays in adapting to network conditions may cause oscillations
RouteR-bAsed contRol •
Scheduling – Determines service order – Should be easy to implement, provide fairness and protection, and perform well
•
Scheduling algorithms – FIFO (first in, first out) – Round-robin / weighted round-robin – Weighted fair queuing
•
Buffer Management – Absorbs bursts – Shared/per-flow – Introduce delay
•
Queue Management – Manage queue length, decide what packets to drop – RED effective, but difficult to parameterize for variable conditions
tcP-FRiendly congestion contRol • TCP-friendly: long-term throughput does not exceed that of TCP under the same conditions TCP-friendly CM protocol
Avg Rate
TCP
•Motivation: want to stream data such as audio and video without degrading overall network performance •For convenience, consider long-lasting streams
congestion contRol scheMes • Rate-based vs. Window-based • Unicast vs. Multicast • End-to-end vs. Router-supported
single-RAte vs. Multi-RAte • • •
Meaningful when considering multicast Single-rate sends data to each client at the same rate Multirate sends data to each client at whatever rate is best for that client
Separate transmissions must “share” bandwidth: slower receivers still “take” bandwidth from faster
R S
1
R 2
R R
3
S
1
R
R 4
2
single-RAte PRotocols
RAte-bAsed APPRoAches • RAP – Rate Adaptation Protocol (We will discuss in detail later) – Simple AIMD behavior
• LDA+ – Loss-Delay Based Adaption Algorithm – Dynamic AIMD based on RTCP feedback
• TFRC – TCP-Friendly Rate Control Protocol – Adjusts sending rate based on complex TCP equation
• TEAR – TCP Emulation at Receivers – Uses a congestion window to determine rate, but averages over larger timescales
window-bAsed APPRoAches • RLA – Random Listening Algorithm – Tracks number n of congested receivers, window is decreased if a random number is ≤ 1/n
• MTCP – Multicast TCP – Arrange receivers in a tree, children report congestion to parents. – Root receives aggregate info, sends only as much data as smallest window
• NCA – Nominee-Based Congestion Avoidance – Selects bottleneck as representative receiver, uses TCP-style congestion control algorithm
Multi-RAte PRotocols
RAte-bAsed APPRoAches • RLC – Receiver-Driven Layered Congestion Control – Bandwidth consumed by each layer increases exponentially – Subscription to additional layers comes at particular times, which also increase exponentially; however congestion causes immediate layer drops
RAte-bAsed APPRoAches • FLID-DL – Fair Layered Increase/Decrease with Dynamic Layering – Encodes data with digital fountain – Bandwidth consumed by a layer decreases over time
• LTS/TFRP – Layered Transmission Scheme/TCP-Friendly Transport Protocol – Use simple TCP rate equation to decide subscription level
MldA And RAinbow • MLDA – Multicast Loss-Delay Based Adaption Algorithm (ratebased) – Same as LDA+, but performs rate calculation at receiver
• Rainbow (window-based) – Encode data with digital fountain – Receivers individually request packets based on individual windows
the RAP PAPeR RAP: An end-to-end RAte-bAsed congestion contRol MechAnisM FoR ReAltiMe stReAMs in the inteRnet by RezA RejAie et Al.
RAte AdAPtAtion PRotocol PAPeR • RAP: An End-to-end Rate-based Congestion Control Mechanism for Realtime Streams in the Internet • A Well known paper from 99 and used very hugely for research as well as practical purposes.
About the AuthoRs
Mark Handley Reza Rejaie Associate Professor Dept. of Computer and Information Science University of Oregon Reza Rejaie's research interests includes peer-to-peer networks, multimedia networking, network measurement, congestion control and content distribution networks.
Deborah Estrin Director, Center for Embedded Networked Sensing (CENS) Professor, UCLA Computer Science Department Professor Estrin received the National Science Foundation, Presidential Young Investigator Award for her research in network interconnection and security. During the subsequent 10 years much of her research focused on the design of network and routing protocols
Professor of Networked Systems. Royal Society-Wolfson Research Merit Award Holder Professor Handley's research interests include the Internet architecture, congestion control (how to match the load offered to a network to the changing available capacity of the network), Internet routing, etc.
RAP & its goAl In this paper, the Authors presented an end-to-end TCP-friendly Rate Adaptation Protocol (RAP), which employs an additiveincrease, multiplicativedecrease (AIMD) algorithm. It is well suited for unicast playback of realtime streams and other semireliable rate-based applications. Its primary goal is to be fair and TCP-friendly while separating network congestion control from application-level reliability.
RAP & its goAl The authors also evaluate RAP through extensive simulation, and conclude that bandwidth is usually evenly shared between TCP and RAP traffic. Unfairness to TCP traffic is directly determined by how TCP diverges from the AIMD algorithm. Basic RAP behaves in a TCP friendly fashion in a wide range of likely conditions, but they devised a fine-grain rate adaptation mechanism to extend this range further. Finally, they show that deploying RED queue management can result in an ideal fairness between TCP and RAP traffic.
FoRewoRds • MM is delay sensitive, semi-reliable, rate-based – Not in Internet
• Still MM apps have grown – Those typically allow larger delay (ex: VoD) – So can do buffering to remove variance
• Must react to congestion in TCP-Friendly fashion
ReseARch APPRoAch • Separate congestion control from error and quality control • RAP module – Congestion control via AIMD (converges to fair) – Congestion detection vial loss (ECN possible) – Order of RTT
• Layer manager – Quality control – Layer manager (maximum layers to fit bwidth) – Less than RTT by buffering
• (RAP module primary in this paper)
RAP ARchitectuRe
This paper concentrates on RAP module
the RAP PRotocol • RAP “machinery” mainly at source – Receiver acks each packet – Sender calculates stuff (loss and RTT)
• Each ACK packet contains sequence number of corresponding delivered data packet • From ACKs, RAP source can detect losses and sample RTT • Sender must have: – Decision function – Increase/Decrease algorithm – Decision frequency
decision Function • No congestion then periodically increase rate • Congestion then immediately decrease rate – Gaps and timeouts
• Acks have more than just last sequence – Can send back ‘holes’ to avoid responding to single loss events
incReAse/decReAse AlgoRithM • Uses AIMD • Change inter-packet gap (IPG) – – – –
Smaller gap then higher rate Larger gap then lower rate Step-wise decrease on no congestion Double on congestion
decision FRequency •
Change rate no more than 1 per RTT – Step “length” is RTT
•
Then, if “height” is 1 packet – Emulate TCP during congestion avoidance
• •
RAP emulates the coarse-grain rate adjustment of TCP RAP is unfair to flows with longer RTT as TCP
•
Special cases: – Clustered losses – Fine-grain rate adaptation – RED gateways
clusteRed losses • Packets lost together are part of same congestion signal • SeqfirstLoss is first packet lost • SeqlastSent is last one sent • Ignore – SeqlastSent > seq > SeqfirstLoss
• Similar to TCP SACK
Fine-gRAin RAte AdAPtAtion • Keep long term RTT and short-term RTT • IPG is based on short-term RTT • IPG’ is based on ratio of long-term to short-term – Use it to adjust rate
RAndoM eARly detection gAtewAys
• TCP has trouble with multiple losses in a row in one window – Drop Tail queues – TCP times-out to window size of 1 – RAP goes down exponentially
• RED distributes losses – Also smaller queue sizes (hopefully) – Wants 1 loss for each flow for each RTT
• With RED, RAP should be totally fair to TCP • Configuring RED still difficult – Major topic of CC meetings
evAluAtion by siMulAtion • • • •
TCP-friendliness Ability to cope with background traffic Interaction with RED gateways Fine-grain rate adaptation
soMe outcoMes thRough siMulAtion • RAP is in general TCP-friendly, even without fine-grain rate adaptation • The more TCP diverges from AIMD, the less bandwidth it obtains • RAP compared to TCP-SACK to avoid TCP’s inherent performance problems • Measure inter-protocol fairness: ratio of average RAP bandwidth to average TCP bandwidth • Resources scaled linearly with number of flows to maintain share per flow fixed and operate TCP in its well-behaved mode • Varying number of flows and RTT
soMe outcoMes thRough siMulAtion • For a wide range of RTT, increasing number of flows improves fairness (ratio converges to 1) • Not true for small RTT (or small pipe size) due to the small size of TCP’s congestion window • Fine-grain rate adaptation prevents RAP flows from overshooting the available bandwidth share • Thus, reducing loss for TCP flows and improving fairness • RED, if configured correctly (i.e. maxP not too large or too small), improves fairness between RAP and TCP
lAst woRds on the RAP PAPeR The authors goal was to develop an end-to-end TCP-friendly RAP for semi-reliable rate-based applications (e.g. playback of realtime streams). It has been used very hugely for research as well as practical purposes. It also •Rate-based •Reasonably Fair to TCP - Unfair when TCP not AIMD (timeout) •More Fair when RED gateway
soMe otheR discussion ReFeRence inteRnet & FRoM otheR PAPeR, ARticles
otheR notAble views Cheng Jin, David Wei and Steven Low had published called “ FAST TCP� at Caltech Infocom, March 2004. The authors agreed with the argument : Delay-based approach is better than loss-based approach as it is - Multi-bit information compared to one-bit - Earlier detection of impending congestion - More frequent feedback possible
But the authors talked about some Deployment Issues In their view A proposal should have incremental deployment characteristic. Lot of excellent proposals have not seen the day of light because of this. Examples: TCP-Vegas, SACK, Multicast. Etc. They also tacked about Explicit Congestion Notification (ECN)
otheR views TCP Vegas: It is a TCP congestion control, or network congestion avoidance, algorithm that emphasizes packet delay, rather than packet loss, as a signal to help determine the rate at which to send packets. TCP Tahoe: Loss is detected when a timeout expires before an ACK is received. Tahoe will then reduce congestion window to 1 MSS, and reset to slow-start state. TCP Reno: If three duplicate ACKs are received (i.e., three ACKs acknowledging the same packet, which are not piggybacked on data, and do not change the receiver's advertised window), Reno will halve the congestion window, perform a "fast retransmit", and enter a phase called Fast Recovery. If an ACK times out, slow start is used as it is with Tahoe.
otheR notAble views TCP is not so aggressive as It is expected. – Slow start phase of TCP can make packet loss, jitter and out of order packets of UDP stream. • But if there are not many TCP connections in slow start phase concurrently, packet loss rate is not high and jitter is not big.
– Congestion avoidance phase do not make much impact on UDP stream. – TCP connections makes not much impacts on UDP streams if the link is not heavily over loaded (100 TCP connections per second and average several tens megabyte data size). Joonbok Lee of KAIST “Impacts of TCP on the high bandwidth digital video stream” 2004.6.9
otheR notAble views Internet friendly transport-level protocol (IFTP) • The authors proposed a design of an IFTP for media streaming whose goal is to contribute to the good health of the Internet and avoid starving other good behaving protocols like TCP. notable
– a simple extension that allows offering QoS-differentiated services to selected connections. – Compute tight upper bounds of the amount of bandwidth that IFTP may be able to claim from TCP – less packet loss, delay and delay jitter than UDP
Hala El Aarag and Mostafa Bassiouni “An Internet friendly transport protocol for continuous media over best effort networks”
IJCS 2002
otheR notAble views Streaming video delivery over the Internet Video Adaptation Techniques
Dynamic Video Rate Control (DVRC) – Their proposed technique
Simulcast Delivery of multiple video streams encoded at different bit-rates Client switches to a stream version depending on the available bandwidth Introduces bandwidth redundancy Layered Adaptation Base layer (low-quality decodable video) Enhancement layers (progressively refine quality) Client receives the base layer and optionally a number of enhancement layers
• • • • •
is an end-to-end protocol for adaptive video flows operates on top of UDP does not provide reliability directly adapts the quality/rate of the outgoing video stream encapsulates header information to allow the manipulation of video streams
Panagiotis Papadimitriou and Vassilis Tsaoussidis
COMNET Group, http://comnet.ee.duth.gr/comnet “A Rate Control Scheme for Adaptive Video Streaming over the Internet” ICC 2007
otheR notAble views
"Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks�
This paper is really good for long distance network. Firstly, it presents RTT fairness as an important safety condition for high-speed congestion control and raise an issue that existing protocols may have a severe problem in deployment due to lack of RTT fairness under drop tail. RTT fairness has been largely ignored in designing high-speed congestion control. Second, this paper presents a new protocol that can support RTT fairness, TCP friendliness, and scalability.
Injong Rhee, Lisong Xu Congestion Control on High-Speed Networks
North Carolina State University
INFOCOM 2004
bic: high-sPeed netwoRks
"Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks” NewYork ABILENE ABILENE
UK UK SuperJANET4 It
It GARR-B STARLIGHT GEANT
ESNET ESNET
GENEVA
NL NL SURFnet
STAR-TAP
CALREN CALREN
Fr Fr Renater Many high-speed networks are being developed. BW: 10Gbps, and expected to be upgraded to higher speeds in the near future.
Injong Rhee, Lisong Xu Congestion Control on High-Speed Networks INFOCOM 2004
bic: esnet (eneRgy science netwoRk)
"Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks” NewYork ABILEN ABILEN EE
UK UK SuperJANET4 It
It GARR-B STARLIGHT GEANT
GENEVA
NL NL SURFnet
STAR-TAP
ESNET ESNET ESNET ESNET
CALRE CALRE NN
Fr Fr Renater ESNet is funded by the Department of Energy to provide a highspeed network serving thousands of scientists worldwide
Injong Rhee, Lisong Xu Congestion Control on High-Speed Networks INFOCOM 2004
bic: high-sPeed APPlicAtion
"Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks�
Applications Weather Simulation Video Conference
Telemedicine
Transport Protocols be able to transfer a large amount of data over a long distance within a short amount of time
High-Speed Networks Injong Rhee, Lisong Xu Congestion Control on High-Speed Networks INFOCOM 2004
bic: tcP congestion contRol
"Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks”
• •
The instantaneous throughput of TCP is controlled by a variable cwnd, TCP transmits approximately a cwnd number of packets per RTT (Round-Trip Time).
cwnd = cwnd + 1 Packet loss
Packet loss
cwnd = cwnd * (1-1/2) Packet loss
Packet loss
TCP
cwnd
Slow start
Congestion avoidance
Time (RTT) Injong Rhee, Lisong Xu Congestion Control on High-Speed Networks INFOCOM 2004
bic: tcP oveR high-sPeed netwoRks
"Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks” A TCP connection with 1250-Byte packet size and 100ms RTT is running over a 10Gbps link (assuming no other connections, and no buffers at routers)
1.4 hours
1.4 hours
slow Packet lossincrease Packet loss cwnd
100,000
Packet loss
TCP
Packet loss
10Gbps
big decrease
50,000
Slow start
1.4 hours
5Gbps
Congestion avoidance
Time (RTT) Injong Rhee, Lisong Xu Congestion Control on High-Speed Networks INFOCOM 2004
bic: PRoPosed high-sPeed PRotocols
"Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks” • Window-Based Protocols
– AIMD (Additive Increase Multiplicative Decrease) • Jumbo Frame, GridFTP, PFTP, PSockets – HSTCP (High-Speed TCP) by Sally Floyd at ICIR, Berkeley – STCP (Scalable TCP) by Tom Kelly at Cambridge University – FAST (Fast AQM Scalable TCP) by Steven Low at California Institute of Technology
• Rate-Based Protocols – SABUL (Simple Available Bandwidth Utilization Library ) by Robert Grossman at University of Illinois at Chicago window-based protocols are known for safer incremental deployment. D. Bansal, H. Balakrishnan, S. Floyd, and S. Shenker, "Dynamic behavior of slowly responsive congestion controls", In Proceedings of SIGCOMM 2001, San Diego, California.
Injong Rhee, Lisong Xu Congestion Control on High-Speed Networks INFOCOM 2004
bic:
AiMd (Additive incReAse MultiPlicAtive decReAse) "Binary AIMD Increase Congestion Control (BIC)say for32,Fast Long-Distance increases cwnd by a larger number, instead of 1 per RTT. Networks� After a packet loss, AIMD decreases cwnd by 1/8, instead of 1/2
cwnd = cwnd + 1
cwnd = cwnd * (1-1/2)
cwnd = cwnd + 32
cwnd = cwnd * (1-1/8)
Packet loss
Packet loss
Packet loss
Packet loss
TCP
cwnd
Slow start Congestion avoidance
Time (RTT) Injong Rhee, Lisong Xu Congestion Control on High-Speed Networks INFOCOM 2004
bic: stcP (scAlAble tcP)
"Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks� STCP adaptively increases cwnd, and decreases cwnd by 1/8.
cwnd = cwnd + 1
cwnd = cwnd * (1-1/2)
cwnd = cwnd + 0.01*cwnd
cwnd = cwnd * (1-1/8)
Packet loss
Packet loss
Packet loss
Packet loss
TCP
cwnd
Slow start Congestion avoidance
Time (RTT) Injong Rhee, Lisong Xu Congestion Control on High-Speed Networks INFOCOM 2004
bic: hstcP (high-sPeed tcP)
"Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks� HSTCP adaptively increases cwnd, and adaptively decreases cwnd. The larger the cwnd, the larger the increment, and the smaller the decrement
cwnd = cwnd + 1
cwnd = cwnd * (1-1/2)
cwnd = cwnd + inc(cwnd)
cwnd = cwnd * (1-dec(cwnd))
Packet loss
Packet loss
Packet loss
Packet loss
TCP
cwnd
Slow start Congestion avoidance
Time (RTT) Injong Rhee, Lisong Xu Congestion Control on High-Speed Networks INFOCOM 2004
bic:
ResPonse Functions oF tcP, AiMd, hstcP And
stcP "Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks� Bandwidth Scalable
1.0E+06 TCP AIMD
HSTCP and STCP are both bandwidth scalable and TCP friendly
Throughput (Mbps)
1.0E+05
HSTCP STCP
1.0E+04
1.0E+03
1.0E+02
1.0E+01 1.0E-07
1.0E-06
1.0E-05
1.0E-04
1.0E-03
1.0E-02
Packet Loss Probability
TCP Friendly Injong Rhee, Lisong Xu Congestion Control on High-Speed Networks INFOCOM 2004
bic: design goAl
"Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks� 1.0E+06
Scalability, RTT Fairness
TCP AIMD HSTCP STCP BIC
Throughput (Mbps)
1.0E+05
1.0E+04
1.0E+03
1.0E+02
1.0E+01 1.0E-07
1.0E-06
1.0E-05
1.0E-04
1.0E-03
1.0E-02
Packet Loss Probability
TCP Fairness Injong Rhee, Lisong Xu Congestion Control on High-Speed Networks INFOCOM 2004
bic: binARy incReAse congestion contRol
"Binary BIC Increase Congestion Control (BIC) for Fast Long-Distance Networks� adaptively increase cwnd, and decrease cwnd by 1/8 cwnd = cwnd + 1
cwnd = cwnd * (1-1/2)
cwnd = cwnd + f(cwnd, history)
cwnd = cwnd * (1-1/8)
Packet loss
Packet loss
Packet loss
Packet loss
TCP
cwnd
Slow start Congestion avoidance
Time (RTT) Injong Rhee, Lisong Xu Congestion Control on High-Speed Networks INFOCOM 2004
bic: Rtt FAiRness
"Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks”
Throughput ratio of two flows with different RTTs on a 2.5Gbps link
Inverse RTT Ratio
1
3
6
BIC
1
12
38
AIMD
1
6
22
HSTCP
1
29
107
STCP
1
127
389
Simulation setup: BDP Buffer, Drop Tail, Reverse Traffic, Forward Background Traffic (short-lived TCP, Web Traffic)
Injong Rhee, Lisong Xu Congestion Control on High-Speed Networks INFOCOM 2004
bic: siMulAtion suMMARy
"Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks”
Scalability TCP-Friendliness RTT Fairness
AIMD
HSTCP
STCP
BIC
√ × √
√ √ ×
√ √ ×
√ √ √ Injong Rhee, Lisong Xu
Congestion Control on High-Speed Networks INFOCOM 2004
bic: high-sPeed APPlicAtion
"Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks�
In 2005 they made an improvement and they published another paper using the basic BIC technique. The name of the paper is CUBIC : A New TCP-Friendly High-Speed TCP Variant. It Simplifies the BIC window control using a cubic function. And Improves its TCP friendliness & RTT fairness
More information: http://www.csc.ncsu.edu/faculty/rhee/export/bitcp Injong Rhee, Lisong Xu Congestion Control on High-Speed Networks INFOCOM 2004
soMe thoughts on FutuRe MM • • • • • •
Video Compression – How about using a combination of encoding schemes? Application Level QoS – The effectiveness of TCP like rate control. Continuous media distribution services – A scalable, cost-effective, efficient and incremental deployable infrastructure for continuous media distribution. Streaming servers – VCR like control, Storage mechanisms, scalability, fault tolerance. Media synchronization – Synchronization in multicast video while supporting VCRlike interactive functions. Protocols – Caching, support for pause/resume operation in caches, security in protocols.
Streaming Video over the Internet: Approaches and Directions Dapeng Wu, Yiwei Thomas Hou et al.
soMe thoughts Internet friendly behavior is necessary for the multimedia revolution that is coming in the next decade. Also congestion is an important and complex problem. Many solutions of varying effectiveness and complexity for various applications. Areas of future research are: •Methods of comparing protocols •Improve definitions of fairness, friendliness •Improve models of TCP traffic
ReFeRence http://www.cse.cuhk.edu.hk/~cslui/CSC5480/chapter6a.ppt http://www1.cs.columbia.edu/~danr/courses/6761/Fall00/week9/6761-8-realtime.ppt http://data.uta.edu/~ramesh/book/MultimediaSystems/ppts/M5L1.ppt http://www.cs.rochester.edu/~kshen/csc257-fall2007/lectures/lecture20-multimedia.pdf http://www.cs.ubc.ca/~agupta/courses/TSDS/presentation24jan.ppt http://pages.cs.wisc.edu/~akella/CS640/F06/slides/F06_Lecture19_multimedia.pdf http://www.multicom.uwaterloo.ca/pastseminars/RTP-presentation.pdf http://www.singaren.net.sg/library/presentations/14Mar03/presentation_06.pdf http://web.cs.wpi.edu/~claypool/courses/525-S03/slides/XMZY97.ppt http://mm.aueb.gr/presentations/2003-Wireless-researchseminar.pdf http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/bic-lisong.ppt http://www.cs.ucla.edu/~mjwelch/files/tfrc/medium_start.ppt http://web.cs.wpi.edu/~rek/NOSSDAV03.ppt http://www.ens-lyon.fr/LIP/RESO/pfldnet2005/Slides/PFLDnet2005-RheeXu.ppt http://utopia.duth.gr/~ppapadim/ppts/aina06.ppt http://www.icir.org/floyd/talks/tfrcbis-mar08.ppt http://www.hpl.hp.com/personal/Kevin_Lai/projects/dccp/EZ02.OralPres3.e190.ppt http://www.ietf.org/rfc/rfc3448.txt http://www.psc.edu/networking/tcp_friendly.html http://acronyms.thefreedictionary.com/Wireless+Multi-Media+Streaming+TCP-Friendly+Protocol