katz, stoica f04 eecs 122: introduction to computer networks midterm ii review computer science...

Katz, Stoica F04

EECS 122: Introduction to Computer Networks

Midterm II Review

Computer Science DivisionDepartment of Electrical Engineering and Computer Sciences

University of California, BerkeleyBerkeley, CA 94720-1776

2Katz, Stoica F04

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

P&D: Sections 5.1, 5.2, 6.1- 6.3, 6.4.2, 6.5.1- 6.5.3 Project #2 Specification

3Katz, Stoica F04





4Katz, Stoica F04

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

5Katz, Stoica F04

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

6Katz, Stoica F04

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

7Katz, Stoica F04

TCP Service

1) Open connection2) Reliable byte stream transfer from

(IPa, TCP Port1) to (IPb, TCP Port2)• Indication if connection fails: Reset

3) Close connection

8Katz, Stoica F04

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

9Katz, Stoica F04

Congestion Window (cwnd)

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

EffectiveWindow = MaxWindow – (LastByteSent – LastByteAcked)

MaxWindow = min(cwnd, AdvertisedWindow)

LastByteAcked LastByteSent

sequence number increases

AdvertisedWindow is used for flow control

10Katz, Stoica F04





11Katz, Stoica F04

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 didn’t get the packet

• Either by ACK or Timeout- What do you do? - Retransmit packet- Still receiver didn’t 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!

12Katz, Stoica F04

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?

13Katz, Stoica F04

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

14Katz, Stoica F04

Slow Start Example

The congestion window size grows very rapidly

TCP slows down the increase of cwnd when cwnd >= ssthresh

segment 1cwnd = 1

cwnd = 2segment 2segment 3

cwnd = 4 segment 4

segment 5segment 6segment 7

cwnd = 8

cwnd = 3

15Katz, Stoica F04

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 > ssthresh then each time a segment is acknowledged increment cwnd by 1/cwnd (cwnd += 1/cwnd).

16Katz, Stoica F04

Slow Start/Congestion Avoidance Example

Assume that ssthresh = 8

cwnd = 1

cwnd = 2

cwnd = 4

cwnd = 8

cwnd = 9

cwnd = 10

02468

101214

t=0 t=2 t=4 t=6

Roundtrip times

Cw

nd (i

n se

gmen

ts)

ssthresh

17Katz, Stoica F04

Putting Everything Together:TCP PseudocodeInitially:

cwnd = 1;ssthresh = infinite;

New ack received:if (cwnd < ssthresh) /* Slow Start*/ cwnd = cwnd + 1;else /* Congestion Avoidance */ cwnd = cwnd + 1/cwnd;

Timeout:/* Multiplicative decrease */ssthresh = cwnd/2;cwnd = 1;

18Katz, Stoica F04

The big picture

Time

cwnd

Timeout

Slow Start

CongestionAvoidance

sstresh

19Katz, Stoica F04

Packet Loss Detection

Wait for Retransmission Time Out (RTO) What’s 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: Don’t wait for RTO to expire

20Katz, Stoica F04

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 don’t

get duplicate ACKs!

ACK 2

segment 1cwnd = 1

cwnd = 2 segment 2segment 3

ACK 4cwnd = 4 segment 4

segment 5segment 6segment 7

ACK 3

3 duplicateACKs

ACK 4

ACK 4

21Katz, Stoica F04

Fast Recovery

After a fast-retransmit set cwnd to ssthresh/2- i.e., don’t 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

22Katz, Stoica F04

Fast Retransmit and Fast Recovery

Retransmit after 3 duplicated acks- Prevent expensive timeouts

No need to slow start again At steady state, cwnd oscillates around the

optimal cwnd size

Time

cwnd

Slow Start

CongestionAvoidance

Fast retransmit

23Katz, Stoica F04

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

24Katz, Stoica F04

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 > , decrease cwnd linearly- If E-A < , increase cwnd linearly- Rate measurements ~ delay measurements- See textbook for details!

25Katz, Stoica F04

TCP-SACK

SACK = Selective Acknowledgements

ACK packets identify exactly which packets have arrived

