Netzwerktechnik FHS Kufstein Tirol - PowerPoint PPT Presentation

View by Category
About This Presentation

Netzwerktechnik FHS Kufstein Tirol


Problem statement: Internet properties and our goal ... capacity: often physical capacity, but different if you talk about TCP ... – PowerPoint PPT presentation

Number of Views:126
Avg rating:3.0/5.0
Slides: 138
Provided by: telekoop
Learn more at:


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Netzwerktechnik FHS Kufstein Tirol

NetzwerktechnikFHS Kufstein TirolGetting the
most out of the Internet
Michael Welzl http//www.welzl.atDistributed
and Parallel Systems Group Institute of Computer
Science University of Innsbruck
Both sides of the story...
  • End users want
  • Efficient Internet data transfer
  • e.g., 100 Mbit/s should really be 100
    Mbit/s!(not always true! e.g. theoretical vs.
    real wireless bandwidth)
  • application (video, audio, ..) quality should be
  • Cheap service
  • Service providers want
  • Money!
  • Save money efficient use of existing capacity
  • Earn extra money provide special services with
    guarantees(e.g., video conferencing)

Thus, two major parts 1. Efficient End-to-End
Internet Data Transfer2. Quality of Service
  • A brief networking (Internet) overview
  • Efficient End-to-End Internet Data Transfer
  • Problem statement Internet properties and our
  • IP, router architecture, the congestion problem,
    heterogeneous infrastructure, traffic properties
  • Instruments what can be done?
  • end system
  • measure and change! rate, packet size,
    application data, flow / congestion control
  • router
  • communicate with end system (e.g. ICMP), control
    packets in queues
  • Solutions how are the instruments applied?
  • TCP congestion control, Path MTU Discovery, ALF,
    special mechanisms for special flows (SCTP, DCCP,
    UDP Lite), RED, ECN, ..
  • Quality of Service
  • IntServ / RSVP, DiffServ, QoS Routing, Traffic
    Engineering, MPLS, MP?S, Internet2 QBone
  • Lessons learned and the future of Internet QoS

1. Networking a brief overview
  • Network layers, ISO/OSI vs. DoD model,
    terminology, the Internet

Logical communication flow
draw a green rectangle
Physical communication flow
language (protocol)
draw a green rectangle
Network(Internet Cloud)
Choose a path
check for logical errors
check for bit errors
  • Programming Languages
  • Machine code
  • Assembler
  • Low level languages
  • High level languages (special purposes),OO
    Design, ..
  • Simplification by abstraction
  • Same for networks network layer models

ISO/OSI Reference Model
  • THE famous layer model
  • 7 layers
  • precise terminology, huge amount of theoretical
  • layer provides service to upper layers
  • strict rules (layers must not be skipped, but
    they are interchangeable)

OSI Architecture
  • ISO Basic Reference Model for Open Systems
    Interconnection (OSI)
  • OSI model is concept, architecture, common

OSI Layers
  • Application oriented layers7. Application
    Layer actual communicating apps6. Presentation
    Layer semantics5. Session Layer structured
    dialogue - synchronisation, ..
  • Transport oriented layers4. Transport Layer
    end2end msg. stream, no knowledge of routing3.
    Network Layer routing, packets between adjacent
    systems(LANs 2b Logical Link Control L.2a
    Medium Access Control)2. Data Link Layer
    error-recovery, frames (not packets) stream
    between adjacent systems1. Physical Layer
    unsecure bitstream between adjacent systems

The most successful (packet) network is...(and
the winner is...)
The Internet
How the Internet has changed
  • Original goal robust communication on a
    long-term basis
  • Original size ARPANET...

How the Internet has changed
  • Currently 69 new hosts added each minute!
  • IEEE Spectrum, Feb. 2001
  • Commercial demand for new, accordingly priced
    services(VoIP, streaming audio/video,
    videoconferencing, ..)
  • Overprovisioning does not suffice - demands
  • Goal is not just speed / reliability
    anymoreInternet "best effort" service is not
    good enough

Common Internet myths misconceptions
  • The network automatically finds the best path for
    my packets.
  • IPv6 is brand new, provides QoS and will be
    widely deployed soon.
  • The Internet changes with incredible speed.
  • Overprovisioning can solve all QoS problems.
  • Somewhat less commonInternet2 will soon replace
    the Internet as we know it.
  • World Wide Web Internet.
  • The Internet exists since ...
  • TCP/IP is (are) the Internet protocol(s).

