EECS 122: Introduction to Computer Networks Midterm II Review

1
EECS 122 Introduction to Computer Networks
Midterm II Review

• Computer Science Division
• Department of Electrical Engineering and Computer
  Sciences
• University of California, Berkeley
• Berkeley, CA 94720-1776

2
Topics to be Covered

• Transport Protocols
• Congestion Control and Congestion Avoidance
  concepts, TCP variants
• QoS (Packet Scheduling) and Congestion Control
  (RED) Mechanisms
• Fluid Model and Token Bucket method
• Essential DiffServ and IntServ Concepts
• PD Sections 5.1, 5.2, 6.1- 6.3, 6.4.2, 6.5.1-
  6.5.3
• Project 2 Specification

3
Topics to be Covered

• Transport Protocols
• Congestion Control and Congestion Avoidance
  concepts, TCP variants
• QoS (Packet Scheduling) and Congestion Control
  (RED) Mechanisms
• Fluid Model and Token Bucket method
• Essential DiffServ and IntServ Concepts

4
Transport Layer

• Provide a way to decide which packets go to which
  applications (multiplexing/demultiplexing)
• Can provide more reliability, in order delivery,
  at most once delivery
• Can support messages of arbitrary length
• Govern when hosts should send data ? can
  implement congestion and flow control

5
UDP

• User Datagram Protocol
• Minimalist transport protocol
• Same best-effort service model as IP
• Messages up to 64KB
• Provides multiplexing/demultiplexing to IP
• Does not provide flow and congestion control
• Application examples video/audio streaming

6
TCP

• Transmission Control Protocol
• Reliable, in-order, and at most once delivery
• Messages can be of arbitrary length
• Provides multiplexing/demultiplexing to IP
• Provides congestion control and avoidance
• Application examples file transfer, chat

7
TCP Service

• Open connection
• Reliable byte stream transfer from (IPa, TCP
  Port1) to (IPb, TCP Port2)
• Indication if connection fails Reset
• Close connection

8
Flow Control vs. Congestion Control

• Flow control regulates how much data can a
  sender send without overflowing the receiver
• Congestion control regulates how much data can a
  sender send without congesting the network
• Congestion dropping packets into the network due
  to buffer overflow at routers

9
Congestion Window (cwnd)

• Limits how much data can be in transit, i.e., how
  many unacknowledged bytes can the sender send

AdvertisedWindow is used for flow control
MaxWindow min(cwnd, AdvertisedWindow)
EffectiveWindow MaxWindow (LastByteSent
LastByteAcked)
LastByteAcked
LastByteSent
sequence number increases
10
Topics to be Covered

• Transport Protocols
• Congestion Control and Congestion Avoidance
  concepts, TCP variants
• QoS (Packet Scheduling) and Congestion Control
  (RED) Mechanisms
• Fluid Model and Token Bucket method
• Essential DiffServ and IntServ Concepts

11
Why do You Care About Congestion Control?

• Otherwise you get to congestion collapse
• How might this happen?
• Assume network is congested (a router drops
  packets)
• You learn the receiver didnt get the packet
• Either by ACK or Timeout
• What do you do?
• Retransmit packet
• Still receiver didnt get the packet (because it
  is dropped again)
• Retransmit again
• . and so on
• And now assume that everyone is doing the same!
• Network will become more and more congested
• And this with duplicate packets rather than new
  packets!

12
Solutions?

• Increase buffer size. Why not?
• Slow down
• If you know that your packets are not delivered
  because network congestion, slow down
• Questions
• How do you detect network congestion? Use packet
  loss as indication!
• By how much do you slow down?

13
TCP Slow Start

• Goal discover congestion quickly
• How?
• Quickly increase cwnd until network congested ?
  get a rough estimate of the optimal size of cwnd
• Whenever starting traffic on a new connection, or
  whenever increasing traffic after congestion was
  experienced
• Set cwnd 1
• Each time a segment is acknowledged increment
  cwnd by one (cwnd).

14
Slow Start Example
segment 1
cwnd 1

• The congestion window size grows very rapidly
• TCP slows down the increase of cwnd when cwnd gt
  ssthresh

