T-110.5116 Computer Networks II Quality of Service

21.11.2011 Matti Siekkinen

(Main source: J. Kurose, K. Ross: “Computer Networking: A Top Down Approach”)

November 21, 11

Q & A for summary lecture

 Q & A for summary lecture 5.12.   Prepare and send me questions by email   Questions are treated anonymously   We will go through the questions during the last session

 Assignment grading almost done   No failed reports   Results probably this week

2

November 21, 11

Outline  What is QoS?

  Overview of QoS mechanisms  Application level techniques

  Media streaming example case o  Client or server based techniques

  Overlays o  RON, CDN

 Network-layer techniques   Offering multiple classes of service

o  Scheduling and policing packets, DiffServ   Providing QoS guarantees

o  Resource reservation, RSVP, IntServ  Conclusions

November 21, 11

What is Quality of Service?

 Many applications are sensitive to delay, jitter, and packet loss   Too high values makes utility drop to zero

 Some mission-critical applications cannot tolerate disruption   VoIP   high-availability computing

 Charge more for business applications vs. consumer applications

 Related concept is service availability   How likely is it that I can place a call and not get interrupted?   requires meeting the QoS requirements for the given

application

November 21, 11

Example QoS Requirements

Personal voice over IP Network

monitoring

CEO Video conference with analysis

Financial Transactions

Interactive whiteboard

Unicast radio

Network management traffic Extranet

web traffic Public web traffic

Push news

Personal e-mail

Business e-mail

Server backups

Sensitive

Insensitive

Casual Critical

Delay

Mission Criticality

November 21, 11

QoS in Today’s Internet TCP/UDP/IP: “best-effort service”  no guarantees on delay, loss

Today’s Internet applications use application-level techniques to mitigate

(as best possible) effects of delay, loss

But some apps (multimedia) require QoS and level of performance to be

effective!

? ? ? ? ?

?

? ? ?

?

?

November 21, 11

How should the Internet evolve to better support QoS?

Integrated services philosophy:   fundamental changes in

Internet so that apps can reserve end-to-end bandwidth

  requires new, complex software in hosts & routers

Laissez-faire   no major changes   more bandwidth when

needed   content distribution,

application-layer multicast   application layer

Differentiated services philosophy:

  fewer changes to Internet infrastructure, yet provide 1st and 2nd class service

What’s your opinion?

November 21, 11

QoS Mechanisms: classification

 Provisioning   Admission control

o  Prohibit or allow new flows to enter the nw   Resource reservation

 Control   Operate on short time scales   Real-time traffic or flow control

o  E.g. scheduling, shaping, policing...  Management

  Monitor the QoS   Longer time scales than control

November 21, 11

QoS Mechanisms

Packet Scheduling

Admission Control

Traffic Shaping

(Users get their share of bandwidth) (Amount of traffic

users can inject into the network)

(To accept or reject a flow based on flow specifications)

Core

Adapt application behavior

November 21, 11

QoS Control Mechanisms

 Application-level techniques   Application adapts to network conditions   Use overlays

 Transport-layer techniques   Adapt transport protocols to application requirements

and network conditions   TCP, DCCP

 Network-layer techniques   Scheduling (FIFO, WFQ)   Queue mgmt (drop-tail, RED)   Policing (leaky/token bucket)

Make the best out of best effort

November 21, 11

Outline  What is QoS?

  Overview of QoS mechanisms  Application level techniques

  Media streaming example case o  Client or server based techniques

  Overlays o  RON, CDN

 Network-layer techniques   Offering multiple classes of service

o  Scheduling and policing packets, DiffServ   Providing QoS guarantees

o  Resource reservation, RSVP, IntServ  Conclusions

November 21, 11

Example case: Multimedia networking

 Streaming stored multimedia  Interactive real time media

November 21, 11

Streaming stored media application-level streaming

techniques for making the best out of best effort service:   client-side buffering   use of UDP versus TCP   multiple encodings of

multimedia

  jitter removal   decompression   error concealment

Media Player

November 21, 11

constant bit rate video transmission

Cum

ulat

ive

data

time

variable network

