communication systems 16 th lecture

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


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:


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


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


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


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


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)


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


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


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


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.


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).


44 | 51


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.


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.


47 | 51

With the numbers from the previous example:


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.


49 | 51

With the updated numbers from the previous example:


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.


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.


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.


53 | 51


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.


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

communication systems 16 th lecture

Documents

internet bandwidth

communication delay

parametersenough bandwidth

leastshort delay delay

networks usability

network fusionlast lecture

internet telephony

ip header