1 | 51
Communication Systems16th lecture
Chair of Communication SystemsDepartment of Applied Sciences
University of Freiburg2008
2 | 51
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)
3 | 51
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
4 | 51
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)
5 | 51
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.
6 | 51
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 ...
Communication Systemsreal time services
7 | 51
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) ...
Communication Systemsrequirements towards network
8 | 51
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
9 | 51
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)
10 | 51
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
11 | 51
Communication SystemsRTP – header in wireshark
12 | 51
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
13 | 51
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
14 | 51
Communication SystemsRTCP – header in wireshark
15 | 51
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)
16 | 51
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
17 | 51
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
18 | 51
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
19 | 51
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
20 | 51
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
21 | 51
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
22 | 51
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
23 | 51
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
24 | 51
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
25 | 51
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
26 | 51
Scheduling: choosing the next packet for transmission FIFO
Priority Queue
Round Robin
Weighted Fair Queuing
Communication SystemsQuality of Service (QoS) – packet scheduling
27 | 51
Communication SystemsQuality of Service (QoS) – packet scheduling
28 | 51
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
29 | 51
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
30 | 51
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
31 | 51
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
32 | 51
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
33 | 51
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
34 | 51
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
35 | 51
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
36 | 51
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)
37 | 51
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.
Communication SystemsClassless queueing
38 | 51
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.
39 | 51
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.
40 | 51
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.
Communication SystemsClassful queueing
41 | 51
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.
Communication SystemsHierarchical class based queuing
42 | 51
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 delays become important.
Communication SystemsHierarchical class based queuing
43 | 51
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).
Communication SystemsHierarchical class based queuing
44 | 51
Communication SystemsHierarchical class based queuing
45 | 51
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.
Communication SystemsHierarchical class based queuing
46 | 51
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.
Communication SystemsHierarchical class based queuing
47 | 51
With the numbers from the previous example:
Communication SystemsHierarchical class based queuing
arrival time departure time
48 | 51
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.
Communication SystemsHierarchical class based queuing
49 | 51
With the updated numbers from the previous example:
Communication SystemsHierarchical class based queuing
arrival time departure time
50 | 51
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.
Communication SystemsHierarchical class based queuing
51 | 51
The HFSC algorithm differentiates between real-time and link-sharing criteria.
A leaf class can be assigned a real-time and a link-sharing curve, where inner classes can only have a link-sharing curve.
The real-time criterion can only be applied to leaf classes because only these classes actually hold packets.
This real-time oriented criterion is therefore responsible for carrying out the guaranteed service.
The link-sharing criterion only concerns itself with relationships to neighboring classes. It is responsible for fair distribution of service rather than absolute guarantees.
This separation into two criteria is necessary in order to be able to meet the guaranteed delay times under all circumstances.
Communication SystemsHierarchical class based queuing
52 | 51
This also means that a class can send a packet on the basis of its real-time guarantee even if the link-sharing curve of a class higher in the hierarchy is briefly violated.
Assume our example data class from party A is already active and sending at its maximum packet rate, 400 kbit/s.
Now the VoIP class becomes active. It is allowed to send with a higher rate on account of its real-time guarantee.
Thus, the service for class A, totals to above 500 kbit/s, meaning that the link-sharing parameter for this class has been violated in the short term.
In order to be able to carry out the link-sharing guarantees over the long term, class A will be "punished" for this brief excess.
Communication SystemsHierarchical class based queuing
53 | 51
Communication SystemsHierarchical class based queuing
Between t1 and t2, exceeds the total maximum allowed capacity.
54 | 51
Each of the classes in the hierarchy is assigned a "virtual time", which corresponds to service actually attained.
As soon as it is possible to send a packet, each level of the hierarchy is searched, starting at the root, for the class exhibiting the least attained virtual time.
The leaf class found with this method then sends a packet and the virtual time of that class, along with each of its parent classes all the way up to the root, will be increased accordingly.
If a class sends based on its real-time parameter, its virtual time will also be increased.
Communication SystemsHierarchical class based queuing
55 | 51
In most cases bandwidth suffices But you may have to connect a flatsharing community of students
over a single DSL line
Provide Internet services for a student dormitory over a WLAN link with limited capacity
Congested lines may render the whole service unusable SSH gets unbearable delays
Maildownload via POP or IMAP takes hours
Even filesharing does not work – ACK to downloaded packets have to wait to long ...
Communication SystemsQuality of Service (QoS) – conclusion
56 | 51
Adding capacity is often not an issue, but you can experiment with QoS on a linux machine used as a router many embedded router devices use linux as OS they often offer basic features for QoS / traffic shaping or
these features could be added by end user (alternative firmwares for such routers, e.g. for the popular Linksys WRT54G(S)
That way you might solve a range of bandwidth related problems without the need to upgrade the connection
Nevertheless at corporate level it is often cheaper just to add bandwidth than starting a sophisticated QoS management on switch and IP level
Communication SystemsQuality of Service (QoS) – conclusion
57 | 51
Switch to internet telephony Security
reduced costs might induce new type of SPAM – spit (spam over internet telephony)
how to know that the caller is the one he claims to, same for the called partner
Compatibility to existing services routing of emergency calls location of emergency
Presence rebustness of servers and “routes” permanent updates of clients (mobile devices move from
network to network)
Communication SystemsInternet telephony - requirements
58 | 51
Voice over IP should offer higher robustness (e.g. alternate routes) better voice quality mobility, multimedia and conferencing secure communication gateways to other telephone systems (GSM, UMTS, PSTN) 100% open standards
hope of a combination of lower costs with better functionality
Communication SystemsInternet telephony - requirements
59 | 51
Communication SystemsInternet telephony – infrastructure (idialized :-))
60 | 51
Requirements by VoIP services enough bandwidth for digitized audio stream (both directions!) minimal jitter and noise
Two main VoIP standards H.323 – standard developed by Telcos - ITU SIP – internet standard
SIP is session initialization protocol developed by Henning Schulzrinne (Feb. 1999) IETF Standard RFC 2543 (March 1999) current: RFC 3261 (June 2002)
Communication SystemsInternet telephony - standards
61 | 51
H.32x series defines not only VoIP but classical telephony too (H.324) and ISDN (H.320)
1996 the first version 1 was introduced, today modern equipment is using version 5
family of protocols: defines the transmission of multimedia content in realtime over unreliable networks
protocol suite consists of several modules: terminal, gateway, gatekeeper, MCU (multipoint controller unit)
Communication SystemsInternet telephony - standards
62 | 51
Handle rather the same type of services H.323 was developed for telecommunication, not primerily for IP
networks SIP is directly focused for the Internet use H.323 is able to handle video conferences and offers more
complex telephony functions SIP much simpler, but clearer and easier to understand/implement,
scales better SIP might take over, but many products implement H.323 so it is
not dead by now More on Internet telephony in the next lecture...
Communication SystemsInternet telephony – H.323 v. SIP
63 | 51
RSVP http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/rsvp.htm
QoS Queueing Disciplines for Bandwidth Management:
http://lartc.org/howto/lartc.qdisc.html
For additional literature check the last practical exercise slides!
Communication SystemsLiterature