1 / 22

Design Principle: Multiplexing

Design Principle: Multiplexing. Goals: identify, study common architectural components, protocol mechanisms what approaches do we find in network architectures? synthesis: big picture. design principles: separation of data, control hard state versus soft state randomization indirection

chase
Download Presentation

Design Principle: Multiplexing

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. Design Principle: Multiplexing Goals: • identify, study common architectural components, protocol mechanisms • what approaches do we find in network architectures? • synthesis: big picture design principles: • separation of data, control • hard state versus soft state • randomization • indirection • multiplexing • network virtualization: overlays • design for scale Multiplexing: sharing resource(s) among users of the resource. Based on slides by Don Towsley

  2. Many dimensions of multiplexing resource unavailability Other dimensions? • time granularity block, drop queue user granularity call burst packet on demand statistical reservations guaranteed shared among class per user

  3. Packet-level multiplexing resource unavailability Other dimensions? • time granularity block, drop queue user granularity call burst packet on demand statistical reservations guaranteed shared among class per user

  4. Scheduling And Policing Packets • scheduling: choose next packet to send on link • FIFO (first in first out) scheduling: send in order of arrival to queue • real-world example: stop sign • discard policy: • Tail drop: drop arriving packet • RED

  5. 2 3 1 3 4 5 1 4 3 1 5 4 2 5 2 Scheduling Policies: more Strict Priority scheduling: transmit highest priority queued packet • multiple classes, with different priorities • class may depend on marking or other header info, e.g. IP source/dest, port numbers, etc.. • real world example: reservations versus walk-ins arrivals time packet service time departures

  6. Scheduling Policies: still more round robin scheduling: • multiple classes • cyclically scan class queues, serving one from each class (if available) • real world example: 4-way stop (distributed scheduling)

  7. Scheduling Policies: still more Weighted Fair Queuing: • generalized Round Robin • each class gets weighted amount of service in each cycle

  8. Policing Mechanisms Goal: limit traffic to not exceed declared parameters Three commonly-used criteria: • (Long term) Average Rate:how many pkts can be sent per unit time (in the long run) • crucial question: what is interval length: 100 packets per sec or 6000 packets per min have same average! • Peak Rate: e.g., 6000 pkts per min. (ppm) avg.; 15000 ppm peak rate • (Max.) Burst Size: max. number of pkts sent consecutively (with no intervening idle)

  9. Policing Mechanisms Token Bucket: limit input to specified Burst Size and Average Rate. • bucket can hold b tokens • tokens generated at rate r token/sec unless bucket full • over interval of length t: number of packets admitted less than or equal to (r t + b).

  10. token rate, r arriving traffic bucket size, b per-flow rate, R WFQ D = b/R max Policing Mechanisms (more) • token bucket, WFQ combine to provide guaranteed upper bound on delay, i.e., QoS guarantee!

  11. General Model of Class-based Link Scheduling estimator class 1 class 2 class 3 classifier scheduler class 4

  12. Link sharing among classes The question: sharing link among classes of packets in times of overload • isolation among classes • sharing between classes when link not fully used link link NSF ARPA DOE flow1 flow2 flow3

  13. Link Scheduling Framework • each class guaranteed some share (fraction) of bandwidth (over suitable time interval) if needed • Use it or lose it: unused bandwidth should be used by others who can use it Under-limit class: used less than guaranteed share Over-limit class: used more than guaranteed share. Not a bad thing if not needed by others! At-limit class Unsatisfied class: has a persistent backlog and is under limit  (persistent backlog intentionally not defined) Satisfied: not unsatisfied 

  14. Agency A Agency B Agency C Link Scheduling Hierarchies link Classes may be divided into subclasses, which can then further divide class bandwidth according to link scheduling guidelines 10% 40% 50% ftp http IP ATM rt nrt smtp 1% 9% 15% 25% 30% 10% 10%

  15. link Agency B Agency C Agency A ftp http IP ATM rt nrt smtp Link Scheduling Guidelines A class can continue unregulated if one of the following hold: • the class is not overlimit • the class has a not-overlimit ancestor at level i, and there are no unsatisfied classes in link sharing structure at levels lower than i

  16. link Example 1 legend A under limit B at limit over limit      satisfied A2 A1 B2 B1  unsatisfied backlog Q; which classes need to be regulated?

  17. link legend under limit at limit over limit  satisfied  unsatisfied backlog Example 2 A B     A2 A1 B2 B1 Q; which classes need to be regulated?

  18. link legend under limit at limit over limit  satisfied  unsatisfied backlog Example 3       A2 A1 B2 B1 Q; which classes need to be regulated?

  19. link    legend under limit  at limit over limit  satisfied  unsatisfied backlog Example 4   A2 A1 B2 B1 Q; which classes need to be regulated?

  20. Link Sharing Summary • timescales over which persistent backlog and under/over limit defined are crucial • provide “rationale” basis for determining who is available to be scheduled in a multi-class, multi-objective system (elegantly) • devil is in the details

  21. Burst-level multiplexing • we’ve seen packet, call as unit of multiplexing • burst: yet another unit of multiplexing source- transmitted traffic time “burst” TASI: time assigned speech interpolation (AT&T mid 50’s) • detect silence periods in voice conversation • only send traffic during periods of speech activity (“talkspurts”) Optical Burst Switching: bufferless multiplexing of optical networks

  22. Multiplexing: what have we learned? • Many dimensions • Essential to accommodate users with diverse demands with limited resources (space, memory, time, …). • lots of mechanism • particularly for packet-level sharing • mechanisms: for implementing policy

More Related