Primary reason for tremendous success
end2end argumentmove complexity to higher
layers in the stack...important Internet design
Example security Security provided by the
network may be too bad or unnecessary for some
applications. The network cannot provide
authentication only the application has access
to the necessary information
Today, scalability remains the no. 1 goal
DoD reference model
  • DoD-model older (approx. 1969) than OSI (approx.
  • Only 4 layers
  • Application Layer
  • Transport Layer
  • Internet Layer ( layer 3, Network layer)
  • Network Access Layer ( everything underneath the
  • Layers 5 and 6 missing
  • Less restrictive - layers may be skipped

OSI, DoD and reality
  • OSIMany service functions carried out in
    several layers / services? Overhead, even
  • Why should I implement layers 5, 6 in my app /
    OS ?
  • Commercial failure - but still useful to explain
  • DODactually obsolete Internet defined by
    TCP/IP stack(defined by RFCs)

TCP/IP Protocol Stack
  • IP addressing, routing, fragmentation/reassembly,
  • UDP ports, checksum
  • TCP UDP connection-oriented service
    (retransmission/ACK),combined flow control /
    congestion control

A shaky invariant the Internet Hourglass
Everything Over IP
IP Over Everything
IP Routing Domain level (IGP's)
  • Distance Vector Routing RIP, routers only
    keepinformation about adjacent routers
  • Link State Routing OSPF, IS-IS - each router
    knows about the whole domain (less scalable!)
  • based on routing metric, usually no. of hops -
    not always optimal

Interdomain routing (EGP's)
  • BGP Distance Vector Routingbetween "Autonomos
    Systems"(registered unique AS number)
  • Metrics often configuredmanually according to
  • Peering relationshipsusually cheaper than
  • Implementation filteronly accept routes
    fromspecific sources

Who defines the Internet?
  • Preliminary research in IRTF ( http//
  • Standards (RFCs) defined by IETF (
    http// ) -mostly Working Groups
  • Decisions by IESG (as of Feb. 2001, 14 elected
  • IAB stimulates IETF / IESG actions
  • RFCs have different status standard, proposed
    standard, draft standard, experimental,
    informational, ..
  • Internet-draft preliminary - may turn into RFC

Who really defines the Internet?
  • RFCs define the Internet. Only standard RFCs
  • Extremer views, but maybe closer to reality
  • Jon Postel defined the Internet.
  • Cisco defines the (core) Internet.
  • Microsoft defines the (end2end) Internet.
  • Some standards never made it.Some other things
    did (MBone, NAT, P2P, ..)

Standards that never really made it(and probably
never will)
  • TTL as an actual time value
  • The (originally planned usage of the) IP TOS
  • Several IP options Strict / Loose Source
    Routing Record Route Timestamp
  • Source Quench

Who runs the Internet?
  • (See http//www.caida.orgfor more pictures)
  • Hierarchical structure
  • Distributed ISP admins run it
  • No Internet "police"
  • Each ISP interested in his/her own services, but
    end2end paths may include the backbone
  • CPU cycles scarce in core routers

If you really want to know how it works
  • ... check out
  • http//

important links http// http//www.i
2. Efficient End2End Internet Data Transfer
  • Problem statement, terms, instruments (what can
    be done?), solutions (how are the instruments

Problem statement
  • Efficient transmission of data streams across the
  • various sources, various destinations, various
    types of streams
  • What is efficient?
  • terms latency, end2end delay, jitter,
    bandwidth(nominal/available/bottleneck -),
    thoughput, goodput, loss ratio, ..
  • goals high throughput (bits / second), low
    delay, jitter, loss ratio
  • Note Internet TCP/IP based world-wide network
  • no assumptions about lower layers!
  • ignore CSMA/CD, CSMA/CA, token ring, baseband
    encoding, frame overhead, switches, etc. etc. !

typically bit/s at this level!
  • Mirriam-Webster online ( http// )
  • Main Entry bandwidth, Pronunciation
  • Function noun, Date circa 1937
  • 1 a range within a band of wavelengths,
    frequencies, or energies especially a range of
    radio frequencies which is occupied by a
    modulated carrier wave, which is assigned to a
    service, or over which a device can operate
  • 2 the capacity for data transfer of an
    electronic communications system ltgraphics
    consume more bandwidth than text doesgt
    especially the maximum data transfer rate of
    such a system

Traditional, real definition!
Information rate
Bandwidth (2)
  • Common interpretation in CN contextHow many
    bits/sec can be transferred ("how thick is the
  • Consider modem connection vs. van of DVDs
    traveling an interstate highway
  • Unit definition 1 - Hz, definition 2 - bit/s
  • And baud?
  • glossaryhttp//
    fo/Glossary/Terms/baud.html"Most people use baud
    to describe modem speeds in bits per second--but
    they're wrong. They may say a 9,600-bps modem
    transmits at 9,600 baud, but really baud is a
    measure of how frequently sound changes on a
    phone line. Modern modems transmit more bits with
    fewer changes in sound, so baud and bps numbers
    aren't equal. However, only editors, pedants, and
    communications engineers now care about the
    distinction. But if you run into members of these
    groups, use bps instead of baud.

Wooly but common bandwidth related terms (and
their usual interpretations)
  • Nominal bandwidth
  • Bandwidth of a link when there is no traffic
  • Available bandwidth
  • (Nominal bandwidth - traffic) ... during a
    specific interval!
  • Very important, but perhaps most ambigous term of
  • Bottleneck bandwidth
  • smallest nominal bandwidth along a path
  • often also smallest available bandwidth along a
  • Throughput
  • bandwidth seen by the receiver
  • Goodput
  • bandwidth seen by the receiving application (e.g.
    TCP goodput ! throughput)

A simple router model
packet too large?? fragment!
Switching Fabric
In 1
Out 1
Queue 1
In 2
Out 2
In 3
Queue 2
  • Switching fabric forwards a packet (dest.
    addr.) if no special treatment necessary
    fast path (hardware)
  • Queues grow when traffic bursts arrive
  • low delay small queues, low jitter no
    queue fluctuations
  • Packets are dropped when queues overflow
    (DropTail queueing)
  • low loss ratio small queues

Delay / Bandwidth
  • Delay / Bandwidth related, but not
  • On the Internet, delay changes indicate (path
    changes or) congestion? TCP Vegas
  • Congestion related to bandwidth ? delay related
    to bandwidth!
  • but

similar delay, different available bandwidth!
  • Latency - time to transfer an "empty" message
  • also propagation delay
  • limit speed of light!
  • End2end delay latency msg_length /
    bottleneck bandwidth
  • queuing delay
  • processing delay can also play a role,esp. in
    core routers (CPU cycles scarce resource!)
  • Jitter - delay fluctuations, very critical for
    most real-time applications
  • Round-trip time (RTT) - time a messages needs to
    go from sender to receiver and back

maximum theoretical earth distance 66.8ms (lag
gt 50ms audible!)
The time spent in queues
  • mbit / mb / Mb / Mbit ... ?
  • Latency sometimes end2end-delay
  • In general make sure you know what layer you
    are talking about!
  • link physical connection between one or more
    hosts or routers, or link between IP routers (may
    consist of multiple physical links!)
  • capacity often physical capacity, but different
    if you talk about TCP
  • Typical commercial WLAN term theoretical
    bandwidth(nominal bandwidth at physical as
    opposed to application layer)

The congestion problem
  • Congestion control necessary
  • adding fast links does not help!

total throughput w/o cc. 20kb/s total throughput
w/ cc. 110kb/s
Congestion collapse
  • Goal operation at the knee !

Internet traffic characteristics
  • MRTG trace (based on SNMP, accessing traffic
    counters in MIB)

Internet traffic characteristics /2
  • Traditional traffic modelling queuing
    theorynotion traffic follows poisson
  • Internet traffic is bursty - intuitive reasons
  • TCP is bursty by nature (congestion avoidance,
    payload vs. acks - later!)
  • ACK compression can cause payload bursts due to
    ACK-clocking (later!)
  • various packet sizes
  • Bursts from queues aggregate as traffic traverses
    the net
  • Burstiness of one flow affects other adaptive

Still true for user arrival !
Internet traffic characteristics /3
  • Overlapping of independent on-off sources leads
    to distribution with heavy-tailed autocorrelation
  • Long-range dependance "peaks sit on ripples
    which sit on waves"
  • No "flattening" towards a mean as you zoom out -
    same structures may be found at different time
    scales, hence self similar
  • Traffic characteristics sometimes modeled with
    time series (fARIMA models) or wavelets
  • Measurement of the "degree of self similarity"
    Hurst parameter
  • -gt model approximation involves Hurst parameter
  • Calculations extremely difficult -Internet
    analysis mostly based on simulation!

  • What can be done?

IPv4 Header
Examples Loose / Strict Source Routing, Record
Route, Timestamp, Router Alert
End systems Measure...
well studied- leads to misinterpretation
of transmission errors
  • throughput ("goodput")
  • ( mean, fluctuations,
  • packet loss ratio..)

easy to measure independent of transmission
errors- not practical without throughput
delay( rtt, one way delay, jitter..)
similar delay, different available bandwidth!
... and change!
  • lower layers
  • throughput (gap between packets)
  • flow control / congestion control
  • well studied, many options - our main interest!
  • packet size
  • large recommendedless overhead
  • small less impact of transmission
    errors,smaller latency!
  • protocol

Note packet size granularity ofthroughput
  • content
  • compression
  • hierarchical encoding
  • FEC

Common difficultiesbandwidth known (depending
on content)?granularity of rate changes
End2end bandwidth adaptation difficulties
Flow Control Methods
  • Remember refers to next msg-no to be
  • Version described at left
  • credit C-A is fixed-size window
  • C-A pushed by ACKs
  • S, R move within window
  • sender keeps copies of A thru S-1
  • Common design flaw
  • Rcv. wants to slow down sender? holds back ACK
  • ? timeouts, retransmits
  • Remedy, cf. TCP
  • TCP separates ACK / window size (credit) per
  • _______________________________
  • Rate control
  • S, R negociate data rate
  • may be slowed down by either party
  • No explicit feedback necessary
  • Sliding window flow control
  • most widely used, many variants

Possibilities in routers
  • Communicate with end systems
  • alter header flags (IP only! should not look at
    other layers)
  • generate signaling packets Internet Control
    Message Protocol (ICMP)(mainly error messages)
  • Control packets in queuesuse queue length or
    position in queue to
  • communicate (mark)
  • drop, move to other queue etc.
  • Problems
  • CPU cycles scarce in (core) Internet routers
  • Scalability! (e.g., no per-flow state)example
    ICMP Source Quench failed(congestion
    notification in times of congestion)

  • How are the instruments applied?

Path MTU Discovery
  • MTU Maximum Transfer Unit (largest packet that
    will not be fragmented)
  • MTU refers to link Path MTU (PMTU) minimum MTU
    of a path
  • Algorithm
  • set IP dont fragment flag
  • start with big packets
  • gradually decrease size upon ICMP Destination
    Unreachable - Fragmentation Needed reply
  • layer 3 functionality - may be initiated from
    layer 4
  • TCP problem with arbitrary packet drops
  • Path MTU Discovery Black Hole Detection
    problemNo ICMP messages from unresponsive
    routers or filtered by firewalls...hard to
    detect and solve!
  • proposed solution start with small packets and
  • do not rely on ICMP messages!

Internet congestion control History
  • 1968/69 dawn of the Internet
  • 1986 first congestion collapse
  • 1988 "Congestion Avoidance and Control"
    (Jacobson)Combined congestion/flow control for
  • Goal stability - in equilibrum, no packet is
    sent into the network until an old packet leaves
  • ack clocking, conservation of packets principle
  • made possible through window based stopgo -
  • Superposition of stable systems stable ?
    network based on TCP with congestion control

TCP Congestion Control /1 Tahoe, 1988
  • Distinguish
  • flow control protect receiver against overload
  • (receiver "grants" a certain amount of data
    ("receiver window") )
  • congestion control protect network against
  • ("congestion window" (cwnd) limits the rate
    min(cwnd,rwnd) used! )
  • Flow/Congestion Control combined in TCP. Several
  • (window unit SMSS Sender Maximum Segment Size,
    usually adjusted to Path MTU init cwndlt2
    (SMSS), ssthresh usually 64k)
  • Slow Start for each ack received, increase cwnd
    by 1(exponential growth) until cwnd gt ssthresh
  • Congestion Avoidance each RTT, increase cwnd by
    SMSSSMSS/cwnd(linear growth - "additive

TCP Congestion Control /2
  • If a packet or ack is lost (timeout, roughly
    4rtt), set cwnd 1, ssthresh current
    bandwidth / 2(multiplicative decrease") -
    exponential backoff
  • Several timers, based on RTT good estimation is
  • Later additions(TCP Reno, 1990)Fast retransmit
    / fast recovery (notify sender of loss via
    duplicate acks)

Congestion Avoidance
Slow Start
Background AIMD
Active Queue Management
  • Today, TCP behaviour dominates the Internet (WWW,
  • example backbone measurement 98 TCP traffic
  • 1993 Random Early Detection ("Discard", "Drop")
    (RED)(now that end nodes back off as packets are
    dropped, drop packets earlier to avoid queue
  • Another goal add randomization to avoid traffic
    phase effects!
  • Qavg (1 - Wq) x Qavg Qinst x Wq(Qavg
    average occupancy, Qinst instantaneous
    occupancy, Wq weight - hard to tune,
    determines how aggressive RED behaves)

Active Queue Management /2
  • Based on exponentially weighted moving average
    (EWMA) of instantaneous queue occupancy low
    pass filter
  • recalculated every time a packet arrives
  • Qavg below threshold min_th Nothing happens
  • Qavg above threshold min_th Drop probability
    rises linearly
  • Qavg above threshold max_th Drop packets
  • RED expects all flows to behave like TCP - but is
    it fair?
  • Variants drop from front, drop based on
    instantaneous queue occupancy, drop arbitrary
    packets, drop based on priorities...

Explicit Congestion Notification (ECN)
  • 1999 Explicit Congestion Notification
    (ECN)Instead of dropping, set a bit
  • End systems are expected to act as if packet was
    dropped-gt actual communication between end nodes
    and the network!
  • ATM and Frame Relay not only ECN but also BECN
  • Internet BECN often proposed and regularly
    discussed (ICMP SQ), but very unlikely - several
  • Idea charge more when ECN flag is set
  • ECN cannot totally replace loss measurements!

Congestion pricing
  • Basic idea higher sending rate more congestion
    higher price
  • Idea charge more when ECN flag is set
  • Smart Market idea
  • each packet bids for capacity
  • out of n bids, m highest bids can be accepted
  • price marginal cost (highest bid of unaccepted
    packets) ? leads to market equilibrium
  • Smart Market not practical (bidding per
    packet), but shows
  • balance of demand and supply leads to market
  • stable system just based on economics suffices
    for congestion control
  • Problem link cannot know bids in advance ? no

TCP in heterogeneous environments
  • Timeout interpreted as congestion
  • was bad idea in times of error-prone networks
  • seems reasonable in times of fibre networks
  • absolutely insane for wireless links!
  • TCP over long fat pipes large bandwidthdelay
  • long time to reach equilibrium, MD problematic!
  • Different implementations / extensions
  • TCP SACK - explicit notification of missing
  • TCP over wireless - checksum error ? do not
    immediately drop packet ? not interpreted as
  • TCP over sat (also "Interplanetary Internet")
    larger windows, ..

Wireless TCP
  • Various experimental enhancements
  • split connection at base station
  • monitor connection at base station, buffer
    interfere (Snoop TCP)
  • Note ECN is not affected by link noise!

UDP and UDP Lite
  • UDP IP 2 features
  • Ports identify communicating instances with
    similar IP address(transport layer)
  • Checksum Adler-32 covering the whole packet
  • checksum field 0 no checksum at all! bad idea!
  • ? solution UDP Lite (length checksum
  • advantage e.g. video codecs can cope with bit
    errors, but standard UDP throws a whole packet
  • critical apps depending on UDP Lite can depend
    on lower layers
  • usefulness often, link layers do not hand over
    corrupt data
  • Usage of UDP unreliable data transmission (DNS,
    SNMP, real-time streams, ..)

End2end real-time data transfer
  • Assumption no special service available at
    application level
  • (Definition of Internet "real-time" softer than
  • Different requirements
  • reliable service may not be needed (no
  • Timely transmission important
  • Different treatment
  • no retransmission / waiting for ACKs
  • no sliding window (stop go behaviour not
  • but
  • some kind of flow control still needed
  • synchronization necessary
  • often Multicast

Real Time Protocol (RTP)
  • Can be used on top of anything, but usually UDP
  • adds a timestamp
  • supports payload type identification
  • adds a counter to preserve the original packet
  • Intermediate systems
  • Translator converts encodings, filtering
  • Mixer synchronizes multiple streams based on RTP
  • Real Time Control Protocol (RTCP)
  • Receiver reports provide feedback (packet loss,
    interarrival jitter)
  • Sender reports similar to RRs, issued if receiver
    isalso a sender

Regular network end nodes ? overlay network model!
Other related protocols
  • XTP
  • rate-based protocol for multimedia
    transport(instead of allowing a certain amount
    of data, inform the sender about the allowed data
  • no time synchronization / timestamps
  • Multicast (overlay)
  • Application level protocols (mainly for ease of
  • Real Time Streaming Protocol (RTSP)
  • Application level protocol supporting VCR-like
  • Play, Forward, Rewind, Pause, Stop, Record
  • Just signaling - no payload transmission (usually
    done with RTP/UDP)
  • Not connection-oriented, can be used on top of
    TCP or UDP
  • Hypertext Transport Protocol (HTTP)
  • Can be used to control streaming multimedia
    (browser plug-ins, ..)

Data encoding / application layer signaling
  • RTP content type definitions encapsulate various
  • H.323 protocol suite
  • big, covers various layers (e.g., H.263 video)
  • encoding formats for video, audio
  • originally designed for ISDN (CBR)
  • newer than H.323, improved scalability
  • session signaling similar to http request (ascii)
  • designed to co-exist with RTP/RTCP in the
  • MPEG
  • Fluctuating data stream designed for efficient
  • Semantics in MPEG7

Compare DivX downloads ? streaming video
Multimedia adaptation
  • Mistake
  • adaptation schemes assume arbitrary data stream
  • Problem
  • Data streams show fluctuations (example MPEG I-,
    B-, P-frames)
  • Solution
  • Special CBR design for communication - H.261
    designed for ISDN
  • not possible or feasible in all cases
  • Problem
  • compression usually not deterministic - size
    depends on content!
  • real-life distance learning example40kbps
    enough for streaming video (Smartboard) audio
    (speech), but speech suffers dramatically if
    teacher visible

  • ATM ABR Max-Min-fairness
  • A (..) allocation of rates is max-min fair iff
    an increase of any rate (..) must be at the cost
    of a decrease of some already smaller rate.
  • One resource mathematical definition satisfies
    "general" understanding of fairness - resource is
    divided equally among competitors
  • Usually requires knowledge of flows in routers
    (switches) - scalability problem!
  • Internet
  • TCP dominant, but does not satisfy
    Max-Min-fairness criterion!
  • Ack-clocked - flows with shorter RTT react sooner
    (slow start, ..)and achieve better throughput
  • Therefore, Internet definition of fairness
    TCP-friendliness"A flow is TCP-compatible
    (TCP-friendly) if, in steady state, it uses no
    more bandwidth than a conformant TCP running
    under comparable conditions."

Proportional Fairness
F. Kelly Network should solve a global
optimization problem (maximize log utility
function) Max-Min-fairness suboptimalS1 S2
S3 c/2
All link capacities c
  • Proportional fairness
  • An allocation of rates x is proportionallyfair
    iff, for any other (..) allocationy, we have
    (roughly approximated by

Proportionally fair allocationS1 c/3, S2 S3
How to be TCP-friendly
  • TCP-friendliness can be achieved by emulating the
    behaviourof TCP (or the desired parts of it)
  • Simplified TCP AIMD (additive incr. ? ,
    multiplicative decr. ?)
  • 0 lt ? , 0 lt ? lt 1 -gt stable and fair
    congestion control
  • ? 4 x (1 - ?2) / 3 -gt TCP-friendly
    congestion control
  • ? 1, ? 1/2 -gt TCP
  • AIMD mechanisms for multimedia applications RAP,
  • Different approaches
  • TCP Emulation At Receivers (TEAR)TCP
    calculations (cwnd calculation, fast recovery,
    ...) moved to receiver, do not ack every packet,
    smooth sending rate
  • Binomial congestion control TCP-friendly,
    nonlinear control law

GAIMD congestion control
  • Relationship between ? and ? for TCP-friendliness

more aggressive responsive
Equation based congestion control
  • Based on TCP steady-state response function-
    gives upper bound for transmission rate T
  • well known example TFRC - TCP-friendly rate
    control protocol
  • smooth sending rate

Evaluation of TCP-friendly mechanisms
  • Infocom 2001 paper by Yang, Kim, Lam examines
    simulations ofTCP (Reno) vs. GAIMD (?0.31,
    ?7/8) vs. TFRC vs. TEAR(bigger is better)
  • Network simulator "ns-2
  • Well known scenario compete on a single
    bottleneck link ("dumbbell")

...and performance?
  • Parameters not very performance oriented
  • Smoothness not very interesting if large buffers
    are available (one-way streaming)
  • Despite efforts to identify non-adaptive
    flowsThe more you send, the more you get.
  • Probably most interesting question beside
    smoothnessHow closely does the mechanism follow
    the available bandwidth?
  • measurable parameter packet loss ratio

Not-so-TCP-friendly solutions
  • Overcome rate fluctuationslimit encodings (e.g.
    2 or 3 qualities), let user decide
  • Cross-media-adaptationchoose from video, audio,
    single pictures, text(e.g. MPEG7)
  • Limit by bottleneck bandwidth
  • often "last mile" - e.g. RealMedia
  • better determine actual bottleneck via packet
    pair approach
  • If wireless link involved small packets, UDP
  • Another possibility send more (do FEC) in
    response to packet loss
  • (very network-unfriendly behaviour, but may yield
    less data loss)

Network stability some adaptation better than
Example Jedi Knight 2 !
Some thoughts
  • How TCP-friendly are 8 web browsers?
  • Congestion Manager congestion control for all
    flows in OS core
  • MulTCP Emulate multiple TCPs to provide
    differentiated services
  • How TCP-friendly are short-lived flows?
    (web-traffic, ..)
  • How to convince Internet multimedia app.
    programmers to implement TCP-friendly congestion
  • Solution Datagram Congestion Control Protocol
  • Well-defined framework for TCP-friendly
    congestion control
  • Sender app chooses an appropriate congestion
    control mechanism
  • Core OS implementation of mechanisms
  • Lots of additional features nonces, partial /
    separate checksums (distinguish corruption ?
    congestion), ...

TCP header
TCP Connection Management
heavy solid linenormal path for a client The
heavy dashed linenormal path for a
server Light linesunusual events
  • Service provided by TCPCongestion
    controlled,reliable, sequentially ordered data
    streambetween two entities(port no. IP addr).
  • What else could we want?

  • Original Internet intention robust communication
    network (military)
  • Trend provide telephone-like service
  • Phones have been around for a long time
  • Easy to use, always works
  • Metaphor (SIP) call somebody on the net
  • Paths rarely change provide a circuit
  • http// request for information
    (yahoo web site)
  • Metaphor call yahoo wrong!
  • Better dissemination of information (mirrors,
    web caches), transparent to the user ? stress
    reduction, faster service, location dependent
  • (Application Layer) Multihoming use the net for
    distributed data retrieval

Multihoming /2
  • Location dependent services
  • Adapt content based on language, culture
  • find people with similar interest in this place
    (mobile client)
  • Exclude surfers from certain locations (law
    enforcements, ..)
  • New issue geographical location tracking(DNS
    extensions, time measurements, ..)
  • Problem efficient information dissemination
  • Routing

Application Level Framing
  • TCP byte stream oriented protocol
  • Application may want logical data units
  • Byte stream inefficient when packets are lost
  • ALF app chooses packet size chunk size
  • packet 2 lost no unnecessary data in packet
    1,use chunks 3 and 4 before retrans. 2 arrives
  • 1 ADU (Application Data Unit) multiple chunks
    -gt ALF still more efficient!

Multiple Data Streams
  • Application may use multiple logical data
    streams(e.g. pictures in a web browser)
  • Common solution multiple TCP connections
  • separate flow / congestion control (Congestion

Chunk 2
Chunk 1
Chunk 2
Chunk 1
Unnecessary retransmission!
SCTP (Stream Control Transmission P.)
  • Stream-based, connection oriented, reliable
    transmission protocol (TCP features)
  • Decoupling of reliable and ordered delivery
  • Unordered delivery eliminate head-of-line
    blocking delay
  • Support for multiple data streams (per-stream
    ordered delivery)
  • Application Level Framing
  • TCP congestion control (SACK ECN)
  • Hearbeat keep-alive mechanism

  • Multihoming at transport layer! (layer 3
  • Goal robustness
  • switch hosts upon routing failure
  • eliminate effect of routing reconvergence time
  • CRC-32 checksum instead of Adler-32
  • TCP connection ? SCTP association
  • 2 IP addresses, 2 port numbers ? 2 sets of IP
    addresses, 2 port numbers
  • DoS protecton avoid TCP SYN attacks
  • 4-way handshake no state at receiver of INIT
  • state in digitally signed INIT-ACK message

Unicast / Broadcast / (overlay) Multicast
Multicast issues
  • Required for applications with multiple receivers
  • video conferences, real-time data stream
    transmission, .. ? different data streams than
    web surfing, ftp downloads etc!
  • Issues
  • group management
  • protocol required to join / leave group
    dynamically Internet Group Management Protocol
  • state in routers hard / soft (lost unless
  • who initiates / controls group membership?
  • congestion control
  • scalability (ACK implosion)
  • dealing with heterogeneity of receiver groups
  • fairness
  • Multicast congestion control mechanism
  • sender- vs. receiver-based, single-rate vs.
    multi-rate (layered),
  • reliable vs. unreliable, end-to-end vs.

depends on content!
3. Quality of Service
  • "Managed unfairness"
  • Service rules behaviours
  • IntServ / RSVP, DiffServ, QoS Routing, Traffic
    Engineering, MPLS, MP?S, IPv6, Internet2 QBone

QoS and network layers
QoS and network layers /2
  • QoS fundamentally an end-to-end issue...
  • QoS spec. must not be violated at any layer
  • QoS request may originate from (almost) any layer
  • QoS provisioning may be demanded at (almost) any
  • There is no overall framework -demand for QoS
    often leads to layer violation

QoS below IP
  • LAN Medium Access Control (MAC) Layer
  • CSMA/CD (Ethernet) behaviour practically
    unpredictable(collisions lead to Binary
    Exponential Backoff, calculations too
  • Token passing schemes bandwidth / delay
  • WAN ATM-Layer (ATM has its own 3-dimensional
  • ATM was the first serious QoS attempt - "ATM to
    the desktop"
  • Constant cell size of (548) bytes enables Time
    Division Multiplexing-gt predictable data rate!

ATM Services
CBR (Constant Bit Rate) emulates a leased line
RT-VBR (Real-time Variable Bit Rate) for rt-streams w/ varying bandwidth such as MPEG
NRT-VBR (Non-real-time Variable Bit Rate) similar to RT-VBR, but more jitter is tolerated
ABR (Available Bit Rate) Cheap service - you do what you are told, get what is available and achieve a small cell loss ratio
UBR (Unspecified Bit Rate) Cheap, too no promises - best used by IP
ATM Services and Switching

  • ATM Explicit Rate Feedback (part of Available
    Bit Rate (ABR) service)
  • RM (resource management) cells
  • sent by sender, interspersed with data cells
    bits in RM cell set by switches
  • NI bit no increase in rate (mild congestion),
    (EF)CI bit like Internet ECN
  • two-byte ER (explicit rate) field may be lowered
    by congested switch
  • sender send rate thus minimum supportable rate
    on path!
  • Problem ATM failed (scalability? too much
    complexity in switches?)
  • Experimental Internet approaches
  • Multilevel ECN (two bits), eXpress Control
    Protocol (XCP), CADPC/PTP (my own)

ATM and reality
  • ATM to the desktop dead
  • Most often used for high-speed Internet links
  • Suboptimal for various reasons
  • Cell size does not match packet sizes
  • IP provides datagram service, no use for CBR
  • IP mostly used with UBR or ABR service in case
    of ABR,TCP is a control loop on top of a control

Typical QoS requests
ATM Peak / Sustained / Minimum Cell Rate, Cell Delay Variation Tolerance, Cell Transfer Delay, Cell Error Rate, Cell Loss Ratio, ..
Layer 4 (distributed Multimedia app) Throughput, End2end Delay, Residual Error Rate (not (yet?) on the Internet!), Connection Establishment Delay / Failure Probability, ..
Layer 7 Transmission Security, Data Encoding Completeness, ..
Human Layer Perceived quality - "does it look good?", "does it feel controllable?", fun factor, ..
"Human Layer" QoS requirements
QoS Architectures
  • Heidelberg QoS Model, OMEGA, int-serv, XRM
    (hierarchical), QoS-A and Tenet (3-dimensional),
    OSI, TINA, MASI, ..
  • Various concepts related to layers (OSI, QoS-A),
    related to specific implementations (int-serv),
  • Architectures identify fundamental concepts of
    QoS specification, provisioning, control and
  • No overall agreement on a single architecture

Generic QoS-capable router
Policing / Admission Control Marking
Queuing Scheduling / Shaping
Building blocks of modern QoS architectures
QoS router building blocks
  • Packet Classification
  • Group packets according to header properties
  • Multiple fields (MF classification) needed to
    detect individual flowsip source / destination,
    protocol and port numbersproblems packet
    fragmentation (port numbers),header compression,
    encryption (IPSec)
  • Meter
  • Monitor traffic characteristics (e.g., does flow
    741 hold its promises?), provide information to
    other block(s)
  • Policing
  • Drop packets if certain conditions are fulfilled
  • Admission Control
  • React (not necessarily drop packets) if certain
    conditions are fulfilled
  • Marking
  • Mark packets (change header) if certain
    conditions are fulfilled
  • for later special treatment - maybe not even in
    the same router

QoS router building blocks /2
  • Switch(ing) Fabric
  • Do a query on the routing table, decide where to
    send the packet
  • Queuing
  • If a packet cannot be delivered immediately
    (congestion),put in queue(s) for later delivery
  • Decision which queue? Active queue management?
  • Scheduling
  • When to take a packet from which queue (e.g.,
    round robin)
  • Shaping
  • Adjust traffic characteristics if certain
    conditions are fulfilled(usually implemented in
  • Useful even without QoS provisioning Do not
    exceed max. promised quality - customers will get
    accustomed and complain!

Integrated Services (IntServ)
  • Notionhard guarantees desired, per-flow
    resource reservation needed
  • Two services defined
  • Guaranteed Serviceguaranteed bandwidth, firm
    bounds on end-to-end queuing delaysto be used
    by real-time applications
  • Controlled Loadclosely approximates the
    behaviour seen when there is (almost) no
    congestion to be used by elastic applications
  • Architecture, Services / Reservation signaling
    protocol("Resource Reservation Protocol" - RSVP)
    design separated

IntServ per-hop requirements
  • Classification
  • per-flow context established via multifield
  • flow context used to drive token-bucket metering

Marker, Policer, ..
  • implemented as byte counter goal detect
    various degrees of burstiness
  • several thresholds (also empty) with
    associated treatment possible!

IntServ traffic specification contains token
generation rate, bucket size
IntServ per-hop requirements /2
  • IntServ token bucket metering leads to remarking
    or dropping(admission control)
  • Multiple queues, one for each flow
  • Implementation virtual queues - only one real
    queue per service
  • Scheduler takes packets based on priorities
    (airline analogy)
  • e.g., 1, 1, 2, 1, 1, 2, .. but not priority
    queuing (q1 until empty) - may cause starvation
    of q2!
  • No bandwidth guarantees because of packet
  • Solution Weighted Fair Queuing (WFQ), Class
    Based Queuing (CBQ)

Resource ReserVation Protocol (RSVP)
  • Signaling - routers must know which flows to
  • state in routers is established via PATH messages
    from sender
  • Sender advertises allowed traffic spec via adspec
  • Receivers initiate reservation (resv messages
    containing flow spec.)
  • Multicast support, state merging

IntServ / RSVP discussion
  • RSVP requires support by all routers(if
    unsupported, RSVP is tunneled - but no more hard
  • Scaling per-flow state not feasible!RSVP
    protocol not scalable either (maybe due to bad
  • Strict guarantees per customer complicated
  • Solution "softer" QoS, no per-flow state in core
    routers - DiffServ

Best-Effort IntServ/RSVP DiffServ
QoS-Guarantees none flow-based aggregated
Configuration none dynamicend2end staticedge2edge
Differentiated Services (DiffServ)
  • Edge routers Classifier / Meter / Marker /
    Shaper / Dropper
  • Core routers static forwarding according to
    DiffServ-class, implementation may vary
  • SLA Service Level Agreement between DS Domains

DiffServ terminology
  • SLA contains non-technical aspects
  • Service Level Specification (SLS)
  • Parameters which determine theservice provided
    by a DS domain
  • contains Traffic Conditioning Spec. (TCS),and
    other properties such as encryptionand routing
  • DiffServ Codepoint (DSCP) - IPv4 Precedence / TOS
  • DSCP mapped to Per Hop Behaviour (PHB)
  • how are packets treated in the core?
  • Aggregated flows with same DSCP Behaviour
    Aggregate (BA)
  • Distinguish PHB specification / implementation
  • PHB Group PHBs that call for similar spec. /

DiffServ details
  • Edge routers MF and BA classificationbased on
    signaling, metering .. or ideas such as simply
    UDP / TCP
  • Expedited Forwarding (EF) PHB
  • "Virtual Leased Line" Service
  • Aggregated flows must not exceed peak bandwidth
  • Ingress Router Policing (dropping) Egress
    Router shaping
  • Small delay - real time apps simple service
  • Unused bandwidth used by best-effort traffic!
  • Assured Forwarding (AF) PHB Group
  • Supports bursty flows
  • Packets are marked with AF Class and Drop
  • non-conforming packets are remarked

DiffServ details /2
  • DiffServ does not define
  • End2end service models
  • Implementation details (PHBs, traffic
    conditioners, ..)
  • But hints
  • As in ATM ABR, "open" spec. leads to a lot of
    research work
  • Implementation examples
  • schedulers for PHB WFQ, CBQ, WRR (Weighted Round
    Robin), ..
  • policers for drop precedence Weighted RED, RIO -
    RED variants which drop according to priorities
  • shapers for traffic conditioningLeaky Bucket -
    enforces CBR, may drop!
  • meters for drop precedence marking
  • Token Bucket(s) with various thresholds("A
    Single Rate Three Color Marker")

DiffServ extensions / ideas
  • IntServ over DiffServ
  • may be good idea fine granularity of IntServ /
    RSVP signaling at edge routers end systems,
    scalability through DiffServ core
  • IntServ flows are aggregated for DiffServ
  • DiffServ does not participate in RSVP signaling
  • IntServ treats DS Domains (EF PHB!) as a leased
  • Bandwidth Broker
  • additional network nodes for signaling and
  • translation SLS -gt TCS
  • explicit communication with edge routers, e.g.
    via COPS
  • Open specification brought some chaos, tooRed /
    green / blue packets, assured / premium service,
    Gold / Silver / Bronze olympic services .. what
    is real?

QoS Routing
  • IntServ and DiffServ assume shortest-path
    routing!Not always optimal some flows may
    prefer a "long, fat pipe"
  • Solution classify / meter, then forward
    according to requirements
  • Knowledge of a path's QoS properties additional
    routing metrics(increases routing protocol
  • Problems
  • scalability / oscillation - if QoS Routing is
    done for many sourcesquality reduced by own
    payload! use old path again?
  • when / how often is QoS measured / calculated?
  • QoS Routing not yet a real issue in IETF(WG only
    produced framework, OSPF QoS extensions

Traffic Engineering
  • Static configuration administrators want to move
    some traffic
  • based on long-term measurements
  • IP-in-IP tunneling example
  • B encapsulates packets (new srcB, dstC), C
    removes new header

From traffic engineering to MPLS
  • Layer violation
  • If you are tunneling along a fixed path and your
    network is ATM, you could just as well set up a
    VC for the path - faster forwarding!
  • Automatic variant Ipsilon IP Switching
  • Switches identify flow (MF classification),
    establish ATM-VC "Short-Cut"
  • Does not scale well - fine granularity
  • Better Multiprotocol Label Switching (MPLS)
  • Not just (but mostly) ATM, even LANs!
  • based upon separation of forwarding and control
    functionality in routers
  • Label put short info. (from layer 2) in front of
    IP (like IP encapsulation)
  • Label Switching Routers (LSR) forward on Label
    Switched Path (LSP)
  • At destination remove label, forward IP packet

Multi Protocol Label Switching (MPLS)
  • Forwarding Equivalence Class (FEC)
  • Group of packets with similar expected treatment
    (usually same label)
  • Various forms of classification possible (MF, ..)
  • What if labeled packets are labeled again?
  • Labels are stacked (push, pop, swap poppush,
    connects two LSPs )

MPLS details
  • Label designed for speed
  • 32 bit
  • S1 this is the last label
  • TTL is the only IP header field that MUST be
    treated at each hop
  • Labels distributed via Label Distribution
    Protocol (LDP)
  • MPLS applications
  • Traffic engineering (like IP-in-IP tunneling)
  • Split load by establishing more LSPs for one FEC
  • Virtual Private Networks (VPNs)
  • First aid if links go down (switch to different
  • QoS support

QoS support with MPLS
  • Obvious choices
  • IntServ over MPLS
  • set up a label switched RSVP tree
  • RSVP-TE protocol RSVP extension MPLS-specific
    information in messages (LABEL_REQUEST in PATH,
    LABEL in RSV, ..)
  • DiffServ over MPLS
  • CR-LDP protocol LDP extended with traffic
  • Group packets according to DSCP
  • Set up E/L - LSPs via LDP or RSVP
  • E-LSP EF and AF1 packets transmitted on same
    LSP, but differentqueues (based on experimental
  • L-LSP EF and AF1 packets on different LSPs,
    different queues

Multi Protocol Lambda Switching (MP?S)
  • Wavelength Division Multiplexing (WDM)
  • frequency multiplexing for optical tranmission
  • optical packet switches - switches based on
  • problems contention (signals with same colour
    overlap), ...
  • IP over WDM difficult to realizeeasier if
    connection oriented
  • Achieved via MPLS (Wavelength label) -gt MP?S
  • MP?S switches can be connected via ?'s for
    default-routing and signaling (similar to MPLS
    lt-gt ATM VC)
  • Even heavier layer violation!

Internet Protocol Version 6 (IPv6, IPNG)
  • Different addresses (much bigger! but makes
    migration hard)
  • Some header fields removed
  • Multicast - IGMP now part of ICMP
  • New optional header extensions(IPSec problematic
    for MF classification!)
  • QoS support
  • DiffServ field / flow label instead of ToS /
    precedence...for easier flow classification (no
    further semantics defined)

Main IPv6 Header
Optional extension headers
Fragmentation only in hosts!
Transition From IPv4 To IPv6
  • Not all routers can be upgraded simultaneous
  • no flag days
  • How will the network operate with mixed IPv4 and
    IPv6 routers?
  • Several approaches
  • Dual Stack some routers with dual stack (v6, v4)
    can translate between formats (example path
    v6 ? v6_2_v4 ? v4_2_v6 ? v6)
  • Tunneling IPv6 carried as payload in IPv4
    datagram among IPv4 routers
  • IPv6/IPv4 network address and protocol
    translation serious recent efforts
  • Short-term solution Network Address Translator
  • assumption at time t, only x out of y hosts
    communicate with outside world? use unique
    translation tables ( state!) to map x local to
    x global addresses
  • NAT extension NAPT (Network Address / Port
  • map local ip addr. / (tcp or udp) port no. pair
    to globally unique ip address / port no.
  • advantage 1 globally unique ip address can be
    used by several local hosts at once
  • disadvantage problems with specific port numbers

Some NAT trouble (there is more!)
  • Problem realm-specific IP address in payload
  • Solution per-app treatment by ALG (Application
    Level Gateway)
  • Problem IPSec encryption at lower layer
    (transparent to the app)
  • Solution implement lower-layer decryption
    encryption in ALG
  • ...
  • IP fragmentationsemantics of IP address /port
    number pair lost atIP layer -gt wrong reassembly!

ignored by IP layer!
  • NATs break the end-to-end model
  • complicated functions (state, ..) in the network
  • special per-application functionality at lower

Internet2 Qbone Initiative
  • Internet2 - http//
  • partnership of over 130 universities, 40
    corporations and 30 other organizations (numbers
    of fall '99)
  • One Internet2 objective (there are others)
  • engineer scalable, interoperable, and
    administrable interdomain QoS to support advanced
    networked applications
  • Qbone - http//
  • an interdomain testbed to enable Internet2 QoS
  • driven by input and work from
  • Internet2 QoS Working Group
  • Internet2/Qbone Bandwidth Broker Advisory Council
  • To participate, you must make your network part
    of Internet2!

IP QoS lessons learned
Some QoS rules
  • Scalability above everything!
  • especially avoid per flow state
  • avoid state alltogether
  • consider hierarchical structures for state
  • QoS guarantees need a consistent end2end service
  • If hard guarantees are impossible, consider
    "softer" QoS
  • Consider interactions with end system congestion
  • Layer violations may be necessary
  • Either "manage unfairness" or be fair (Internet

The Future
History again