Circuit Switching

Circuit Switching

Circuit Switching Network resources (e.g., bandwidth) divided into “pieces” Pieces allocated to and reserved for calls Computer Networks Resource idle if not used by owner (no sharing) Ways to divide link bandwidth into “pieces” • frequency division multiplexing (FDM) frequency Example: Lecture 36: 4 users time QoS, Priority Queueing, VC, WFQ • time division multiplexing (TDM) frequency time Packet Switching Bandwidth division into “pieces” Packet Switching: Dedicated allocation Each end-to-end data stream Resource reservation Statistical Multiplexing divided into packets 10 Mbps C Packets from multiple users share network resources A Ethernet statistical multiplexing Each packet uses full link bandwidth B 1.5 Mbps Resources used as needed queue of packets waiting for output Resource contention: link • aggregate resource demand can exceed amount available D • congestion: packets queued, wait for link use E • store and forward: packets move one hop at a time Sequence of A’s and B’s packets does not have a fixed • each node receives complete packet before forwarding pattern ⇒ statistical multiplexing Packet vs. Circuit Switching Pros and Cons of Packet Switching Packet switching allows more users to use network! Advantages: great for bursty data • resource sharing For example: • simpler, no call setup • 1 Mbps link • each user: • sends 100 kbps when “active” Disadvantages: excessive congestion, N users • active 10% of time 1 Mbps link packet delay and loss • protocols needed for reliable data transfer circuit-switching: 10 users • congestion control • no service guarantee: “best-effort” service packet switching: with 35 users, probability that more than 10 are active at the same time < .0004 Better than Best-Effort Service Example: HTTP vs. VoIP Traffic Approach: deploy enough link capacity such that 1Mbps VoIP shares 1.5 Mbps link with HTTP congestion doesn’t occur, traffic flows without • HTTP bursts can congest router, cause audio loss queueing delay or overflow buffer loss • want to give priority to audio over HTTP • advantage: low complexity in network mechanisms • packets can be differentiated by port number or • packets can be marked as belonging to different classes • disadvantage: high bandwidth costs, most of the time bandwidth is under utiliZed (e.g., 2% average utiliZation) 1 Mbps phone R1 Alternative: multiple classes of service R2 • partition traffic into classes (not individual connections) • network treats different classes of traffic differently 1.5 Mbps link Priority Queueing Traffic Metering/Policing Send highest priority high priority queue What if applications misbehave (VoIP sends higher than queued packet first declared rate)? • multiple classes, with arrivals departures different priorities Marking and/or policing: classifier server • fairness: gives priority to low priority queue • force sources to adhere to bandwidth allocations some connections • provide protection (isolation) for one class from others 2 • delay bound: higher priority 1 3 4 5 • done at network ingress connections have lower delay arrivals • but within the same priority, packet in 1 Mbps service 1 3 2 4 5 still operates as FIFO, hence phone R1 R2 delay not bounded departures 1 3 2 4 5 • relatively cheap to operate 1.5 Mbps link (O(log N)), N number of packets in queue packet marking and/or policing Policing Mechanisms Token-Bucket Filter Limit packet stream to specified Goal: limit traffic to not exceed declared parameters burst siZe and average rate Three commonly used criteria: 1. average rate: how many packets can be sent per averaging time interval • crucial question: what is the averaging interval length? • 100 packets per sec or 6,000 packets per min have the same average! • bucket can hold at most b tokens • new tokens generated at the rate of r tokens/sec 2. peak rate: packet sent at link speed, inter-packet gap is • new tokens dropped once bucket is full transmission delay • • e.g., 6,000 packets per min (ppm) avg.; 1,500 ppsec peak packet can be sent only if there’s enough tokens in buffer to cover it 3. (max.) burst siZe: maximum number of packets allowed to • assuming 1 token is needed per packet, over be sent at peak rate without intervening idle period interval of length t: number of packets metered out is ≤ (rt + b) Circuit vs. Packet Switching Packet-Switched Networks No call setup at network layer Packet switching: data sent through the No state to support end-to-end connections at routers network in discrete “chunks” • no network-level concept of “connection” • route may change during session Circuit switching: dedicated circuit per call Packets forwarded using destination host address • end-to-end resources reserved for calls • packets between same source-destination pair may take • link bandwidth, switch capacity different paths • call setup required • dedicated resources: no sharing application • guaranteed performance application transport • resource idle if not used by owner transport network 1. send data 2. receive data network data link data link physical physical Pros and Cons of Packet Switching Virtual Circuits (VC) Advantages: great for bursty data Datagram network provides network-layer • resource sharing connectionless service • simpler, no call setup VC network provides network-layer connection- Disadvantages: excessive congestion, packet oriented service delay and loss Analogous to the transport-layer services, but: • protocols needed for reliable data transfer • service is host-to-host, as opposed to socket-to-socket • congestion control • no service guarantee of any kind • implementation in network core Source-to-destination path behaves much like a How to provide circuit-like quality of service? telephone circuit • bandwidth and delay guarantees needed for multimedia apps • in terms of performance, and • network actions along the path Virtual Circuits Virtual Circuits A VC comprises: Signalling protocol: 1. path from source to destination • used to setup, maintain, teardown VC • each call must be set up before data can flow • e.g., ReSource reserVation Protocol (RSVP) • requires signalling protocol • fixed path determined at call setup time, remains fixed throughout call • every router on path maintains state application for each passing connection/flow 6. receive data application transport 5. data flow begins transport • link, router resources (bandwidth, buffers) network 4. call connected network may be allocated to VC data link 3. accept call data link physical 2. VC numbers, one number for each link along path physical 1. initiate call • each packet carries a VC identifier (not destination host address) 2. incoming call 3. entries in forwarding tables in routers along path VC Forwarding Table Per-VC Resource Isolation Packet belonging to a VC carries a VC number To provide circuit-like quality of service VC number must be changed for each link • resources allocated to a VC must be isolated from other traffic New VC number obtained from forwarding table Examples: MPLS, Frame-relay, ATM, PPP Bit-by-bit Round Robin: t9 t6 t3 t0 • cyclically scan per-VC queues, Forwarding table on router NW: 4 3 2 1 VC number incoming incoming outgoing outgoing sending one bit from each VC interface VC# interface VC# t7 t4 t1 12 NW 22 32 (if present) µ 1 12 2 22 3 2 1 1 2 • 1 round, R( ), is defined as all RR 3 2 63 1 18 non-empty queues have been t11t10 t8 t5 t2 3 7 2 17 served 1 quantum 5 4 3 2 1 interface 1 97 3 87 • R(t5) = 2 number … … … … • time at Round 3? Round 4? 1 bit Routers maintain connection state information! A.k.a. GeneraliZed Processor Sharing (GPS) Fluid-Flow Approximation Packetized Scheduling Packet-by-packet Round Robin: A continuous service model • cyclically scan per-flow queues, sending one • t5 t4 t2 t1 instead of thinking of each quantum as packet from each flow (if present) serving discrete bits in a given order • Problem: gives bigger share to 2 1 • think of each connection as a fluid stream, t9 t8 t7 t6 t3 flows with big packets µ described by the speed and volume of flow 6 5 4 3 2 1 RR At each quantum the Packet-by-packet Fair Queueing: • same amount of fluid compute F: finish round, the round a t8 t7 t3 t2 from each (non-empty) packet finishes service 2 1 • simulates fluid-flow RR in the F=4 F=2 stream flows out RR µ t9 t6 t5 t4 t1 µ computation of F’s FQ concurrently • serve packets with the 6 5 4 3 2 1 F=5 F=3 F=1 smallest F first F=6 F=4 F=2 R5 R4 R3 R2 R1 Start and Finish Rounds Round# vs. Wall-Clock Time Let: Round# • time: wall-clock time When does packet i finish service? Fα • round: virtual-clock time i α α α a c F = S + P , t8 t7 t3 t2 b i i i • µ = 1 unit α α 2 1 Pi where P is the service time (in • tα : arrival time of packet i of flow α i F=4 F=2 i α µ t9 t6 t5 t4 t1 • Nac(t): #active flows at time t Sα rounds) of packet i and S i the FQ i service start round 6 5 4 3 2 1 F=5 F=3 F=1 Computing the rate of change: F=6 F=4 F=2 tα tα+δ tα+δ tα+δ a: Nac = 1, ∂R/∂t = µ/Nac(t) = 1, i i 1 i a i 2 Wall-clock time At what round does packet i b: Nac = 2, ∂R/∂t = ½, δ2 = 2∗δ1 of flow α start seeing service? c: at the beginning, Nac = 1, ∂R/∂t = 1, α α α halfway serving packet i, a packet belonging to S i = MAX(F i–1, A i) another flow arrives, Nac = 2, ∂R/∂t = ½ • Sα = Fα if there is a queue, Aα otherwise i i–1 i As N (t) changes, finish round stays the same, • Aα R(tα ) i ac i = i : round at the time packet arrives actual time stretches Round Computation Example Arrival Round Computation Scenario: When packet i of an active flow arrives, its finish round is • A 1 1 t α α α α flows has packet of size arriving at time 0 computed as F i

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    9 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us