delay (jitter)

client video reception

constant bit rate video playout at client

client playout delay

buff

ered

vi

deo

Client buffering and jitter

 client-side buffering, playout delay compensate for network-added jitter

November 21, 11

Client Buffering

  Client-side buffering, playout delay compensate for network-added jitter

  Usually Fast Start used to fill buffer quickly   Not possible with live streaming

buffered video

variable fill rate, x(t)

constant drain rate, d

November 21, 11

Streaming: UDP or TCP?

UDP  server sends at rate appropriate for client (oblivious to

network congestion !)   often send rate = encoding rate = constant rate   then, fill rate = constant rate - packet loss

 short playout delay (2-5 seconds) to remove network jitter

 error recover: time permitting TCP  send at maximum possible rate under TCP  fill rate fluctuates due to TCP congestion control   larger playout delay: smooth TCP delivery rate  HTTP/TCP passes more easily through firewalls

November 21, 11

Streaming Multimedia: client rate(s)

Q: how to handle different client receive rate capabilities?  28.8 Kbps dialup   100 Mbps Ethernet

A: server stores, transmits multiple copies of video, encoded at different rates

1.5 Mbps encoding

28.8 Kbps encoding

Trade stream quality to resource requirements

November 21, 11

Real-time interactive applications   PC-2-PC

  Skype   Google Voice

  PC-2-phone   Dialpad   Net2phone   Skype   Google Voice

  videoconference with webcams   Skype   Polycom   (Google Voice)

Going to now look at a PC-2-PC Internet phone example in detail

November 21, 11

Interactive Multimedia: Internet Phone

 speaker’s audio: alternating talk spurts, silent periods.   64 kbps during talk spurt   pkts generated only during talk spurts   20 msec chunks at 8 Kbytes/sec: 160 bytes

data  application-layer header added to each chunk.  chunk+header encapsulated into UDP segment.  application sends UDP segment into socket every

20 msec during talk spurt

November 21, 11

Internet Phone: Packet Loss and Delay

 network loss: IP datagram lost due to network congestion (router buffer overflow)

 delay loss: IP datagram arrives too late for playout at receiver   delays: processing, queueing in network; end-

system (sender, receiver) delays   typical maximum tolerable delay: 400 ms

 loss tolerance: depending on voice encoding, losses concealed, packet loss rates between 1% and 10% can be tolerated.

November 21, 11

Internet Phone: Fixed Playout Delay

 receiver attempts to playout each chunk exactly q msecs after chunk was generated.   chunk has time stamp t: play out chunk at t+q .   chunk arrives after t+q: data arrives too late

for playout, data “lost”  tradeoff in choosing q:

  large q: less packet loss   small q: better interactive experience

November 21, 11

Fixed Playout Delay

  sender generates packets every 20 msec during talk spurt.   first packet received at time r   first playout schedule: begins at p   second playout schedule: begins at p’

November 21, 11

Adaptive Playout Delay (1)

dynamic estimate of average delay at receiver:

where u is a fixed constant (e.g., u = .01).

  Goal: minimize playout delay, keeping delay loss rate low   Approach: adaptive playout delay adjustment:

  estimate network delay, adjust playout delay at beginning of each talk spurt.

  silent periods compressed and elongated.   chunks still played out every 20 msec during talk spurt.

November 21, 11

Adaptive playout delay (2)

  also useful to estimate average deviation of delay, vi :

  estimates di , vi calculated for every received packet but used only at start of talk spurt

  for first packet in talk spurt, playout time is:

where K is positive constant

  remaining packets in talk spurt are played out periodically

November 21, 11

Adaptive Playout (3)

Q: How does receiver determine whether packet is first in a talkspurt?

 if no loss, receiver looks at successive timestamps.   difference of successive stamps > 20 msec -->talk

spurt begins.  with loss possible, receiver must look at both time

stamps and sequence numbers.   difference of successive stamps > 20 msec and

sequence numbers without gaps --> talk spurt begins.

November 21, 11

Recovery from packet loss (1) Forward Error Correction (FEC): simple scheme   for every group of n chunks create redundant chunk by

