1 / 12

PGMCC :A TCP-friendly Single-rate Multicast Congestion Control Scheme

PGMCC :A TCP-friendly Single-rate Multicast Congestion Control Scheme. Author - Luigi Rizzo CS 590F Seminar Presenter - Ameya Varde. Terminology. Multicast - data transfer from a single sender to multiple receivers. Group - set of receivers. Acker - slowest receiver within the group.

Download Presentation

PGMCC :A TCP-friendly Single-rate Multicast Congestion Control Scheme

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. PGMCC :A TCP-friendly Single-rate Multicast Congestion ControlScheme Author - Luigi Rizzo CS 590F Seminar Presenter - Ameya Varde

  2. Terminology • Multicast - data transfer from a single sender to multiple receivers. • Group - set of receivers. • Acker - slowest receiver within the group. • Single rate multicast - • All receivers get the same data rate. • Sender adapts to the slowest receiver. • A single slow receiver can drag down the data rate for the whole group. • Scheme is relatively easy and consumes smaller bandwidth. • TCP friendly - sender transmits no faster than the TCP fair rate at the slowest receiver.

  3. Objective of PGMCC • Prevent congestion in the multicast session. • To do so, we need to - • Find the slowest receiver (acker). • Ackers may change over time. • Transmit no faster than the acker can accept.

  4. Working of PGMCC • Acker election and tracking. • PGMCC makes use of NAK's sent by receivers to decide the acker. • Congestion control. • The acker then supplies ACK's to the sender as an indication of successful data packet transfer. • A window-based congestion controller scheme similar to the one used in TCP is used between the sender and acker.

  5. Packet Formats

  6. Acker Election and Tracking • Two parameters (present in the NAK) decide the acker. • rxw_lead Sender computes RTT. RTT = (most recent seq_no) – rxw_lead • rx_loss Receiver computes loss rate p. p = W x pprev + (1-W) x seq_no • Throughput T  1 / (RTT x p) • Acker is the receiver with the lowest T. • Receiver i becomes the new acker if • Ti < c x Tacker c  0.6-0.8 • c is used to reduce the number of acker switches.

  7. Congestion Control • Sender maintains two state variables, window W and token count T. • W is an estimate of the number of packets in transit. • T regulates the generation of data packets. • on session start, W=1, T=1. • on transmit, T=T-1 (i.e. consume one token). • on ACK, W=W +1/W, T=T+1+1/W. • on NAK, W=W/2, T unchanged for next W/2 ACK's.

  8. PGMCC enabled routers • NAK suppression. • Filters repeated NAK's coming from receivers to sender. • Stores state. • Maintains rx_id, rxw_lead. • Selective Forwarding. • Forwards re-transmitted packets only to expecting receivers • Problem: • Could result in sender not receiving a NAK from a potential acker • Solution: • Maintain rxw_loss in router as well. • For a repeated NAK, compare incoming rxw_loss with the stored one. If lesser, forward NAK to sender.

  9. Experimental Results

  10. Advantages of PGMCC • RTT computed without the need for globally synchronized clocks. • Sender is not hindered by acker switches. • Works fine even for unreliable protocols. • Works with or without router support. • Responsive to uncorrelated losses . • Sender uses loss rates (rx_loss) computed by receivers. • Avoids "drop-to-zero" problem. • Achieves intra protocol and inter protocol fairness. • Scaleable.

  11. Disadvantages and Future work Disadvantages • Requires loss reports from receivers. • Most calculations are approximate. Future work • Use of alternate methods to compute loss rate at the receivers. • Computing throughput more accurately. • Use adaptive rather than a fixed value (6) for slow start threshold.

  12. Conclusions • PGMCC has been implemented by the author in the PGM protocol on BSD Unix. • Achieves the desired results in the configurations that were tested. • Author believes that PGMCC can be reliably used for multicast communication over the Internet on a small-medium scale.

More Related