1 / 63

Communication Systems 16 th lecture

Communication Systems 16 th lecture. Chair of Communication Systems Department of Applied Sciences University of Freiburg 2008. 1 | 51. Communication Systems Lecture evaluation.

jimbo
Download Presentation

Communication Systems 16 th lecture

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. Communication Systems16th lecture Chair of Communication Systems Department of Applied Sciences University of Freiburg 2008 1 | 51

  2. Communication SystemsLecture evaluation Last lecture we handed out the evaluation sheets – if not done already, please hand them back after this lecture unfortunately there is no online version this time we will look at the results and then hand over to the faculty processing of the results will take at the studies dean's office no idea on general feedback – typically it is handled rather secretive at the faculty :)‏ No more practical exercises (last sheet is handed back last lecture next Friday)‏ 2 | 51

  3. Communication SystemsLast lecture – WiMAX, Bluetooth, network fusion Last lecture devoted to WiMAX and Bluetooth WiMAX as a new wireless standard for MANs, as an alternative to cable and DSL “Wireless DSL” - different wide area network technologies in the former band of old analogous mobile phone networks to cover rural areas and offer high speed Internet access in sparsely populated areas Bluetooth for low-power, short-range, low-bandwidth communication Bluetooth is widely established and accepted in small mobile devices like mobile phones, PDAs, headsets, ... to replace wiring 3 | 51

  4. Communication SystemsLast lecture – WiMAX, Bluetooth, network fusion • UWB – Ultra Wide Band as an upcoming high bandwidth technology which should be able to share bandwidth with other users and is authorized to operate in the range of 3.1 upto 16GHz • In the second part of lecture switched over again and talked on fusion of telephony and IP networks • Traditional telephony networks are circuit switching networks • More and more real time services are handled over the Internet • Important issue in communication – delay and packet loss (infinite delay)‏ 4 | 51

  5. Communication Systemsplan for this lecture Voice over IP and other multimedia applications demand more bandwidth and realtime Introduction of special multimedia protocols RTP (Real Time Transport Protocol)‏ RTCP (RTP Control Protocol)‏ RSVP (Resource Reservation Protocol)‏ Problems of RSVP and multimedia chanllenges Bandwidth management and Quality of Services Provide QoS control in IP networks, i.e., going beyond best effort to provide some assurance for QoS Later on switch to Internet telephony, introduction to SIP and H.323. 5 | 51

  6. Communication Systemsreal time services • Requirements toward networks for real-time audio and video at least • short delay (delay is composed from several parameters)‏ • enough bandwidth: normally available in backbone networks • But more problematic the (private) end user over low bandwidth connections • During maturing of the Internet bandwidth was often scarce and expensive • many solutions to bandwidth management addressed the whole end-to-end system connection • but most concepts (e.g. the ToS flag in IP header) are not really used • By now: It is often cheaper to add bandwidth than operating sophisticated bandwidth management • But there are scenarios where quality of service (QoS) may improve the whole networks usability ... 6 | 51

  7. Communication Systemsrequirements towards network • Voice over IP and Quality of Service: • Major challenges: delay and delay variation (jitter)‏ • Delay jitter is the variability of source-to-destination delays of packets within the same packet stream • Voice applications are usually interactive • Delay requirement for a telephone system: 150ms-250ms • We identified the sources of delay in a voice over IP system: • OS delay: 10s-100s milliseconds (digitisazion of data, compression and inter software data handling) ... 7 | 51

  8. Source jitter: Network: network conditions vary at different times. Non-real time OS: samples processed at different time Jitter control - buffering at the destination – task of the application used QoS parameters which should be taken into account: Accuracy, latency Jitter and codec quality Depending on codec used a data stream of e.g. ~80kbit/s is generated for each direction (64kbit/s of ISDN PCM plus IP and UDP header)‏ Communication Systemsrequirements towards network 8 | 51

  9. Introduction of a special multimedia protocol Video and audio streaming Defined in RFC 1889, RFC 3550. Used for transporting common formats such as PCM and GSM for sound, and MPEG1 and MPEG2 for video RTP can be viewed as a sublayer of the transport layer Usually on top of UDP 8byte header (faster transfer)‏ No setup overhead like with TCP session no explicit connection handling (left to protocols like SIP) – faster Communication SystemsReal Time Transport Protocol (RTP) 9 | 51

  10. RTP packet header Payload type (7 bits): the type of audio/video encoding Sequence number (16 bits)‏ Time stamp (32 bits): used for jitter removal - derived from a sampling clock at the sender Synchronization Source Identifier (SSRC) (32 bits): identify the source of the RTP stream It is not the IP address of the sender (would violate the layering) but a number that the source assigns randomly when the new stream is started Communication SystemsRTP – packet header 10 | 51

  11. Communication SystemsRTP – header in wireshark 11 | 51

  12. At the sender, the application puts its audio/video data with an RTP header and sends into the UDP socket The application in the receiver extracts the audio/video data from the RTP packet Uses the header fields of the RTP packet to properly decode and playback the audio/video data Helper protocol: RTCP (RTP Control Protocol)‏ RTCP packets do not encapsulate audio/video data Communication SystemsRTP 12 | 51

  13. RTCP packets sent periodically between sender and receivers to gather useful statistics number of packets sent number of packets lost inter arrival jitter RTP and RTCP packets are distinguished from each other through the use of distinct port numbers Communication SystemsRTCP 13 | 51

  14. Communication SystemsRTCP – header in wireshark 14 | 51

  15. RTP needs a bandwidth at least of the rate as packets are sent in each direction Otherwise packet loss or delays will occur and decrease the quality of data stream A special protocol was developed to add service quality parameters to the packet orientated internet RSVP - part of a larger effort to enhance the current Internet architecture with support for Quality of Service flows RFC 2205 RSVP requests will generally result in resources being reserved in each node along the data path Resource we speak of is bandwidth (delay is much more complicated to “reserve” within IP networks)‏ Communication SystemsResource Reservation Protocol (RSVP)‏ 15 | 51

  16. Signaling protocol introduced to reserve bandwidth between a source and its corresponding destination Main features of RSVP are Use of “soft state'' in the routers receiver-controlled reservation requests flexible control over sharing of reservations forwarding of subflows the use of IP multicast for data distribution Source  Destination: RSVP path message Destination  Source: RSVP reserve message Nice try – but ... Communication SystemsRSVP 16 | 51

  17. Routers cannot not store state information about packets – often too slow Simpler technique: mark each packet with a simple flag indicating how to treat it Individual flows are classified into different traffic classes Each router sorts packets into queues via differentiated services (DS) flag Queues get different treatment (e.g. priority, share of bandwidth, probability of discard)‏ Communication SystemsRSVP – problems 17 | 51

  18. Result is coarsely predictable class of service for each “differenciated services” field value Cost of transmission varies by type of service Each traffic class is reserved a defined level of resources, e.g. buffer and bandwidth Different QoS guarantee policies can be applied in different traffic classes When congestion occurs, packets in low priority traffic classes will be dropped first The buffer and the bandwidth in a router for high priority traffic classes are more than low priority traffic classes More scalable than RSVP but cannot allocate resources precisely Communication SystemsRSVP – problems 18 | 51

  19. Most router implementations: Use only First-Come-First-Serve (FCFS) Limited packet processing and transmission scheduling To mitigate impact of “best-effort” protocols, we can: Use UDP to avoid TCP and its slow-start phase… Buffer content at client and control playback to remedy jitter Adapt compression level to available bandwidth Communication Systemsmultimedia challenges 19 | 51

  20. Just add more bandwidth and enhance caching capabilities (over-provisioning)! Need major change of the protocols : Incorporate resource reservation (bandwidth, processing, buffering), and new scheduling policies Set up service level agreements with applications, monitor and enforce the agreements, charge accordingly Need moderate changes (“Differentiated Services”): Use two traffic classes for all packets and differentiate service accordingly Charge based on class of packets Network capacity is provided to ensure first class packets incur no significant delay at routers Communication Systemsmultimedia challenges – solutions 20 | 51

  21. Talked earlier on new protocols like RTP, RTCP and RSVP – concentrate now on bandwidth management IETF groups are working on proposals to provide QOS control in IP networks, e.g., going beyond best effort to provide some assurance for QOS Work in Progress includes RSVP, Differentiated Services, and Integrated Services Simple model for sharing and congestion studies: Communication SystemsQuality of Service (QoS) – intro 21 | 51

  22. Consider a phone application at 1Mbps and an FTP application sharing a 1.5 Mbit/s link. bursts of FTP can congest the router and cause audio packets to be dropped. want to give priority to audio over FTP PRINCIPLE 1: Marking of packets is needed for router to distinguish between different classes; and new router policy to treat packets accordingly Communication SystemsQuality of Service (QoS) – intro 22 | 51

  23. Applications misbehave (audio sends packets at a rate higher than 1Mbit/s assumed above); PRINCIPLE 2: provide protection (isolation) for one class from other classes Require Policing Mechanisms to ensure sources adhere to bandwidth requirements; Marking and Policing need to be done at the edges: Communication SystemsQuality of Service (QoS) – intro 23 | 51

  24. Alternative to Marking and Policing: allocate a set portion of bandwidth to each application flow; can lead to inefficient use of bandwidth if one of the flows does not use its allocation PRINCIPLE 3: While providing isolation, it is desirable to use resources as efficiently as possible Communication SystemsQuality of Service (QoS) – intro 24 | 51

  25. Cannot support traffic beyond link capacity Two phone calls each requests 1 Mbit/s PRINCIPLE 4: Need a Call Admission Process; application flow declares its needs, network may block call if it cannot satisfy the needs Communication SystemsQuality of Service (QoS) – intro 25 | 51

  26. Scheduling: choosing the next packet for transmission FIFO Priority Queue Round Robin Weighted Fair Queuing Communication SystemsQuality of Service (QoS) – packet scheduling 26 | 51

  27. Communication SystemsQuality of Service (QoS) – packet scheduling 27 | 51

  28. Policing mechanisms (Long term) Average Rate 100 packets per sec or 6000 packets per min?? crucial aspect is the interval length Peak Rate: e.g., 6000 p p minute Avg and 1500 p p sec Peak (Max.) Burst Size: Max. number of packets sent consecutively, e.g. over a short period of time Units of measurement Packets versus bits Communication SystemsQuality of Service (QoS) – packet scheduling 28 | 51

  29. Token Bucket mechanism, provides a means for limiting input to specified Burst Size and Average Rate. Bucket can hold b tokens tokens are generated at a rate of r token/sec unless bucket is full of tokens Over an interval of length t, the number of packets that are admitted is less than or equal to (r t + b)‏ Communication SystemsQuality of Service (QoS) – packet scheduling 29 | 51

  30. QoS routing – multiple restraints A request specifies the desired QoS requirements e.g., BW, Delay, Jitter, packet loss, path reliability etc Two type of constraints: Additive: e.g., delay Maximum (or Minimum): e.g., Bandwidth Task Find a (min cost) path which satisfies the constraints if no feasible path found, reject the connection Communication SystemsQuality of Service (QoS) – routing 30 | 51

  31. But often to complicated/impossible to define a path first, so use mechanism on “per-hop-behaviour” (PHB) - simply let routers decide on each hop what to do Big advantage over protocols like RSVP – no state to be kept Give routers hints how to handle different packets Packet is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6 6 bits used for Differentiated Service Code Point (DSCP) and determine PHB that the packet will receive 2 bits are currently unused Communication SystemsQuality of Service (QoS) – classification of packets 31 | 51

  32. It may be desirable to limit traffic injection rate of some class; user declares traffic profile (e.g., rate and burst size); traffic is metered and shaped if non-conforming Communication SystemsQuality of Service (QoS) – classification of packets 32 | 51

  33. PHB result in a different observable (measurable) forwarding performance behavior PHB does not specify what mechanisms to use to ensure required PHB performance behavior Examples: Class A gets x% of outgoing link bandwidth over time intervals of a specified length Class A packets leave first before packets from class B Communication SystemsQuality of Service (QoS) – classification of packets 33 | 51

  34. PHBs under consideration: Expedited Forwarding: departure rate of packets from a class equals or exceeds a specified rate (logical link with a minimum guaranteed rate)‏ Assured Forwarding: 4 classes, each guaranteed a minimum amount of bandwidth and buffering; each with three drop preference partitions But: AF and EF are not even in a standard track yet… research ongoing “Virtual Leased lines” and “Olympic” services are being discussed Impact of crossing multiple ASs and routers that are not DS-capable Communication SystemsQuality of Service (QoS) – classification of packets 34 | 51

  35. The Linux kernel provides a framework for implementing a queuing policy: “Queuing Disciplines” or qdisc. A qdisc is an abstract programming interface, defining a set of functions which every policy has to implement: e.g. enqueue() and dequeue()‏ Every network device has one qdisc associated. It acts as an buffer and controls physical transmission. The iproute2 package is used to handle traffic classes: tc command Linux packet filter is able to mark packets – so they could be handled later in QoS queues: iptables command Communication SystemsQuality of Service (QoS) – Linux implementation 35 | 51

  36. Communication SystemsQuality of Service (QoS) – Linux implementation • Linux supports 3 kinds of qdisc implementations • Classless qdisc shape traffic for an entire interface, without any subdivisions. • FIFO, Stochastic Fair Queuing (SFQ)‏ • Class based qdisc support shaping policies for different network traffic classes. But usually have a fixed number of classes or fixed class types. • Token Bucket Filter (TBF), PRIO • Hierarchical class based qdisc implementations, allow a custom number of classes and custom class types. • Hierarchical Token Bucket (HTB)‏ • Hierarchical Fair Service Curve Packet Scheduler (HFSC)‏ 36 | 51

  37. Communication SystemsClassless queueing • pfifo_fast • The queue has 3 bands. Within each band, FIFO rules apply. • Band 1 is only able to send, if band 0 is empty. Band 2 only if 0 and 1 are empty. • Classification is done automatically, based on the value in the DS-Field of the IP header. RFC 2474 describes the behavior in more detail. • pfifo_fast is the default qdisc if no qdisc is specified. • Stochastic Fairness Queueing (SFQ)‏ • Traffic is divided into a number of FIFO queues (e.g. 127) using hashing algorithm (hence stochastic). • Traffic is then sent in a round robin fashion, giving each connection the chance to send data in turn. • Only “stochastic” fairness guarantied, because of the limited number of queues and imperfect hash algorithms. 37 | 51

  38. Communication SystemsClass based queuing • When the traffic enters a class based qdisc, it needs to be classified according to the user defined 'filters'. • PRIO (Priority queuing)‏ • Works like pfifo_fast, but has no automatic classification. • Supports up to 16 classes (bands). • When a packet is enqueued to the PRIO qdisc, a class is chosen based on the filters. • For every band a inner qdisc can be set. E.g. assign a SFQ qdisc to provide fairness among all connections enqueued in a single PRIO-band. • Very useful in case you want to prioritize certain kinds of traffic, without using only DS-bits but using all the power of the tc filters. 38 | 51

  39. Communication SystemsClass based queuing • Token Bucket Filter (TBF)‏ • Only passes packets arriving at a rate which is not exceeding the administratively set rate. But allow short bursts in excess of this rate. • Has a buffer (bucket), constantly filled by tokens, at a specific rate (token rate). Each arriving token collects one incoming data packet from the data queue and is then deleted from the bucket. • Has a single inner class. • e.g. add SFQ as inner class to ensure fairness among all waiting connections. 39 | 51

  40. Communication SystemsClassful queueing • Class Based Queuing (CBQ)‏ • One of the most complex qdisc available. • Implement shaping by measuring effective idletime, to make sure that the link is idle just long enough to bring down the real bandwidth to the configured rate. • Subdivides traffic based on filters. • When sending out a packet, uses a weighted round robin process ('WRR'), beginning with the lower-numbered priority classes. 40 | 51

  41. Communication SystemsHierarchical class based queuing • Hierarchical Token Bucket (HTB)‏ • CBQ is complex and does not seem to be optimized for many typical situations. • HTB is well suited for setups where • you have a fixed amount of bandwidth • you want to divide the bandwidth for different traffics and give each traffic a guaranteed bandwidth • and specify how much bandwidth can be borrowed. • HTB works just like CBQ but does not resort to idle time calculations to shape. • Instead, it is a class based Token Bucket Filter supporting a class hierarchy. 41 | 51

  42. Communication SystemsHierarchical class based queuing • Hierarchical Fair Service Curve Packet Scheduler (HFSC)‏ • When network access is used by multiple entities or for different services, then some sort of reasonable resource management is required. • The assurance of minimum bandwidth for the individual services and users (link-sharing) is one possible solution. • For scenarios involving VoIP or streaming services, both pure bandwidth allocation and also prevention of high delaysbecome important. 42 | 51

  43. Communication SystemsHierarchical class based queuing • Imagine the following scenario: • Two users share a single Internet connection with a 1000 kbit/s capacity. • Each user should have control of at least 500 kbit/s of that capacity at any given moment. • One of the users (A) uses a maximum of 100 Kbit/s of his bandwidth for Internet telephony (VoIP) and the remainder of the transmission capacity for general data transport (bulk). 43 | 51

  44. Communication SystemsHierarchical class based queuing 44 | 51

  45. Communication SystemsHierarchical class based queuing • Assume for now, that all packets to be sent conform to a fixed size of 1500 bytes and all classes are sending at maximum rate (if possible). • Based on the 1000 kbit/s link capacity, it takes 12 ms to send a packet. • 8 bits * 1500 bytes / 1000000 bit/s = 12 ms • Assume the VoIP application sends at 100 kbit/s, which correspondents to ~8 packets per second. • Therefore the qdisc must send a packet every 120 ms in order to meet the guaranteed 100 kbit/s, which would mean a max. delay of 132 ms. • This example demonstrates the tight coupling between bandwidth and delays. 45 | 51

  46. Communication SystemsHierarchical class based queuing • The HFSC algorithm is in a position to deal with both of these resources, bandwidth and delay. • It uses the service curve model for allocation of resources. • A service curve S(t) represents the work achieved (service) in bits at time t. • The slope of the curve corresponds to the rate of transmission. 46 | 51

  47. Communication SystemsHierarchical class based queuing • With the numbers from the previous example: arrival time departure time 47 | 51

  48. Communication SystemsHierarchical class based queuing • The concept of the interaction with latency resides in the structure of the service curves of the individual classes. • By selecting a two-part service curve, each section of which is linear, the transmission delay for the VoIP class can be reduced to 30 ms. • The first section of the service curve features a 400 kbit/s slope of 30 ms duration, where the second section exhibits a slope of 100 kbit/s. • This gain in decreased delay of approximately 78 ms is earned at the expense of other classes. • At no point, though, is the sum of the curves allowed to exceed the service curve of the total link capacity. 48 | 51

  49. Communication SystemsHierarchical class based queuing • With the updated numbers from the previous example: arrival time departure time 49 | 51

  50. Communication SystemsHierarchical class based queuing • In our example, the decreased delay for the Voice over IP class occurs at the cost of party A's unspecified data class, whose service curve must be adjusted in order not to to exceed the global limit. • As a result, the maximum transmission delay of this class increases from 30 ms to a total of 52.5 ms. • For bulk data transport, such as FTP, for example, delay simply plays a secondary role in contrast to that of throughput, which isn't impaired by modifying its service curve. 50 | 51

More Related