exclusive OR-ing n original chunks   send out n+1 chunks, increasing bandwidth by factor 1/n.   can reconstruct original n chunks if at most one lost chunk

from n+1 chunks   playout delay: enough time to receive all n+1 packets   tradeoff:

  increase n, less bandwidth waste   increase n, longer playout delay   increase n, higher probability that 2 or more chunks will be

lost

November 21, 11

Recovery from packet loss (2) 2nd FEC scheme   “piggyback lower quality stream”   send lower resolution audio stream as redundant information   e.g., nominal stream at 64 kbps and redundant stream at 16 kbps.

  whenever there is non-consecutive loss, receiver can conceal the loss.   can also append (n-1)st and (n-2)nd low-bit rate chunk

November 21, 11

Recovery from packet loss (3)

Interleaving   chunks divided into smaller

units   for example, four 5 msec units

per chunk   packet contains small units

from different chunks

  if packet lost, still have most of every chunk

  no redundancy overhead, but increases playout delay

November 21, 11

Outline  What is QoS?

  Overview of QoS mechanisms  Application level techniques

  Media streaming example case o  Client or server based techniques

  Overlays o  RON, CDN

 Network-layer techniques   Offering multiple classes of service

o  Scheduling and policing packets, DiffServ   Providing QoS guarantees

o  Resource reservation, RSVP, IntServ  Conclusions

November 21, 11

Overlay solutions

 QoS can also be provided by using overlay solutions (application layer)

 Consider   Overlay node placement wrt. network topology   Replication

 Examples   RON Reliable Overlay Network   Content distribution networks (CDN)

30

November 21, 11 31

RON: Resilient Overlay Networks Claim: building an application overlay network can increase

performance and reliability of routing "Because, sometimes, the Internet doesn't quite work..."

Two-hop (application-level) Berkeley-to-Princeton route

application-layer router

Princeton Yale

Berkeley

November 21, 11

RON

 Overlay nodes cooperatively monitor path quality to each other   Probing

 Nodes decide whether to   allow packets go through to destination   or reroute them via another node

 Applications must explicitly support the use of RON

32

November 21, 11 33

Can RON outperform IP Routing?

 IP routing does not adapt to congestion   But RON can reroute when the direct path is congested

 IP routing is sometimes slow to converge   But RON can quickly direct traffic through intermediary

 IP routing depends on AS routing policies   But RON may pick paths that circumvent policies

 RON introduces overhead   Packets go in and out at intermediate nodes

o  Performance degradation, load on hosts, and financial cost   Probing overhead to monitor the virtual links

o  Limits RON to deployments with a small number of nodes  What if all applications start to use RON?

November 21, 11

Content distribution networks (CDNs)

Content replication   challenging to stream large

files (e.g., video) from single origin server in real time

  solution: replicate content at hundreds of servers throughout Internet   content downloaded to CDN

servers ahead of time   placing content “close” to

user avoids impairments (loss, delay) of sending content over long paths

  CDN server typically in edge/access network

origin server in North America

CDN distribution node

CDN server in S. America CDN server

in Europe

CDN server in Asia

November 21, 11

Content distribution networks (CDNs)

Content replication  CDN (e.g., Akamai)

customer is the content provider (e.g., CNN)

 CDN replicates customers’ content in CDN servers.

 when provider updates content, CDN updates servers

origin server in North America

CDN distribution node

CDN server in S. America CDN server

in Europe

CDN server in Asia

• November 21, 11

CDN example

origin server (www.foo.com)  distributes HTML  replaces: http://www.foo.com/sports.ruth.gif

with http://www.cdn.com/www.foo.com/sports/ruth.gif

CDN company (cdn.com) ❒  distributes gif files ❒  uses its authoritative

DNS server to route redirect requests

HTTP request for www.foo.com/sports/sports.html

DNS query for www.cdn.com

HTTP request for www.cdn.com/www.foo.com/sports/ruth.gif

1

2

3

origin server

CDN’s authoritative DNS server

CDN server near client

client

November 21, 11

More about CDNs routing requests  CDN creates a “map”, indicating distances from