cwnd 2
segment 2
segment 3
cwnd 3
cwnd 4
segment 4
segment 5
segment 6
segment 7
cwnd 8
15
Congestion Avoidance

• Additive increase starting from the rough
  estimate, slowly increase cwnd to probe for
  additional available bandwidth
• Multiplicative decrease cut congestion window
  size aggressively if a timeout occurs
• If cwnd gt ssthresh then each time a segment is
  acknowledged increment cwnd by 1/cwnd (cwnd
  1/cwnd).

16
Slow Start/Congestion Avoidance Example

• Assume that ssthresh 8

ssthresh
Cwnd (in segments)
Roundtrip times
17
Putting Everything TogetherTCP Pseudocode

• Initially
• cwnd 1
• ssthresh infinite
• New ack received
• if (cwnd lt ssthresh)
• / Slow Start/
• cwnd cwnd 1
• else
• / Congestion Avoidance /
• cwnd cwnd 1/cwnd
• Timeout
• / Multiplicative decrease /
• ssthresh cwnd/2
• cwnd 1

18
The big picture
cwnd
Timeout
Congestion Avoidance
Slow Start
sstresh
Time
19
Packet Loss Detection

• Wait for Retransmission Time Out (RTO)
• Whats the problem with this?
• Because RTO is performance killer
• In the BSD TCP implementation, RTO is usually
  more than 1 second
• The granularity of RTT estimate is 500 ms
• Retransmission timeout is at least two times RTT
• Solution Dont wait for RTO to expire

20
Fast Retransmit

• Resend a segment after 3 duplicate ACKs
• Remember, a duplicate ACK means that an out-of
  sequence segment was received
• Notes
• Duplicate ACKs due packet reordering!
• If window is small dont get duplicate ACKs!

ACK 2
cwnd 2
segment 2
segment 3
ACK 3
ACK 4
cwnd 4
segment 4
segment 5
segment 6
segment 7
ACK 4
ACK 4
3 duplicate ACKs
21
Fast Recovery

• After a fast-retransmit set cwnd to ssthresh/2
• i.e., dont reset cwnd to 1
• But when RTO expires still do cwnd 1
• Fast Retransmit and Fast Recovery ? implemented
  by TCP Reno most widely used version of TCP
  today

22
Fast Retransmit and Fast Recovery
cwnd
Congestion Avoidance
Slow Start
Fast retransmit
Time

• Retransmit after 3 duplicated acks
• Prevent expensive timeouts
• No need to slow start again
• At steady state, cwnd oscillates around the
  optimal cwnd size

23
TCP Flavors

• TCP-Tahoe
• cwnd 1 whenever drop is detected
• TCP-Reno
• cwnd 1 on timeout
• cwnd cwnd/2 on dupack
• TCP-newReno
• TCP-Reno improved fast recovery
• TCP-Vegas, TCP-SACK

24
TCP Vegas

• Improved timeout mechanism
• Decrease cwnd only for losses sent at current
  rate
• Avoids reducing rate twice
• Congestion avoidance phase
• Compare Actual rate (A) to Expected rate (E)
• If E-A gt ?, decrease cwnd linearly
• If E-A lt ?, increase cwnd linearly
• Rate measurements delay measurements
• See textbook for details!

25
TCP-SACK

• SACK Selective Acknowledgements
• ACK packets identify exactly which packets have
  arrived
• Makes recovery from multiple losses much easier

26
Topics to be Covered

• Transport Protocols UDP, TCP and its many
  variations
• Congestion Control and Congestion Avoidance
  concepts
• QoS (Packet Scheduling) and Congestion Control
  (RED) Mechanisms
• Fluid Model and Token Bucket method
• Essential DiffServ and IntServ Concepts

27
Packet Scheduling

• Decide when and what packet to send on output
  link
• Usually implemented at output interface of a
  router

flow 1
flow 2
Classifier
Scheduler
1
2
flow n
Buffer management
28
Goals of Packet Scheduling

• Provide per flow/aggregate QoS guarantees in
  terms of delay and bandwidth
• Provide per flow/aggregate protection
• Flow/Aggregate identified by a subset of
  following fields in the packet header
