congestion control in multicast
DESCRIPTION
Congestion control in Multicast. ElEG 667 May 7, 2003. by Keyur Shah CIS, University of Delaware. TCP Friendly Congestion Control Schemes. Single-rate. Multi-rate. Window-based. Rate-based. Window-based. Rate-based. Single Rate and Multi Rate. Single Rate : - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/1.jpg)
Congestion control in Multicast
ElEG 667May 7, 2003
byKeyur Shah
CIS, University of Delaware
![Page 2: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/2.jpg)
TCP Friendly Congestion Control
Schemes
Single-rate Multi-rate
Window-based Rate-based Window-based Rate-based
![Page 3: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/3.jpg)
Single Rate and Multi Rate
Single Rate :
Data is sent to all receivers at the same rate.
The rate is typically limited by the slowest receiver
Thus a single slow receiver can drag down the data rate of the whole group
![Page 4: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/4.jpg)
Multi-rate :
Allows for a more flexible allocation of bandwidth along different network paths.
Have the ability to generate the same data at different rates over multiple streams.
Receivers try to listen to one or more streams depending on their capacity
Receivers with different needs can be served at a rate closer to their needs
![Page 5: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/5.jpg)
Window-based and Rate-based
Window-based : uses a congestion window Each transmitted packet consumes a slot in the congestion window Acknowledgment of a packet received, frees one slot Sender is allowed to transmit packets only if a slot is free
Rate-based : Dynamically adapts the transmission rate according to some network feedback mechanism that indicates congestion
![Page 6: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/6.jpg)
Single rate multicast congestion control scheme between one sender and one or more receivers
In Multicast, it is typical to use NAKs instead of ACKs to avoid ACK implosion. Also, NAK supression is done so that the Network Elements forward only 1 NAK per group of receivers to the upstream router.
This results in delayed feedback to the sender.
Issues
![Page 7: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/7.jpg)
These delays make the system unresponsive to variations in the network conditions. This leads to instability in the network. Another issue besides Stability…. TCP FRIENDLINESS
Such unresponsive flows which are slow in reacting to congestion can drive the other competing slow, responsive flows to a very low throughput
![Page 8: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/8.jpg)
Pragmatic General MulticastCongestion Control
(PGMCC)
![Page 9: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/9.jpg)
PGMCC tries to achieve faster response
It also includes positive ACKs
But having each receiver send an ACK causes the scalability problem
Solution: Elect a group representative (called ACKER) who is responsible for sending positive ACKs
The ACKER is dynamically selected to be the receiver which would have the lowest throughput
Note: Due to the dynamics of the network the receiver with the lowest throughput may change from time to time…i.e. The ACKER will also change.
![Page 10: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/10.jpg)
Window based Controller used by pgmcc
Window based congestion control scheme is run between the sender and the ACKER
Uses AIMD
Uses 2 variables:
• Window Size (W) – describes the current window size in packets
• Token Count (T) – the no of packets that can be transmitted
![Page 11: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/11.jpg)
On start up or after timeout : W = T =1
On Transmit : T = T-1
On ACK reception : W = W + 1/W T = T + 1 + 1/W
On loss detection : W = W/2by dupacks
Pgmcc like TCP does some exponential opening of the window (Slow Start). It is limited to a fixed size 4-6 packets
Primarily done to quickly open the window beyond the dupack threshold
![Page 12: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/12.jpg)
ACKER selection
Aim – To determine the receiver which would have the lowest throughput
Throughput for each receiver can be estimated using• Round Trip Time• Loss Rate
Initial ACKER selection
When receivers get a data packet with no ACKER selected, all receivers generate a dummy NAK report.The sender will select the source of the first incoming NAK as the new ACKER
![Page 13: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/13.jpg)
Whenever an ACK or NAK arrives from any receiver:
• The sender computes the expected throughput (T_i) for that receiver using the RTT and loss rate.
• The sender has already stored the expected throughput for the current ACKER (T_ACKER)
• If T_i < C * T_ACKER Node i is selected as new ACKER
Note: C is between 0-1, used to avoid too frequent ACKER changes
![Page 14: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/14.jpg)
RTT measurement
Explicit Timestamp :
Transmit a timestamp with every data packet
Receiver echoes the most recent timestamp in the ACK or NAK
Sender computes the RTT by subtracting the received timestamp from the current value of the clock
![Page 15: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/15.jpg)
Implicit Timestamp :
Record a timestamp for each data packet, but timestamp isn’t transmitted
The receiver reports the most recent sequence no in the ACK or NAK using which the sender can find the corresponding timestamp
![Page 16: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/16.jpg)
Using Sequence numbers :
Least precise technique
Doesn’t require the presence of a high resolution clock on the nodes
Sender doesn’t compute any timestamp
Receiver echoes the most recently received Sequence no
Sender computes RTT as the difference of the most recently sent Sequence no and the one echoed in the ACK or NAK
Thus RTT is in terms of sequence numbers and not seconds
![Page 17: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/17.jpg)
Timeouts
In TCP, Timeout value is calculated by accumulating statistics of SRTT and RTTVAR
PGMCC can use a similar scheme, only that whenever the ACKER changes the computation of SRTT and RTTVAR must be restarted
An ACKER may leave the group without notifying the sender
To avoid many successive timeouts due to absence of an ACKER, new election of ACKER should be performed after TWO successive timeouts
![Page 18: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/18.jpg)
Fairness !!!
![Page 19: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/19.jpg)
Intra-protocol fairness with non-lossy and lossy links
non-lossylink
Lossylink
![Page 20: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/20.jpg)
Inter-protocol fairness
non-lossylink
Lossylink
![Page 21: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/21.jpg)
Source based scheme is limited by the slowest receiver
-The conflicting bandwidth requirements of all receivers cannot be simultaneously met with one transmission rate
This can be achieved if we transfer the burden of rate adaption to the receivers
The source can generate data at different rate over multiple Streams
The receivers try to listen to one or more streams depending on their capacity.
Another Approach
![Page 22: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/22.jpg)
Receiver driven Layered Multicast (RLM)
The source simply transmits each layer of its signal on a separateMulticast group
Receiver has the key functionality- It adapts by joining and leaving groups
Conceptually the receiver,- On congestion, drops a layer- On spare capacity, adds a layer
Receiver searches for the optimal level of subscription
Similar to TCP which searches for its optimal rate using AIMD
![Page 23: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/23.jpg)
S-R1 path has high capacity - R1 subscribes to all 3 layers and gets highest quality signal
R2, R3 have to drop layer 3 because the 512 kb/s link becomescongested
![Page 24: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/24.jpg)
How many layers to subscribe ?
Receiver needs to determine whether its current level of subscription is too high or low
Too high is easy to find- as it’ll cause congestion
Too low – there is no signal to the receiver to indicate that its subscription is too low
![Page 25: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/25.jpg)
RLM performs a join-experinment-spontaneously adds layers at “well chosen” times
If a join-experiment causes congestion- the receiver quickly drops the offending layer
If a join experiment is successful- the receiver is one step closer to the optimal operating point
Subscribing to layers in RLM
![Page 26: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/26.jpg)
Join experiments cause transient congestion
Need to minimize the frequency and duration of the join experiments
Solution : A learning strategyDoing join experiments infrequently when they are likely to fail
And doing them readily when they are likely to succeed
Done by, managing a separate Join Timer for each level of subscription
![Page 27: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/27.jpg)
Time
1
4
3
2
Layer #
F
ED
C
B
A
![Page 28: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/28.jpg)
Scalability of RLM
If each receiver carries out the adaptation algorithmThe system scales poorly
As the session membership grows Aggregate frequency of join experiments increases network congestion increases
![Page 29: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/29.jpg)
S
R1 R2
Join-2 Join-4
congestion
Also, join-experiments can interfere with each other
R1 can misinterpret the congestion and back off layer 2 join-timer
![Page 30: Congestion control in Multicast](https://reader036.vdocuments.site/reader036/viewer/2022062408/56813e15550346895da7f71b/html5/thumbnails/30.jpg)
Solution – Shared Learning
Receiver notifies the entire group, that it is now performing a join-experiment on layer ‘x’
All receivers can learn from the failed join experiments of other receivers