leaf ISPs and CDN nodes  when query arrives at authoritative DNS server:

  server determines ISP from which query originates   uses “map” to determine best CDN server

 CDN nodes create application-layer overlay network

November 21, 11

Outline  What is QoS?  Overview of QoS mechanisms  Application level techniques

  Media streaming example case o  Client or server based techniques

  Overlays o  RON, CDN

 Network-layer techniques   Offering multiple classes of service

o  Scheduling and policing packets, DiffServ   Providing QoS guarantees

o  Resource reservation, RSVP, IntServ  Conclusions

November 21, 11

Providing Multiple Classes of Service  So far: making the best of best effort service

  one-size fits all service model  alternative: multiple classes of service

  partition traffic into classes   network treats different classes of traffic differently

(analogy: VIP service vs regular service)

0111

 granularity: differential service among multiple classes, not among individual connections

 history: ToS bits in IP header

November 21, 11

Multiple classes of service: scenario

R1 R2 H1

H2

H3

H4 1.5 Mbps link R1 output

interface queue

November 21, 11

Principles for QoS differentiation  Example: 1Mbps IP video phone, FTP share 1.5 Mbps

link.   bursts of FTP can congest router, cause audio/video loss   want to give priority to audio/video over FTP

packet marking needed for router to distinguish between different classes; and new router policy to treat packets accordingly

Principle 1

R1 R2

November 21, 11

Principles for QoS differentiation (more)

 what if applications misbehave? (audio/video sends higher than declared rate)   policing: force source adherence to bandwidth allocations

 marking and policing at network edge:

provide protection (isolation) for one class from others Principle 2

R1 R2

1.5 Mbps link

1 Mbps phone

packet marking and policing

November 21, 11

Principles for QoS differentiation (more)

 Allocating fixed (non-sharable) bandwidth to flow is inefficient use of bandwidth if flows don’t use their allocation

While providing isolation, use resources as efficiently as possible

Principle 3

R1 R2

1.5 Mbps link

1 Mbps phone

1 Mbps logical link

0.5 Mbps logical link

November 21, 11

Mechanisms for QoS differentiation

 Scheduling mechanisms   Routers buffer arriving packets in queue(s)   Scheduling: router chooses which packet to forward

next from many possible ones   Many different scheduling policies possible

 Policing mechanisms   Router forwards only packets that agree to specified

policy parameters   Provide protection/isolation between classes of flows

o  Enforce ”good behavior”

44

November 21, 11

Scheduling Mechanisms

 scheduling: choose next packet to send on link  FIFO (first in first out) scheduling: send in order

of arrival to queue   The most widely used in the Internet

November 21, 11

Scheduling: more Priority scheduling: transmit highest priority

queued packet  multiple classes, with different priorities

  class may depend on marking or other header info, e.g. IP source/dest, port numbers, etc..

November 21, 11

Scheduling: still more round robin scheduling:  multiple classes  cyclically scan class queues, serving one from

each class (if available)

November 21, 11

Scheduling: still more Weighted Fair Queuing:  generalized Round Robin  each class gets weighted amount of service in

each cycle

November 21, 11

Drop policy   If packet arrives to full queue, which one to discard?

  Tail drop: drop arriving packet   priority: drop/remove on priority basis   random: drop/remove randomly

  RED = Random Early Detection, a.k.a. Random Early Drop   When queue length exceeds a drop level -> drop each arriving

packet with a fixed probability p   Advantages

o  Avoids global synchronization where all TCP connections back off at the same time

o  Sources don’t have to react to transient congestion   Problems

o  Not suitable as such for QoS differentiation (WRED proposed) o  Vulnerable to LDOS

•  Low rate attack stream with carefully scheduled periodic short bursts •  Cause “lock out” of legitimate flows via successive TCP timeouts

p Drop level

November 21, 11

Policing Mechanisms  Goal: limit traffic to not exceed declared parameters  Three commonly used criteria:

  (Long term) Average Rate: how many pkts can be sent per unit time (in the long run)