Makes recovery from multiple losses much easier

26Katz, Stoica F04


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

27Katz, Stoica F04

Packet Scheduling Decide when and what packet to send on output link

- Usually implemented at output interface of a router

1

2

Scheduler

flow 1

flow 2

flow n

Classifier

Buffer management

28Katz, Stoica F04

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

29Katz, Stoica F04

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: don’t wait for queue to overflow- Random: don’t drop all packets in burst, but space

drops out

30Katz, Stoica F04

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)

31Katz, Stoica F04

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

32Katz, Stoica F04

ECN Advantages

No need for retransmitting optionally dropped packets

No confusion between congestion losses and corruption losses

33Katz, Stoica F04






34Katz, Stoica F04

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

r bps

b bits

<= R bps

regulatortime

bits

b*R/(R-r)

slope R

slope r

Arrival curve

35Katz, Stoica F04

Source Traffic Characterization

Arrival curve – maximum amount of bits transmitted during an interval of time Δt

Use token bucket to bound the arrival curve

Δt

bits

Arrival curve

time

bps

36Katz, Stoica F04

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

bitsArrival curve

time

bps

0 1 2 3 4 5

1

2

1 2 3 4 5

1

2

3

4

(R=2,b=1,r=1)

Δt

37Katz, Stoica F04

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

bits

b*R/(R-r)

slope rArrival curve

DBa

slope ra

R

38Katz, Stoica F04

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

39Katz, Stoica F04

Fluid Flow System: Example

0 152 104 6 8

5 1 1 11 1

Red flow has packets backlogged between time 0 and 10

- Backlogged flow flow’s queue not empty

Other flows have packets continuously backlogged

All packets have the same size

flows

link

weights

40Katz, Stoica F04

Packet System: Example

0 2 104 6 8

0 2 104 6 8

Select the first packet that finishes in the fluid flow system

Servicein fluid flow

system

Packetsystem

41Katz, Stoica F04

Example: Problem 6.14 (a)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

A

B

C

A,1C,1 B,2 A,2

C,21 2 3 4 5 6 7 8 9 10

A,4B,6C,3

A,6B,8C,5

A,7B,11C,6

A,9B,12C,7

A,10B,15C,8

12 13 14 1511 16 17 18 19 20 21 wall clock

wall clock

1 2 3 4 5 6 7 8 9 10 12 13 14 1511 16 17 18 19 20 21 wall clock

link capacity (C) = 1; packet size = 1

Fluidsystem

Packetsystem

Arrivalpatterns

42Katz, Stoica F04

Solution: Virtual Time

Key Observation: while the finish times of packets may change when a new packet arrives, the order in which packets finish doesn’t!

- 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 doesn’t change when the packet arrives System virtual time – index of the round in the bit-by-bit

round robin scheme

43Katz, Stoica F04

Example: Problem 6.14 (a)

A,1C,1 B,2 A,2

C,21 2 3 4 5 6 7 8 9 10

A,4B,6C,3

A,6B,8C,5

A,7B,11C,6

A,9B,12C,7

A,10B,15C,8

12 13 14 1511 16 17 18 19 20 21 wall clock

2 3 4 5 6 7 8 9 10 12 13 14 1511 16 17 18 19 20 21 wall clock

V(t) -virtualsystemtime

1

1/31/2

1/3

1/21.5

2.53

)()(

tNC

ttV

C – link capacityN(t) – total weight of backlogged flows

44Katz, Stoica F04

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

45Katz, Stoica F04

What You Need to Know

Basic concepts- Arrival & service 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

You don’t need to know- Details of WF2Q- How service curve works

46Katz, Stoica F04






47Katz, Stoica F04

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

48Katz, Stoica F04

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)

49Katz, Stoica F04

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 today’s

Internet delivers- But perhaps if DiffServ were widely deployed premium

traffic would get great service (recall example)

50Katz, Stoica F04

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

51Katz, Stoica F04

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

52Katz, Stoica F04

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

53Katz, Stoica F04

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

54Katz, Stoica F04

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

katz, stoica f04 eecs 122: introduction to computer networks midterm ii review computer science...

Documents