• source/destination IP address (32 bits)
• source/destination port number (16 bits)
• protocol type (8 bits)
• type of service (8 bits)
• Examples
• All packets from machine A to machine B
• All packets from Berkeley
• All packets between Berkeley and MIT
• All TCP packets from EECS-Berkeley

29
Random Early Detection (RED)

• Basic premise
• Router should signal congestion when the queue
  first starts building up (by dropping a packet)
• But router should give flows time to reduce their
  sending rates before dropping more packets
• Therefore, packet drops should be
• Early dont wait for queue to overflow
• Random dont drop all packets in burst, but
  space drops out

30
RED Advantages

• High network utilization with low delays
• Average queue length small, but capable of
  absorbing large bursts
• Many refinements to basic algorithm make it more
  adaptive (requires less tuning)

31
Explicit Congestion Notification

• Rather than drop packets to signal congestion,
  router can send an explicit signal
• Explicit congestion notification (ECN)
• Instead of optionally dropping packet, router
  sets a bit in the packet header
• If data packet has bit set, then ACK has ECN bit
  set
• Backward compatibility
• Bit in header indicates if host implements ECN
• Note that not all routers need to implement ECN

32
ECN Advantages

• No need for retransmitting optionally dropped
  packets
• No confusion between congestion losses and
  corruption losses

33
Topics to be Covered

• Transport Protocols UDP, TCP and its many
  variations
• Congestion Control and Congestion Avoidance
  concepts
• QoS (Packet Scheduling) and Congestion Control
  (RED) Mechanisms
• Fluid Model and Token Bucket method
• Essential DiffServ and IntServ Concepts

34
Token Bucket and Arrival Curve

• Parameters
• r average rate, i.e., rate at which tokens fill
  the bucket
• b bucket depth
• R maximum link capacity or peak rate (optional
  parameter)
• A bit is transmitted only when there is an
  available token
• Arrival curve maximum number of bits
  transmitted within an interval of time of size t

Arrival curve
r bps
bits
slope r
bR/(R-r)
b bits
slope R
lt R bps
time
regulator
35
Source Traffic Characterization

• Arrival curve maximum amount of bits
  transmitted during an interval of time ?t
• Use token bucket to bound the arrival curve

bits
bps
Arrival curve
?t
time
36
Source Traffic Characterization Example

• Arrival curve maximum amount of bits
  transmitted during an interval of time ?t
• Use token bucket to bound the arrival curve

Arrival curve
bits
4
bps
3
2
2
1
1
?t
0
1
2
3
4
5
1
2
3
4
5
time
37
QoS Guarantees Per-hop Reservation

• End-host specify
• the arrival rate characterized by token-bucket
  with parameters (b,r,R)
• the maximum maximum admissible delay D, no losses
• Router allocate bandwidth ra and buffer space Ba
  such that
• no packet is dropped
• no packet experiences a delay larger than D

slope ra
slope r
bits
Arrival curve
bR/(R-r)
R
38
Packet Scheduling and Fair Queuing

• Make sure that at any time the flow receives at
  least the allocated rate ra
• The canonical example of such scheduler Weighted
  Fair Queueing (WFQ)
• Implements max-min fairness each flow receives
  min(ri, f) , where
• ri flow arrival rate
• f link fair rate (see next slide)
• Weighted Fair Queueing (WFQ) associate a weight
  with each flow

39
Fluid Flow System Example
link

• Red flow has packets backlogged between time 0
  and 10
• Backlogged flow ? flows queue not empty
• Other flows have packets continuously backlogged
• All packets have the same size

flows
weights
5
1
1
1
1
1
0
15
2
10
4
6
8
40
Packet System Example
Service in fluid flow system
0
2
10
4
6
8

• Select the first packet that finishes in the
  fluid flow system

Packet system
0
2
10
4
6
8
41
Example Problem 6.14 (a)
link capacity (C) 1 packet size 1
A
wall clock
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Arrival patterns
B
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
42
Solution Virtual Time

• Key Observation while the finish times of
  packets may change when a new packet arrives, the
  order in which packets finish doesnt!
• Only the order is important for scheduling
• Solution instead of the packet finish time
  maintain the number of rounds needed to send the
  remaining bits of the packet (virtual finishing
  time)