o  crucial question: what is the interval length: 100 packets per sec or 6000 packets per min have same average!

  Peak Rate: e.g., 6000 pkts per min. (ppm) avg.; 1500 pps peak rate

  (Max.) Burst Size: max. number of pkts sent consecutively (with no intervening idle)

 Mechanisms   Leaky bucket   Token bucket

November 21, 11

Policing: Leaky Bucket

 Enforces a constant output rate  Levels out any incoming bursts

of packets  Can be used to limit peak rates

51

Leaky Bucket

Water drips out of the hole at constant rate

Packets out

Packets in

Regulated flow

Unregulated flow

November 21, 11

Policing: Token Bucket   Limit input to specified burst size and average rate

  bucket can hold b tokens   tokens generated at rate r token/sec unless bucket full   over interval of length t: number of packets admitted less

than or equal to (r*t + b)   b limits max burst size Smax   avg rate limited by r*t

  Does not bound the peak rate of bursts smaller than Smax   Bucket contains enough tokens to cover a complete burst size

Smax = b(1+r/(C-r)), where C is output link capacity

November 21, 11

Policing: Token Bucket

 What to do with packets without tokens?  Token Bucket can be used to shape, police, or mark

  Delay pkts from entering net until token available (shaping)   Drop pkts that arrive without tokens (policing)   Let all pkts pass through, mark ones without tokens

o  Network drops pkts without tokens in time of congestion

November 21, 11

IETF Differentiated Services  Want “qualitative” service classes

  “behaves like a wire”   Relative service distinction: Platinum, Gold, Silver

 Scalability:   Simple functions in network core   Complex functions at edge routers (or hosts)   No per-flow router state maintained at core

o  Difficult with large number of flows  Flexibility:

  New service classes arise, old may become obsolete   Don’t define define service classes but provide

functional components to build them

November 21, 11

Core router:   per class traffic

management   buffering and scheduling

based on marking at edge   Per Hop Behaviors (PHB)   no per-flow states

Diffserv Architecture Edge router:   per-flow traffic management  marks packets to classes   could also be done by the host

scheduling

. . .

r

b

marking

November 21, 11

Edge-router packet marking

 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

November 21, 11

Edge-router packet marking

User packets

Rate A

B

Example:   Profile: pre-negotiated rate A, bucket size B   Packet marking at edge based on per-flow

profile

Possible usage of marking:  Packets of different classes marked differently

  E.g. different applications  Conforming portion of flow marked differently than non-

conforming one

November 21, 11

Classification and conditioning

 Traffic metering could be done before/after classification

 Check if traffic conforms to agreed traffic profile (e.g., rate, burst size)

 Depending on conformance can shape, police(drop), or mark differently

November 21, 11

Core router Per-Hop Behavior (PHB)

 PHB result in a different observable forwarding performance behavior   Must be measurable differences

 Mechanisms to use to enforce PHB not specified   Can do it as you want

 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

November 21, 11

Forwarding (PHB)

PHBs currently defined:  Expedited Forwarding: pkt departure rate of a class

equals or exceeds specified rate   logical link with a minimum guaranteed rate

 Assured Forwarding: 4 classes of traffic   each guaranteed minimum amount of bandwidth   each with three drop preference partitions

November 21, 11

