1 / 32

Using Edge-To-Edge Feedback Control to Make Assured Service More Assured in DiffServ Networks

Using Edge-To-Edge Feedback Control to Make Assured Service More Assured in DiffServ Networks. K.R.R.Kumar, A.L.Ananda, Lillykutty Jacob Centre for Internet Research School of Computing National University of Singapore . Outline. Introduction Need for QoS Solutions TCP over DiffServ

reed
Download Presentation

Using Edge-To-Edge Feedback Control to Make Assured Service More Assured in DiffServ Networks

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. Using Edge-To-Edge Feedback Control to Make Assured Service More Assured in DiffServ Networks K.R.R.Kumar, A.L.Ananda, Lillykutty Jacob Centre for Internet Research School of Computing National University of Singapore

  2. Outline • Introduction • Need for QoS • Solutions • TCP over DiffServ • Issues • CATC • Key Observations • Design Considerations • Topology • Edge-to-Edge Feedback Architecture • Marking Algorithm • Simulation Details • Results and Analysis • Deployment • Inferences and Future work

  3. Introduction • Need for QoS • An exponential growth in traffic resulted in deterioration of QoS. • Over provisioning of networks could be a solution. • A better solution: An intelligent network service with better resource allocation and management methods,

  4. Solutions • Integrated Service • Per flow based QoS. • Not scalable. • Differentiated services • QoS for aggregated flows • Scalable • The philosophy: simpler at the core (AQM), complex at the edges.

  5. DiffServ Meter Packets Forward Classifier Marker Shaper/ Dropper Drop Logical View of a Packet Classifier and Traffic Conditioner

  6. DiffServ cont’d.. • Per-Hop behaviours • Expedited forwarding: Deterministic QoS • Assured forwarding: Statistical QoS • Classifier • Traffic Conditioner • Token Bucket (TB), Time Sliding Window (TSW) • Meter • Marker • Shaper/Dropper

  7. TCP over DiffServ • Recent measurements have shown TCP flows being in majority (95% approx. of byte share). • TCP flows are much more sensitive to transient congestion. • Unruly flows like UDP kills TCP traffic • Bandwidth assurance affected by size of target rate. • Biased against • Longer RTTs • Smaller window sizes

  8. Congestion Aware Traffic Conditioner (CATC) • Key Observations • Markers ,one of the major building blocks of a traffic conditioner helps in resource allocation. • Proper understanding of transient congestion in the network helps. • Edge routers have a better understanding of the domain traffic. • An early indication of congestion in a network helps to prioritize the packets in advance. • Existing feedback mechanisms are end-to-end. Eg: ECN

  9. CATC cont’d.. • Design Considerations • Markers should • Be least sensitive to marker or TCP parameters. • Be transparent to end hosts. • Maintain optimum marking. • Minimize synchronizations. • Be fair to different target sizes. • Be congestion aware.

  10. Topology

  11. Edge-to-Edge Feedback architecture • Two edge routers • Control sender (CS) and control receiver (CR) • Upstream: • At CS: • CS sends control packets (CP) at regular interval of time, control packet interval (cpi). • CPs are given highest priority. • At Core: • Core routers maintain the status of drops of the best effort packets. • Information maintained as a status flag to a max. of cpi time. • CP’s congestion notification (CN) bit set or reset based on status flag. • At CR: • Responds to the incoming CP with a CN bit set by setting the congestion echo (CE) bit of the outgoing acknowledgement.

  12. Feedback arch. Cont’d • Downstream • At CS: • Maintains a parameter, congestion factor (cf). • Cf is set to 1 or 0 based on status of the CE bit in acknowledgement received.

  13. Marking algorithm For each packet arrival If avg_rate  cir then mp=mp+(1- avg_rate/cir)*(1+cf*(cir/cir_max)); mark the packet using : cp 11 w.p. mp (marked packets) cp 00 w.p. (1-mp) (unmarked packets)

  14. Marking Algo. Cont’d.. • else if avg_rate > cir then mp=mp+ (1- avg_rate/cir)*(1-cf*(cir/cir_max)); mark the packet using : cp 11 w.p. mp (marked packets) cp 00 w.p. (1-mp) (unmarked packets)

  15. Marking Algo. Cont’d.. where, avg_rate = the rate estimate on each packet arrival mp = marking probability ( 1) cir = committed information rate (target rate) cf = congestion factor cir_max = maximum committed information rate also, cp denotes ‘codepoint’ and w.p. denotes ‘with probability’.

  16. Algo cont’d.. • Marking probability computation based on: • cir • avg_rate • cf • cir_max among all cirs.

  17. Algo. Cont’d.. • The effect on mp: • i)Flow component (1- avg_rate/cir) constantly compares the average rate observed with the target rate to keep the rate closer to the target. • ii)Network component cf*(cir/cir_max) provides a dynamic indication of congestion level status in the network. The marking probability increment is done in proportion to the target rate by multiplying cf with a weight factor cir/cir_max to mitigate the impact of the target rates.

  18. Simulation Details • NS (2.1b7a) simulator on Red Hat 7.0 • Modified Nortel’s DiffServ module for our architecture implementation. • Core routers use RIO like mechanism • FTP bulk data transfer for TCP traffic

  19. Simulation Parameters

  20. Simulation details cont’d.. • Experiments conducted: • Assured services (AS) for aggregates. • AS in under- and well- subscribed cases. • AS in the oversubscribed case. • Protection from BE UDP flows • Effect of UDP flows with assured (target) rates.

  21. R&A: under- and well- subscribed

  22. R&A:over-subscribed

  23. R&A: Goodput vs Time Graph (2/6 Mbps target rate.)

  24. Analysis CATC • Able to achieve the target rates for the under- and well- subscribed cases. • Maintain the achieved rate close to its target rate. • Total link utilization remains more or less constant throughout.

  25. R&A:AS in presence of BE UDP and TCP

  26. R&A:AS in presence of AS UDP and BE TCP

  27. Analysis CATC • Achieves goodput close to the target rates. • Succeeds in taking the share of BE TCP and UDP flows in the worst case scenario. • The average link utilization pretty good. • The AS UDP flow gets its assured rate.

  28. Deployment • MPLS over DiffServ. • Marker anywhere (lack of sensitivity to marker parameters).

  29. Inferences and Future work • The architecture is transparent to TCP sources and hence doesn’t require any modifications at the end hosts. • The edge-to-edge feedback control loop helps the marker to take proactive measures in maintaining the assured service effectively, especially during periods of congestion. • A single feedback control is used for an aggregated flow. Hence this architecture is scalable to any number of flows between the two edge gateways. • The architecture is adaptive to changes in load and network conditions. • The marking algorithm takes care of any bursts in the flows.

  30. Future work • Extend present architecture to take care of drops in priority queues. • A new algorithm to incorporate this.

  31. Q&A

  32. Thank You!

More Related