457lecture02.ppt

20
 CS 457 - Lecture 2 Network Performance Fall 2011

Upload: fxww2001

Post on 07-Oct-2015

215 views

Category:

Documents


0 download

TRANSCRIPT

  • CS 457 - Lecture 2Network PerformanceFall 2011

  • How Is the Link Shared?Circuit Switched or Packet SwitchedCircuit switchingdedicate link bandwidth & switch capacity to each call Requires call setupGuaranteed performancePacket switchingPacket: small chunks of dataSend packets as soon as link availableSwitch receives a full packet then forwards it towards the destination

  • Circuit Switching: FDM and TDM2 usersExample:

  • Packet Switching: Statistical MultiplexingStore-and-forwardPacket switch can temporarily buffer up packetsIntroduces queueing delayPackets get dropped when the queue is full

  • How Many Users Can Share?Given 1 megabits/sec (1 Mbps) linkAssume each user: User send 100,000 bits/sec when activeUser is active 10% of time100% of capacity used if 10 active users.Circuit-switching: Link can support 10 usersPacket Switching: Link can support 35 users Prob.(n > 10) 0.0004 1 Mbps link

  • Circuit Switching PerformanceGiven 1 megabits/sec (1 Mbps) linkDivided into 10 distinct slices (TDM or FDM)No Interaction between usersPotential bandwidth for my connection is 1 Mbps/10 = 100,000 bpsHow long to send 4 Mb file?4 Mb / 100,000 bps = 40 secPlus some delay to setup connectionAssume 1 seconds Total of 41 secondsThroughput = 97,560 bpsHow long to send 100,000b file?100,000b / 100,000bps = 1 secTotal of 2 secondsThroughput = 50,000 bps1 Mbps link

  • Packet Switching PerformanceABpropagationtransmissionqueueingCTransmission R = link bandwidth (bps)L = packet length (bits) Propagationd = length of physical links = propagation speed in medium (~2x108 m/sec)= L / R= d/sQueueing = #packets in queue X transmission time of each packet

  • Delay on A Single LinkRelevant SpecificationsBandwidth: R = 1 MbpsPacket Size: L = 1000 bitsLink length: d = 100 kmPropagation Speed: s = 2.0 x 10^8 m/sec (typical fiber)Assumptionsqlength = 2 Packets in queue when our packet arrivesTotal Delay = transmit + prop + queue= (L/R) + (d/s) + (qlength * L/R)= (1000/1000000) + (100000/2 x 10^8) + (2*1000/1000000) = 3.5 ms

  • Some Comments about UnitsBits or BytesBits denoted by bBytes denoted by BMb = megabits while MB = megabytesKb = kilobits while KB = kilobytesHow big is K and M? It depends.Mega = 2^20, Kilo = 2^10Mega = 10^6, Kilo = 10^3Bandwidth uses powers of 10Tied to MHz which is 10^6 hertzSo bandwidth of 1 Mbps = 10^ bits per secondMessages use powers of 2Tied to computer memory measures in powers of 2So packet/file/message of 1 Mb = 2^20 bits

  • Example ProblemFind total time to transfer a file assumingFile size is 1.5 MB, RTT is 80 ms, Packet size is 1KBInitial 2*RTT handshake before sending dataBandwidth is 10 Mbps and packets sent continuouslyTotal Time to get all bytes to receiver is: Handshake + transmit + prop 2*RTT + FileSize/R + RTT 2 * 80 ms + 1.5 MB/ 10 Mbps + 80 ms 160 ms + 12,582.912 b/ 10,000,000 b/s + 40 ms approx 1.458 seconds

  • Time to send a packet from point A to point Bsum of delays across each hop along the path

    RTT: round-trip-time Network latency132A: my laptopB: www.cnn.com

  • Bandwidth and LatencyBandwidth matters L large => L/R dominatesIncreasing R reduces latencyProp delay mattersL small => L/R also small Increasing R has no impact

  • Examples

    Link TypeBandwidthDistanceRTTBW x DelayDial-up56Kb/s10Km87 ms5 bitsWireless Lan54Mb/s50m0.33ms18 bitsSatellite45 Mb/s33,000 Km230 ms10 MbCross-country fiber10Gb/s4,000 Km40 ms400 Mb

  • Store and Forward (1/2)Store and Forward: Entire packet must arrive at router before it can be transmitted on next link: Let dqueue = dprop = 0Takes dtrans = L/R seconds to transmit (push out) packet of L bits on to link of R bps

    Example:L = 8000 bits (1000bytes)R = 2 MbpsDelay(A-B) = 3L/R = 12 msecRRRL

  • Application PerformanceApplication input to networkTraffic data rateTraffic pattern (bursty or constant bit rate)Traffic target (multipoint or single destination, mobile or fixed)Network service delivered to applicationDelay sensitivityLoss sensitivity

  • Email, Reliable File TransferLoss sensitiveNot delay sensitive relative to round trip timesPoint-to-pointBursty

  • Remote LoginLoss sensitiveDelay sensitive Subject to interactive constraintsCan tolerate up to several hundreds of millisecondsBurstyPoint to point

  • Network AudioRelatively low bandwidthDigitized samples, packetizedDelay variance sensitiveLoss tolerantPossibly multipoint, long duration sessionsNatural limit to number of simultaneous senders

  • Network VideoHigh bandwidthCompressed video, burstyLoss tolerance function of compressionDelay tolerance a function of interactivityPossibly multipointLarger number of simultaneous sources

  • WebTransactional trafficShort requests, possibly large responsesLoss (bug?) tolerantDelay sensitiveHuman interactivityPoint-to-point (multipoint is asynchronous)

    **How to share the same physical network

    Guaranteed performance means exactly the defined performance, not the best performanceSome hosts may want to send faster than some othersPacket switching buffers data -> delay*network resources (e.g., bandwidth) divided into piecespieces allocated to callsNotice that one must send at constant rate to fully use the allocated resource; otherwise it is wasted. May not matter to you, but may matter to others who want to go faster than the allocated rate.Another problem: bursty behavior of most data sourcesresource piece idle if not used by owning call (no sharing)dividing link bandwidth into piecesfrequency divisiontime division Two simple multiple access control techniques.Circuit switching net has no memory

    Problems:- Idle channels- Reject further users when the system full**Great for bursty dataresource sharingno call setupExcessive congestion: packet delay and lossprotocols needed for reliable data transfer, congestion controlQ: How to provide circuit-like behavior to less flexible applications?performance (delay/thruput) bounds needed for audio/video appsstill a developing area.sometimes it is network problem and sometimes application (chapter 6)

    *Great for bursty dataresource sharingno call setupExcessive congestion: packet delay and lossprotocols needed for reliable data transfer, congestion controlQ: How to provide circuit-like behavior to less flexible applications?performance (delay/thruput) bounds needed for audio/video appsstill a developing area.sometimes it is network problem and sometimes application (chapter 6)

    *******What the application delivers to the network? What the application needs from the network: a target data rate, target latencies etc. Talk about each one of these and how it affects network design. What kinds of tradeoff can we do? How traffic burstiness affects the aggregate characteristics; in turn, how are applications affected by delay and loss. Explain burstiness.*Eg. FTP. Cannot tolerate loss, can tolerate modest amounts of delay, not inherently bursty, but because of some control algorithms Analogy of humans transferring (taking dictation). Other characteristics: large packet sizes etc.****