Expedited Forwarding

  Expedited packets experience a traffic-free network (low loss, low latency, low jitter, and assured bandwidth (premium service)

 Strict priority queuing

61

November 21, 11

Assured Forwarding  AF PHB delivers the packet with high assurance as

long as its class does not exceed the subscribed rate  Use e.g. WFQ scheduling

62

November 21, 11

Outline  What is QoS?  Overview of QoS mechanisms  Application level techniques

  Media streaming example case o  Client or server based techniques

  Overlays o  RON, CDN

 Network-layer techniques   Offering multiple classes of service

o  Scheduling and policing packets, DiffServ   Providing QoS guarantees

o  Resource reservation, RSVP, IntServ  Conclusions

November 21, 11

End-to-end QoS guarantees

 What is needed?   QoS differentiation mechanisms

o  The mechanisms we just reviewed   Resource reservation mechanism

o  Admission control o  RSVP or other existing protocol

 How to put it all together?   IETF IntServ architecture

64

November 21, 11

From QoS differentiation to guarantees

 Basic fact of life: can not support traffic demands beyond link capacity

Call Admission: flow declares its needs, network may block call (e.g., busy signal) if it cannot meet needs

R1 R2

1.5 Mbps link

1 Mbps phone

1 Mbps phone

Principle 4

November 21, 11

QoS guarantee scenario  Resource reservation

  traffic and QoS declaration   call setup, signaling (RSVP)   per-element admission control

QoS-sensitive scheduling (e.g.,

WFQ)

request/ reply

November 21, 11

 Architecture for providing QoS guarantees in IP networks for individual application sessions

 Resource reservation: routers maintain state info of allocated resources, QoS req’s

 Admit/deny new call setup requests:

Question: can newly arriving flow be admitted with performance guarantees while not violated QoS guarantees made to already admitted flows?

IETF Integrated Services

November 21, 11

Call Admission Arriving session must :  declare its QoS requirement

  R-spec: defines the QoS being requested   Three types: best effort, controlled load,

guaranteed service  characterize traffic it will send into network

  T-spec: defines traffic characteristics   Described as Token Bucket parameters: r, b

 signaling protocol: needed to carry R-spec and T-spec to routers (where reservation is required)   RSVP

November 21, 11

Intserv QoS: Service models Best effort:  No reservation required at all Controlled load service:   "a quality of service closely approximating the QoS that

same flow would receive from an unloaded network element.“

 No R-spec necessary, just T-spec   Routers can ensure that they do not oversubscribe

Guaranteed service:  R-spec described as rate R

  Selected to obtain desired bandwidth and delay guarantees   R >= r in T-spec

o  Higher rates will reduce queuing delay

November 21, 11

Achieving QoS guarantee   Combine token bucket and WFQ   Mathematically proven upper bound on delay (Parekh 1992)

  Regulated traffic has bounded delay   Can be extended to arbitrary topology networks

WFQ

token rate: ri

bucket size: bi

flow i rate: Ri=wiC/Σw

When ri < Ri , max delay for packet of flow i: Di

max = bi /Ri

arriving traffic

output link capacity: C

November 21, 11

Signaling in the Internet

connectionless (stateless)

forwarding by IP routers

best effort service

no network signaling protocols

in initial IP design

+ =

 New requirement: reserve resources along end-to-end path (end system, routers) for QoS

 RSVP: Resource Reservation Protocol [RFC 2205]   “ … allow users to communicate requirements to network in

robust and efficient way.” i.e., signaling !  earlier Internet Signaling protocol: ST-II [RFC 1819]

November 21, 11

RSVP is…  simplex

  Makes reservations for unidirectional data flows  receiver-initiated

  Receiver of a data flow initiates and maintains the resource reservation

 using soft states   adapts dynamically to changing group membership as

well as changing routes.  independent of routing, admission control, and

packet scheduling  necessary to be present at sender(s), receiver(s),

and routers

November 21, 11

RSVP does not…

 specify how resources are to be reserved   rather: a mechanism for communicating needs

 determine routes packets will take   that’s the job of routing protocols   signaling decoupled from routing   RSVP relies on existing unicast/multicast routing

protocols

November 21, 11

RSVP: operation  At each hop consults admission control and sets up

reservation   Requester informed in case of failure

 Sender-to-network signaling   path message: make sender presence known to routers   path teardown: delete sender’s path state from routers

 Receiver-to-network signaling   reservation message: reserve resources from sender(s) to

receiver   reservation teardown: remove receiver reservations

 Network-to-end-system signaling   path error   reservation error

November 21, 11

IntServ: Scalability Issues

  RSVP signaling Overhead   One PATH/RESV per flow for each refresh period (soft

state)

  Processing overhead   Routers have to classify, police and queue each flow

 State information stored in routers   Flow identification (using IP address, port etc)   Previous hop identification   Reservation Status   Reserved Resources

75

November 21, 11

Outline  What is QoS?  Overview of QoS mechanisms  Application level techniques

  Media streaming example case o  Client or server based techniques

  Overlays o  RON, CDN

 Network-layer techniques   Offering multiple classes of service

o  Scheduling and policing packets, DiffServ   Providing QoS guarantees

o  Resource reservation, RSVP, IntServ  Conclusions

November 21, 11

Conclusions

 Some applications require a certain QoS level   Different metrics important for different apps   Service availability is important also

 QoS mechanisms developed on various layers   Application, transport, network

 Today’s end-to-end Internet is best effort   No end-to-end QoS guarantees possible

o  Would require usage and deployment of nw-layer techniques

  Application and transport level techniques used to make the best out of best effort

77

November 21, 11

Internet-wide QoS never happened

 Lots of research done on QoS mechanisms in 90s   For nothing..?

 Some IP QoS mechanisms are utilized   E.g. DiffServ can be used in private networks (within a single

ISP)  Some guesses of reasons for “failure”

  Technical dimension o  Not manageable across competing domains o  Not configurable by normal users (or apps writers) o  Increase system vulnerability and resilience

  Economic dimension o  Lack of no viable business models o  No initial gain o  Not incrementally deployable

78

November 21, 11

References 1.  Andrew S. Tanenbaum, Computer Networks, Fourth Edition, Pearson Education, 2006. 2.  James F. Kurose, and Keith W. Ross: Computer Networking: A Top-Down Approach Featuring the Internet, Third Edition, Pearson Education,

2006. 3.  Alberto Leon-Garcia and Indra Widjaja, Communication Networks: Fundamental Concepts and Key Architectures, Second Edition, Tata McGraw-

Hill, 2005. 4.  IP QoS Architectures and Protocols, Packet Broadband Network Handbook, Digital Engineering Library, McGraw Hill, 2004. 5.  Congestion Control and Quality of Service, Data Communication and Networking, Digital Engineering Library, McGraw Hill, 2006. 6.  Curado, M. and Monteiro, E. , "A Survey of QoS Routing Algorithms", in Proc. of the International Conference on Information Technology

(ICIT2004), December 2004 7.  Manner Jukka, Lopez A, Mihailovi A, Velayos H, Hepworth E, and Y Khouaja, Evaluation of Mobility and QoS Interaction, Computer Networks

Volume 38, Issue 2, 5 Feb 2002, pp. 137-163. 8.  Anup Kumar Talukdar, B. R. Badrinath, and Arup Acharya, MRSVP: A Resource Reservation Protocol for an Integrated Services Network with

Mobile Hosts, Wireless Networks, 7, 5–19, 2001. 9.  Rajeev Koodli, and Charles E. Perkins, Fast Handovers and Context Transfers in Mobile Networks, ACM SIGCOMM Computer Communications

Review, Special Issue on Wireless Extensions to Internet, 2001. 10.  J. Hillebrand, C.Prehofer, R. Bless, M. Zitterbart, Quality-of-Service Signaling for Next-Generation IP-based Mobile Networks, IEEE

Communications Magazine, June 2004. 11.  Seoung-Bum Lee, G. Ahn, X. Zhang and A. T. Campbell, INSIGNIA: An IP-Based Quality of Service Framework For Mobile Ad Hoc Networks,

Journal of Parallel and Distributed Computing, 2000. 12.  Abhay K. Parekh and Robert G. Gallagher. 1994. A generalized processor sharing approach to flow control in integrated services networks: the

multiple node case. IEEE/ACM Trans. Netw. 2, 2 (April 1994), 137-150. 13.  RFC 2205: Resource Reservation Protocol, Braden, Zhang et al. 14.  RFC 3031: Multiprotocol Label Switching (MPLS), Rosen, Viswanathan and Callon. 15.  RFC 2475: An Architecture for Differentiated Services, S. Blake, D. Black et al. 16.  RFC 4080: Next Steps in Signaling (NSIS): Framework, R. Hancock, G. Karagiannis et al., 2005. 17.  RFC 2326: Real Time Streaming Protocol (RTSP), H. Schulzrinne et al., 1998 18.  GMPLS tutorial: http://www.iec.org/online/tutorials/gmpls/

79