Multicast Congestion Control in the Internet: Fairness and Scalability Sponsored by Tektronix and the Schlumberger Foundation technical merit award Chin-Ying Wang Advisor: Sonia Fahmy Department of Computer Sciences Purdue University http://www.cs.purdue.edu/homes/fahmy/

Overview What is Multicasting? PGM PGMCC Feedback Aggregation Fairness Conclusions and Ongoing Work

What is Multicasting? Multicasting: = group member Multicasting: allows information exchange among multiple senders and multiple receivers Popular applications include: audio/video conferencing, distributed games, distance learning, searching, server and database synchronization, and many more

How does Multicasting Work? datagram S Router Router feedback R R A single datagram is transmitted from the sending host This datagram is replicated at network routers and forwarded to interested receivers via multiple outgoing links Using multicast connections  traffic and management overhead not  number of participants If reliability is required, receivers provide feedback to notify the sender whether the data is received

The Feedback Implosion Problem S = Sender R = Receiver = data Router = ACK/NAK Router R S Feedback implosion R

The Congestion Control Problem How should the sender determine the sending rate? R ? S Router Router R 500 Kb/s R 1000 Kb/s 300 Kb/s 750 Kb/s

Our Goals To study the impact of feedback aggregation on a promising protocol, the PGMCC multicast congestion control protocol To evaluate PGMCC performance when competing with bursty traffic in a realistic Internet-like scenario Ultimately, to design more scalable and more fair multicast congestion control techniques

Multicast Congestion Control ?=300 Kb/s 500 Kb/s 1000 Kb/s S Router Router 300 Kb/s 750 Kb/s R3 R1 Single-rate schemes: Sender adapts to the slowest receiver TCP-like service: one window/rate for all the receivers Limitations: Underutilization on some links Selects the slowest receiver in the group (“crying baby syndrome”)

The PGM Multicast Protocol PGM: Pragmatic General Multicast Single sender and multiple-receiver multicast protocol Reliability: NAK based retransmission requests Scalability: feedback aggregation and selective repair forwarding Suppress replicated NAKs from the same sub-tree in each router

PGM NAK/NCF Dialog Router Router Router Subnet NCF Router NCF NAK NCF ODATA NAK NCF Router RDATA NAK PGM Receivers NAK NCF Subnet NAK Subnet Router NCF PGM Sender NAK PGM Receiver See [Miller1999] and RFC for more details.

PGMCC [Rizzo2000] Use TCP throughput approximation to decide on the group representative, called “ACKer” Update acker to I when T(I) < cT(J) 300 Kb/s RJ Current acker S Router Router RK 500 Kb/s RI 1000 Kb/s 300 Kb/s 750 Kb/s Newly joined receiver whose throughput T(I) < c× current acker’s throughput T(J)

PGMCC (cont’d) Attempts to be TCP-friendly, i.e., on the average, no more aggressive than TCP ACKs are used between the sender and acker TCP-like increase and decrease Throughput of each receiver is computed as a function of fields in NAK packets: Round Trip Time (RTT) Packet loss

Feedback Aggregation Experimental Topology Goal: To determine if there are unnecessary/missing acker switches due to feedback aggregation PR1 PR3 20 % loss PS Router Router Ns-2 Simulator is used. All links are 10 Mb/s with 50 ms delay. 25 % loss PR4 PR2

Feedback Aggregation Experimental Result

PGMCC Fairness Simulate PGMCC in a realistic scenario similar to the current Internet The objective is to determine whether PGMCC remains TCP friendly in this scenario Different bottleneck link bandwidths are used in the simulation: Highly congested network Medium congestion Non-congested network

General Fairness (GFC-2) Experimental Topology PS S15 S16 S17 S10 S14 S20 S18 S4 S21 S0 S1 S11 S5 S3 S13 S19 D5 S7 S2 S12 D4 router5 router1 router3 S6 S8 D13 D3 router0 D14 router4 router2 router6 D0 D2 D9 D12 D7 D1 S9 D15 D20 D21 D6 Link0 Link1 Link3 Link2 Link4 Link5 D8 D10 D11 D16 PR2 D19 D18 D17 PR1 PR3 PR4 PR5

Topology (cont’d) 22 source nodes (S*) and 22 destination nodes (D*) NewReno TCP connection is run between each pair of source and destination nodes One UDP flow sending Pareto traffic runs across Link4 with a 500 ms on/off interval All simulations were run for 900 seconds TCP connection traced runs from S4 to D4

Topology (cont’d) Link bandwidth between each node and router is 150 kbps with 1 ms delay Link bandwidths and delays between routers are: Link0 Link1 Link2 Link3 Link4 Link5 Bandwidth (kbps) 50 100 150 Delay (ms) 20 10 5

Highly Congested Network PGM has a higher throughput in the first 50 seconds Afterwards, PGM has very low throughput due to time-outs

Medium Congestion Maintain all simulation parameters unchanged except increasing the link bandwidth between routers from 2.5 and 3.5 times the bandwidth in “highly congested” network PGM flow outperforms TCP during initial acker switching TCP has higher throughput when the timeout interval at PGM sender does not adapt to the increase of the acker RTT

Medium Congestion (cont’d) Bandwidth = 2.5×”Congested”

Medium Congestion (cont’d) Bandwidth = 3.5×”Congested”

Non-congested Network Maintain all simulation parameters unchanged except increasing the link bandwidth between routers from 10 and 80 times the bandwidth in highly congested network PGM flow outperforms TCP flow as the bandwidth increases Frequent acker switches cause the increase of the PGMCC sender’s window The RTT of the PGMCC acker is shorter than the TCP flow RTT at many instances

Non-congested Network (cont’d) Bandwidth = 10×”Congested”

Non-congested Network (cont’d) Bandwidth = 80×”Congested”

Main Results Feedback aggregation: Results in incorrect acker selection with PGMCC Problem is difficult to remedy without router assistance PGMCC fairness in realistic scenarios: Initial acker switches causes the PGM flow to outperform the TCP flow due to the steep increase of the PGM sending window A TCP-like retransmission timeout is needed to avoid the PGM performance degradation caused by using a fixed timeout interval

Ongoing Work Conduct Internet experiments with various reliability semantics (e.g., unreliable and semi-reliable transmission) and examine their effect on PGMCC, especially on acker selection with insufficient NAKs Exploit Internet tomography in multicast and geo-cast application-layer overlays [NOSSDAV2002, ICNP2002]