1 / 38

Real-time Transport for Assured Forwarding: An Architecture for both Unicast and Multicast Applications

Real-time Transport for Assured Forwarding: An Architecture for both Unicast and Multicast Applications. By Ashraf Matrawy and Ioannis Lambadaris From Carleton University, Ottawa, Canada Proc. Of IEEE ICC, 2003 Presented by Fang Yan 12/14/04. agenda. Motivation Related works

malina
Télécharger la présentation

Real-time Transport for Assured Forwarding: An Architecture for both Unicast and Multicast Applications

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. Real-time Transport for Assured Forwarding: An Architecture for both Unicast and Multicast Applications By Ashraf Matrawy and Ioannis Lambadaris From Carleton University, Ottawa, Canada Proc. Of IEEE ICC, 2003 Presented by Fang Yan 12/14/04

  2. agenda • Motivation • Related works • Network model • End-to-end architecture • The rate adaptation algorithm • Simulation results • Conclusion

  3. Motivation • Develop a multicast congestion control scheme that relies on the IETF proposed Assured Forwarding(AF) architecture. • AF helps build a simple end-to-end architecture. • AF is expected to be deployed soon in Internet routers • For simplicity, marking/policing is done at the senders, instead of the edge routers.

  4. Related works -- AF • A means for a provider to offer different levels of forwarding assurances for IP packets received from a customer • Better reliability than best-effort service • Four AF classes are defined, each AF class is allocated a certain amount of forwarding resources (buffer space and bandwidth) • Within each AF class IP packets are marked with one of three possible drop precedence values

  5. Related works -- RED • Random Early Detection • Widely used Active Queue Management (AQM) technique. • Parameters: • Avg: the average queue size • Minth: the minimum threshold • Maxth: the maximum threshold

  6. RED (contd.) • Algorithm

  7. RED (contd.) • Calculate Pa Pb = maxp(avg – minth)/(maxth – minth) pa = pb(1 – count * pb) Where • Maxp is the maximum value of pb • Count is packets number since last marked pkt

  8. Related work -- RIO • RED with In/Out bits • In/out service allocation profile • congested router preferentially drops out packets • Maintains tow average lengths : in and out • RIO-C : the number of out packets are calculated based on the total number of packets • RIO-D: the number of out packets are calculated based on the number of out packets only

  9. Related work -- WRED • Weighted RED • WRED generally drops packets selectively based on IP precedence • Packets with a higher IP precedence are less likely to be dropped than packets with a lower precedence. • Uses one average queue length to make dropping decisions

  10. Related work -- BECN • Backward Explicit Congestion Notification • uses the existing IP signaling mechanism, the Internet Control Messaging Protocol (ICMP) Source Quench (ISQ) message • Congestion notification is kept at the IP level • ISQ are generated by the intermediate congested RED router and sent back to the source as an indication of incipient congestion • The source reacts at the transport protocol level by lowering its data throughput into the network

  11. Network Model • Two-priority queue model • Staggered configuration of class parameters • Routers can send BECN

  12. End-to-End Architecture • Send MPEG4 packets as one multicast group • Packets are marked with different priority level by the rate adaptation algorithm at the sender • The decisions are based on the congestion status reported to the sender by the different routers • Congestion status is represented by the probability of the router sending a BECN message • Always tries to set the rate for the high priority packets to accommodate the router with the worst congestion

  13. P(t) Source R(t) IP Network

  14. Rate Adaptation Algorithm • Assume that MPEG4 traffic is divided into L layers marked with L different priorities. • Ri(t), 1<= I<= L, be the rate (in packets/sec) of layer i at the source at time t. • Pi(t) = PMaxi (t) + PSendi (t) PMinMaxi (t), Pi(t) is the probability that virtual queue i will generate a feedback message at time t. • PMaxi (t) = Prob{QueueSize(i) >=max} • PMinMaxi (t) = Prob{min <=QueueSize(i) <= max} • PSendi (t) = Prob{Send feedback message | min <= QueueSize(i) <=max}

  15. Rate Adaptation Algorithm • Considering the changes from old to new values of Ri(t) and Pi(t) in a small interval Δt

  16. Rate Adaptation Algorithm • Δt : the RTT value that corresponds to the router with the worst situation at the high priority layer • Routers send a feedback message for packet that causes a problem with a probability. (2% ~ 5%) • The number of packets between consecutive loss events is called a loss interval.

  17. Rate Adaptation Algorithm • To calculate Pi(t) at the end of an interval m • K=10 • W={4,4,4,4,42,2,2,1,1}

  18. Rate Adaptation Algorithm • Pnewi changes very Δt • At the highest priority layer, take the maximum • At lower priority layers, take the minimum • Subject to Rmini and Rmaxi

  19. Rate Adaptation Algorithm

  20. Simulation setup

  21. Simulation result high priority throughput

  22. Simulation result high priority throughput

  23. Simulation result high priority throughput

  24. Simulation result low priority throughput

  25. Simulation result low priority throughput

  26. Simulation result low priority throughput

  27. Simulation result total throughput

  28. Simulation result total throughput

  29. Simulation result total throughput

  30. Simulation result packet loss in high priority

  31. Simulation result packet loss in high priority

  32. Simulation result packet loss in high priority

  33. Simulation result packet loss in low priority

  34. Simulation result packet loss in low priority

  35. Simulation result packet loss in low priority

  36. Conclusion • Enables users with different bandwidth capabilities to receive the same video multicast in different qualities. • Always try to accommodate the slowest receiver at the high priority layer • Allow increasing the rate at the lower priority layer • RIO-D and WRED result in better utilization of bandwidth, but also high loss rate in the lower layer • RIO-C offers different qualities with lower loss rates at the expense of less bandwidth utilization

  37. Thank you! Questions?

More Related