Transcript Communication Systems 15th lecture

Communication Systems
16th lecture
Chair of Communication Systems
Department of Applied Sciences
University of Freiburg
2008
1 | 51
Communication Systems
Lecture 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
Communication Systems
Last 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
Communication Systems
Last 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
Communication Systems
plan 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
Communication Systems
real 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 endto-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
Communication Systems
requirements 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
Communication Systems
requirements towards network




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)
8 | 51
Communication Systems
Real Time Transport Protocol (RTP)






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
9 | 51
Communication Systems
RTP – packet header

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
10 | 51
Communication Systems
RTP – header in wireshark
11 | 51
Communication Systems
RTP





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
12 | 51
Communication Systems
RTCP


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
13 | 51
Communication Systems
RTCP – header in wireshark
14 | 51
Communication Systems
Resource Reservation Protocol (RSVP)







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)
15 | 51
Communication Systems
RSVP





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 ...
16 | 51
Communication Systems
RSVP – problems





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)
17 | 51
Communication Systems
RSVP – problems




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
18 | 51
Communication Systems
multimedia challenges


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
19 | 51
Communication Systems
multimedia challenges – solutions



Just add more bandwidth and enhance caching capabilities (overprovisioning)!
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
20 | 51
Communication Systems
Quality of Service (QoS) – intro




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:
21 | 51
Communication Systems
Quality of Service (QoS) – intro


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
22 | 51
Communication Systems
Quality of Service (QoS) – intro



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:
23 | 51
Communication Systems
Quality of Service (QoS) – intro


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
24 | 51
Communication Systems
Quality of Service (QoS) – intro


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
25 | 51
Communication Systems
Quality of Service (QoS) – packet scheduling

Scheduling: choosing the next packet for transmission

FIFO

Priority Queue

Round Robin

Weighted Fair Queuing
26 | 51
Communication Systems
Quality of Service (QoS) – packet scheduling
27 | 51
Communication Systems
Quality of Service (QoS) – packet scheduling

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
28 | 51
Communication Systems
Quality of Service (QoS) – packet scheduling



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)
29 | 51
Communication Systems
Quality of Service (QoS) – routing



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
30 | 51
Communication Systems
Quality of Service (QoS) – classification of packets





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
31 | 51
Communication Systems
Quality of Service (QoS) – classification of packets

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
32 | 51
Communication Systems
Quality of Service (QoS) – classification of packets



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
33 | 51
Communication Systems
Quality of Service (QoS) – classification of packets




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 DScapable
34 | 51
Communication Systems
Quality of Service (QoS) – Linux implementation





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
35 | 51
Communication Systems
Quality of Service (QoS) – Linux implementation

Linux supports 3 kinds of qdisc implementations
 Classless qdisc shape traffic for an entire interface, without
any subdivisions.


Class based qdisc support shaping policies for different
network traffic classes. But usually have a fixed number of
classes or fixed class types.


FIFO, Stochastic Fair Queuing (SFQ)
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
Communication Systems
Classless 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
Communication Systems
Class 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
Communication Systems
Class 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
Communication Systems
Classful 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
Communication Systems
Hierarchical 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
Communication Systems
Hierarchical 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 delays
become important.
42 | 51
Communication Systems
Hierarchical 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
Communication Systems
Hierarchical class based queuing
44 | 51
Communication Systems
Hierarchical 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
Communication Systems
Hierarchical 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
Communication Systems
Hierarchical class based queuing

With the numbers from the previous example:
arrival time
departure time
47 | 51
Communication Systems
Hierarchical 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
Communication Systems
Hierarchical class based queuing

With the updated numbers from the previous example:
arrival time
departure time
49 | 51
Communication Systems
Hierarchical 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
Communication Systems
Hierarchical class based queuing






The HFSC algorithm differentiates between real-time and linksharing 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.
51 | 51
Communication Systems
Hierarchical class based queuing





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.
52 | 51
Communication Systems
Hierarchical class based queuing
Between t1 and t2, exceeds the total maximum allowed capacity.
53 | 51
Communication Systems
Hierarchical class based queuing




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.
54 | 51
Communication Systems
Quality of Service (QoS) – conclusion


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 ...
55 | 51
Communication Systems
Quality of Service (QoS) – conclusion

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
56 | 51
Communication Systems
Internet telephony - requirements




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)
57 | 51
Communication Systems
Internet telephony - requirements


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
58 | 51
Communication Systems
Internet telephony – infrastructure (idialized :-))
59 | 51
Communication Systems
Internet telephony - standards

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)


60 | 51
Communication Systems
Internet telephony - standards




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)
61 | 51
Communication Systems
Internet telephony – H.323 v. SIP







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...
62 | 51
Communication Systems
Literature

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!
63 | 51