• Virtual finishing time doesnt change when the
  packet arrives
• System virtual time index of the round in the
  bit-by-bit round robin scheme

43
Example Problem 6.14 (a)
V(t) - virtual systemtime
C link capacity N(t) total weight of
backlogged flows
1/3
3
1/2
2.5
1/3
1.5
1/2
wall clock
2
3
4
5
6
7
8
9
10
12
13
14
15
11
16
17
18
19
20
21
1
A,1
A,2
A,4
A,6
A,7
A,9
A,10
B,2
B,6
B,8
B,11
B,12
B,15
C,1
C,2
C,3
C,5
C,6
C,7
C,8
wall clock
1
2
3
4
5
6
7
8
9
10
12
13
14
15
11
16
17
18
19
20
21
44
Properties of WFQ

• Guarantee that any packet is transmitted within
  packet_lengt/link_capacity of its transmission
  time in the fluid flow system
• Can be used to provide guaranteed services
• Achieve max-min fair allocation
• Can be used to protect well-behaved flows against
  malicious flows

45
What You Need to Know

• Basic concepts
• Arrival curve
• Token-bucket specification
• System virtual time / finish virtual time
• WFQ properties
• Link sharing requirements and challenges
• Bandwidth-delay coupling problem
• Mechanisms
• WFQ implementation in the fluid flow packet
  system

46
Topics to be Covered

• Transport Protocols UDP, TCP and its many
  variations
• Congestion Control and Congestion Avoidance
  concepts
• QoS (Packet Scheduling) and Congestion Control
  (RED) Mechanisms
• Fluid Model and Token Bucket method
• Essential DiffServ and IntServ Concepts

47
Differentiated Services

• Some traffic should get better treatment
• Application requirements interactive vs. bulk
  transfer
• Economic arrangements first-class versus coach
• What kind of better service could you give?
• Measured by drops, or delay (and drops)
• How do you know which packets to give better
  service?
• Bits in packet header

48
Advantages of DiffServ

• Very simple to implement
• Can be applied at different granularities
• Flows
• Institutions
• Traffic types
• Marking can be done at edges or by hosts
• Allows easy peering (bilateral SLAs)

49
Disadvantages of DiffServ

• Service is still best effort, just a better
  class of best effort
• Except for EF, which has terrible efficiency
• All traffic accepted (within SLAs)
• Some applications need better than this
• Certainly some apps need better service than
  todays Internet delivers
• But perhaps if DiffServ were widely deployed
  premium traffic would get great service (recall
  example)

50
Integrated Services

• Attempt to integrate service for real-time
  applications into the Internet
• Known as IntServ
• Total, massive, and humiliating failure
• 1000s of papers
• IETF standards
• and STILL no deployment ...

51
Resource Reservation Protocol RSVP

• Establishes end-to-end reservations over a
  datagram network
• Designed for multicast (which will be covered
  later)
• Sources send TSpec
• Receivers respond with RSpec Network
• Network responds to reservation requests

52
Advantages of IntServ

• Precise QoS delivered at flow granularities
• Good service, given exactly to who needs it
• Decisions made by hosts
• Who know what they need
• Not by organizations, egress/ingress points, etc.
• Fits multicast and unicast traffic equally well

53
Disadvantages of IntServ

• Scalability per-flow state, classification, etc.
• Goofed big time
• Aggregation/encapsulation techniques can help
• Can overprovision big links, per-flow ok on small
  links
• Scalability can be fixed, but no second chance
• Economic arrangements
• Need sophisticated settlements between ISPs
• Right now, settlements are primitive (barter)
• User charging mechanisms need QoS pricing

54
What You Need to Know

• Three kinds of QoS approaches
• Link sharing, DiffServ, IntServ
• Some basic concepts
• Differentiated dropping versus service priority
• Per-flow QoS (IntServ) versus per-aggregate QoS
  (DiffServ)
• Admission control parameter versus measurement
• Control plane versus data plane
• Controlled load versus guaranteed service
• Codepoints versus explicit signaling
• Various mechanisms
• Playback points
• Token bucket
• RSVP PATH/RESV messages