Midterm Review EE 122, Fall 2013 Sylvia Ratnasamy ee122/ Material thanks to Ion Stoica, Scott Shenker, Jennifer Rexford,

Midterm Review

EE 122, Fall 2013

Sylvia Ratnasamy

http://inst.eecs.berkeley.edu/~ee122/

Material thanks to Ion Stoica, Scott Shenker, Jennifer Rexford, Nick McKeown, and many other colleagues



Logistics

Test is in this classroom starting at 5:40 exactly

Closed book, closed notes, etc.

Single two-sided “cheat sheet”, 8pt minimum

No calculators, electronic devices, etc. Test does not require any complicated calculation

I will have extra office hours tomorrow, Oct 22. 11am-1pm in 413 Soda Hall

General Guidelines (1)

Test only assumes material covered in lecture & sections Text: only to clarify details and context for the above

The test doesn’t require you to do complicated calculations or packet accounting Use this as a hint to whether you are on the right track

You don’t need to memorize packet headers We’ll provide the IP header for your reference on the exam sheet

You do need to understand how things work not for the sake of knowing gory details but to understand pros/cons,

when a solution is applicable/useful/useless, etc.


Be prepared to:

Weigh design options outside of the context we studied them in

e.g., I had a TCP connection, then BGP went nuts…”

Contemplate new designs we haven’t talked about e.g., I introduce a new IP address format; how does this affect..” e.g., I take a little bit of UDP, mix it with some TCP sliding window..”

Don’t let this daunt you. Reason from what you know about the pros/cons of solutions we did study e.g., TCP is inefficient when…


Exam format (tentative!)Q1) 20 multiple-choice questions

ordered (roughly) from easiest to hardest

Q2) A set of “here’s a scenario, tell me if the following is true/false”-style questions

ordered (roughly) from easiest to hardest within each scenario

Q3,4,5,6: more traditional questions (we think) 3 < 4 < 5 < 6 (< implies easier than) sub-questions within each question ordered easiest to hardest

Pace yourself accordingly.

This Review

Walk through what we expect you to know: key topics, important aspects of each

Just because I didn’t cover it in review doesn’t mean you don’t need to know it But if I covered it today, you should know it

My plan: summarize, not explain Stop me when you want to discuss something further!

Topics

Architecture: concepts and principles (lecs. 2, 3) IP Routing (lecs. 4-9)

Overall context Computing routes (DV, LS, path vector) IP addressing Inter-domain Router architecture

Transport (lecs. 10-13) Role of the transport layer UDP vs. TCP TCP details: reliability, flow and congestion control

Fairness and Router-assisted CC (lec. 13)

Architecture

Concepts you should be familiar with packet delays packet vs. circuit switching statistical multiplexing layering end-to-end argument and best-effort service

Properties of Links

Bandwidth (capacity): “width” of the link number of bits sent (or received) per unit time (bits/sec or bps)

Latency (delay): “length” of the link propagation time for data to travel along the link (seconds)

Bandwidth-Delay Product (BDP): “volume” of the link amount of data that can be “in flight” at any time

bandwidth

Latency

delay x bandwidth

time=0

Packet DelaySending a 100B packet from A to B?

A B

100Byte packet

Time

1Mbps, 1ms

Time to transmit 800 bits=800x1/106s

The last bit reaches B at

(800x1/106)+1/103s= 1.8msPacket Delay = Transmission Delay + Propagation Delay

Packet Delay = (Packet Size ÷ Link Bandwidth) + Link Latency

Circuit switching

(1) Node A sends a reservation request(2) Interior switches establish a connection -- i.e., “circuit”(3) A starts sending data(4) A sends a “teardown circuit” message

Idea: source reserves network capacity along a path

A B

Circuit switching: pros and cons

Pros guaranteed performance fast transfers (once circuit is established)

Cons wastes bandwidth if traffic is “bursty” connection setup adds delay recovery from failure is slow

Packet Switching

Data is sent as chunks of formatted bits (Packets)

Packets consist of a “header” and “payload”

Switches “forward” packets based on their headers

Each packet travels independently

No link resources are reserved in advance. Instead packet switching leverages statistical multiplexing

Packet switching: pros and cons

Cons no guaranteed performance header overhead per packet queues and queuing delays

Pros efficient use of bandwidth (stat. muxing) no overhead due to connection setup resilient -- can `route around trouble’

Data Rate 1

Data Rate 2

Data Rate 3

Statistical Multiplexing: Three Flows with Bursty Traffic

Time

Time

TimeCapacity

Data Rate 1

Data Rate 2

Data Rate 3

When Each Flow Gets 1/3rd of Capacity

Time

Time

Time

Frequent Overloading

When Flows Share Total Capacity

Time

Time

Time

No Overloading

Statistical Multiplexing

Allows efficient use of network bandwidth

Relies on the assumption that not all flows burst at the same time similar assumption and failure case as insurance

Queues absorb transient traffic bursts but also introduce queuing delay We will not be asking you to do detailed calculations

of queuing delay on the test

Layering

Layering is a particular form of modularization

System is broken into a vertical hierarchy of logically distinct entities (layers)

Service provided by one layer is based solely on the service provided by layer below

Rigid structure: easy reuse, performance suffers

In the context of the Internet

Applications

…built on…

…built on…

…built on…

…built on…

Reliable (or unreliable) transport

Best-effort global packet delivery

Best-effort local packet delivery

Physical transfer of bits

Application

Transport

Network

Data link

PhysicalL1

L2

L3

L4

L7

This is not a typo

Protocols and Layers

Communication between peer layers ondifferent systems is defined by protocols

Application

Transport

Network

Data link

Physical L1

L2

L3

L4

L7Application

Transport

Network

Data link

PhysicalL1

L2

L3

L4

L7

Layer Encapsulation

Trans: Connection ID

Net: Source/Dest

Link: Src/Dest

Appl: Get index.html

User A User B

What gets implemented where? Lower three layers implemented everywhere Top two layers implemented only at hosts

Transport

Network

Datalink

Physical

Transport

Network

Datalink

Physical

Network

Datalink

Physical

Application Application

Host A Host BRouter

Protocols at different layers

There is just one network-layer protocol, IPThe “narrow waist” of the Internet hourglass

Application

Transport

Network

Data link

PhysicalL1

L2

L3

L4

L7 SMTP HTTP DNS NTP

TCP UDP

IP

Ethernet FDDI PPP

optical copper radio PSTN

Implications of Hourglass

Benefits of a single network-layer protocol (IP) Allows arbitrary networks to interoperate

Any network that supports IP can exchange packets Decouples applications from low-level

networking technologies Applications function on all networks

Benefits of Layering

Modularity allows abstraction and reuse Narrow waist allows interoperability Innovation at each layer can proceed in parallel

Drawbacks of Layering

Rigid structure may hurt performance Duplication of functionality Information hiding

(Secondary) Headers start to get really big Layer violations

for performance: e.g., TCP-over-wireless for security: e.g., firewalls

Summary of End-to-End Principle

Design principle guiding the placement of functionality in a (networked) system

Builds on observation that some application properties can only be correctly implemented end-to-end Reliability, security, etc.

Supporting these properties in the network may be unwise Doesn’t reduce host implementation complexity Does increase network complexity Might impose overhead on apps that don’t need the functionality

However, implementing in the network can improve performance in some cases

Key argument for why IP offers only “best-effort” delivery Reliability implemented at the endhost (TCP)

Topics





Context and Terminology

“End hosts”“Clients”, “Users”

“End points”

“Interior Routers”

“Border Routers”

“Autonomous System (AS)” or “Domain”Region of a network under a single administrative entity

“Route” or “Path”

Internet Routing

Internet Routing works at two levels

Each AS runs an intra-domain routing protocol that establishes routes within its domain Link State, e.g., Open Shortest Path First (OSPF) Distance Vector, e.g., Routing Information Protocol (RIP)

ASes participate in an inter-domain routing protocol that establishes routes between domains Path Vector, e.g., Border Gateway Protocol (BGP)

Link State Routing

Each node maintains its local “link state” (LS) Each node floods its local link state Hence, each node learns the entire network topology Can use an algorithm such as Dijkstra’s to compute

shortest paths

We won’t test your ability to solve Dijkstra’s under pressure But you should know the high level properties of LS

every node maintains complete topology link updates flooded everywhere may have transient loops while nodes have inconsistent topology

information

Distance Vector Routing

Each router knows the links to its neighbors

Each router has provisional “least cost” estimate to every other router -- its distance vector (DV) E.g.: Router A: “A can get to B with cost 11”

Routers exchange this DV with their neighbors

Routers look over the set of options offered by their neighbors and select the best one

Iterative process converges to set of shortest paths

DV: You should understand

How DV works what’s in a DV; how nodes process and update DVs

The counting to infinity problem why it occurs

Poison Reverse when it does/doesn’t fix counting-to-infinity

DV: Link Cost Changes

A C

A 4 6

C 9 1

Node B

A B

A 50 5

B 54 1

Node C

Link cost changes here

A C

A 60 6

C 65 1

A B

A 50 5

B 54 1

A C

A 60 6

C 110 1

A B

A 50 5

B 101 1

A C

A 60 6

C 110 1

A B

A 50 7

B 101 1

B C

B 4 51

C 5 50

Node A B C

B 60 51

C 61 50

B C

B 60 51

C 61 50

B C

B 60 51

C 61 50

A C

A 60 8

C 110 1

A B

A 50 7

B 101 1

B C

B 60 51

C 61 50

Stable state

A-B changed A sends its DV to B, C

B sends itsDV to A, C

C sends its DV to A, B

A C14

50

B60

“bad news travels slowly” (not yet converged)

to

via

This is the “Counting to Infinity” Problem

DV: Poisoned Reverse

A C

A 4 6

C 9 1

Node B

A B

A 50 5

B 54 1

Node C

Link cost changes here

A C

A 60 6

C 65 1

A B

A 50 5

B 54 1

A C

A 60 6

C 110 1

A B

A 50 5

B 101 1

A C

A 60 6

C 110 1

A B

A 50 61

B 101 1

B C

B 4 51

C 5 50

Node A B C

B 60 51

C 61 50

B C

B 60 51

C 61 50

B C

B 60 51

C 61 50

A B

A 50 61

B 101 1

B C

B 60 51

C 61 50

Stable state

A-B changed A sends its DV to B, C

B sends itsDV to A, C

C sends its DV to A, B

A C14

50

B60

to

via

If B routes through C to get to A: B tells C its (B’s) distance to A is infinite

∞

∞ ∞

∞ ∞

∞

∞

∞ ∞

A C

A 60 51

C 110 1

Converges after C receives another update from B

∞

“Count to Infinity”: root cause

A

B

C

• C’s path to A goes via B• C advertises its distance-to-A to B• When B’s link to A increases in cost; B thinks

it can get to A via C at a lower cost

“Poison Reverse”: key idea

A

B

C

• C’s path to A goes via B• C tells B its distance to A is infinity• When B’s link to A increases in cost; B no longer

thinks it can get to A via C at a lower cost

Topics





Addressing Goal: Scalable Routing

State: Small forwarding tables at routers Much less than the number of hosts

Churn: Limited rate of change in routing tables Traffic, inconsistencies, complexity

Ability to aggregate addresses is crucial for both

(one entry to summarize many addresses)

Hierarchy in IP Addressing

32 bits are partitioned into a prefix and suffix components Prefix is the network component; suffix is host component

Interdomain routing operates on the network prefix “slash” notation: 12.34.158.0/23 network with a 23 bit

prefix and 29 host addresses

00001100 00100010 10011110 00000101

Network (23 bits) Host (9 bits)

12 34 158 5

IP addressing scalable routing?

Hierarchical address allocation helps routing scalability if allocation matches topological hierarchy

Problem: may not be able to aggregate addresses for “multi-homed” networks similar problem with mobile hosts

Two competing forces in scalable routing aggregation reduces number of routing entries multi-homing increases number of entries

BGP and Inter-Domain Routing

Destinations are IP prefixes (12.0.0.0/8) Nodes are Autonomous Systems (ASes) Links represent both physical connections and

business relationships customer-provider or peer-to-peer

BGP is the protocol for inter-domain routing path-vector protocol policy-driven route selection

BGP extends DV

With some important differences routes selected based on policy, not just shortest path path vector (useful to avoid loops) may aggregate routes (aggregating prefixes)

Topology and policy is shaped by the business relationships between ASes

Three basic kinds of relationships between ASes AS A can be AS B’s customer AS A can be AS B’s provider AS A can be AS B’s peer

Business implications Customer pays provider Peers don’t pay each other

Exchange roughly equal traffic

Policy imposed in how routes are selected and exported

Selection: Which path to use? controls whether/how traffic leaves the network

Export: Which path to advertise? controls whether/how traffic enters the network

Can reach 128.3/16blah blah

Route selection

Customer

Competitor

1

5

10

Route export

Typical Export Policy

Destination prefix advertised by… Export route to…

CustomerEveryone

(providers, peers, other customers)

Peer Customers

Provider Customers

We’ll refer to these as the “Gao-Rexford” rules(capture common -- but not required! -- practice!)You must know this!

Typical Selection Policy

In decreasing order of priority make/save money (send to customer > peer > provider) maximize performance (smallest AS path length) minimize use of my network bandwidth (“hot potato”) …

BGP uses route attributes to implement the above ASPATH, LOCAL_PREF, MED, …

You should know the general idea/goal for each attribute; we won’t quiz you on the detailed implementation

Policy Dictates Route Selection

ASes provide “transit” between their customers Peers do not provide transit between other

peers

traffic allowed traffic not allowed

A B C

D E F

QPr Cu

Peer Peer

20 Bytes of Standard Header, then Options

4-bitVersion

4-bitHeaderLength

8-bitType of Service

(TOS)16-bit Total Length (Bytes)

16-bit Identification3-bitFlags 13-bit Fragment Offset

8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum

32-bit Source IP Address

32-bit Destination IP Address

Options (if any)

Payload

Comparison of Design Philosophy

Version IHL Type of Service Total Length

Identification Flags Fragment Offset

Time to Live Protocol Header Checksum

Source Address

Destination Address

Options Padding

Version Traffic Class Flow Label

Payload Length Next Header Hop Limit

Source Address

Destination Address

IPv4 IPv6

To Destination and Back (expanded)

Deal with Problems (greatly reduced)

Read Correctly (reduced)

Special Handling (similar)

Topics





What’s inside a router?

1

2

N

1

2

N

Linecards (input)

Interconnect(Switching)

Fabric

Route/Control Processor

Linecards (output)

Processes packets on their way in

Processes packets before they leave

Transfers packets from input to output ports

Input and Output for the same port are on one

physical linecard


1

2

N

1

2

N

Linecards (input)

Interconnect(Switching)

Fabric


Linecards (output)

(1) Implement IGP and BGP protocols;

compute routing tables(2) Push forwarding

tables to the line cards


1

2

N

1

2

N

Linecards (input)

InterconnectFabric


Linecards (output)

Constitutes the data plane

Constitutes the control plane

Challenges in Router Design

@ Line cards: destination lookups at high speed e.g., find the longest prefix match (LPM) in the table that matches

the packet destination address

@ Switch fabric: head-of-line blocking, scheduling the switch fabric at high speed

@ Route processor: complexity/correctness more a problem than performance

You should understand why these challenges arise but we don’t expect you to know how to fix them e.g., specifics of scheduling algorithms or LPM lookups

Topics





Role of the Transport Layer

Communication between application processes Mux and demux from/to application processes Implemented using ports

[Optionally] Provide common end-to-end services for app layer Reliable, in-order data delivery Well-paced data delivery

59

UDP vs. TCP

Both UDP and TCP provide multiplexing/demultiplexing via ports

UDP TCP

Data abstraction

Packets (datagrams) Stream of bytes of arbitrary length

Service Best-effort (same as IP) •Reliability •In-order delivery•Congestion control•Flow control

Applications Video, audio streaming File transfer, chat

Reliable Transport: General Concepts

Checksums (for error detection) Timers (for loss detection) Acknowledgments (feedback from receiver)

cumulative: “received everything up to X” selective: “received X”

Sequence numbers (detect duplicates, accounting) Sliding Windows

for efficiency: to allow multiple packets in flightYou should know: • what these concepts are• why they exist• how TCP uses them

Things to know about TCP

How TCP achieves reliability RTT estimation Connection establishment/teardown Flow Control Congestion Control

For each, know how the functionality is implemented and why it is needed

E.g., RTT Estimation

Why? TCP uses timeouts to retransmit packets But RTT may vary (significantly!) for different reasons and on

different timescales due to temporary congestion due to long-lived congestion due to a change in routing paths

An incorrect RTT estimate might introduce spurious retransmissions or overly long delays

RTT estimators should react to change but not too quickly proposed solutions use EWMA, incorporate deviations

E.g., Reliability

Why? IP is best-effort but many apps. need reliable delivery Having TCP take care of it simplifies application development

How checksums and timers (for error and loss detection) fast retransmit (for faster-than-timeout loss detection) cumulative ACKs (feedback from receiver -- what’s lost/what’s not) sliding windows (for efficiency) buffers at sender (to hold packets while waiting for ACKs) buffers at receiver (to reorder packets before delivery to app.)

E.g., Connection Establishment

Why? TCP is a stateful protocol (CWND, buffer space, ISN, etc.) Need to initialize connection state at both ends Exchange initial sequence numbers (why?)

How? Three-way handshake Host A sends a SYN to host B Host B returns a SYN acknowledgment (SYN ACK) Host A sends an ACK (+ data) to acknowledge the SYN ACK Hosts exchange proposed Initial Sequence Numbers at each step

E.g., Flow Control

Why? TCP offers a reliable in-order byte stream abstraction Hence, TCP at the receiver must buffer a packet until all packets

before it (in byte-order) have arrived and the receiving application has consumed available bytes

Hence receiver advances its window when the receiving application consumes data

But sender advances its window when new data ACK’d Hence, a risk the sender might overrun the receiver’s buffers

How? “Advertised Window” field in TCP header Receiver advertises the “right hand edge” of its window to sender Sender agrees not to exceed this amount

E.g., Congestion Control

Why? Because a sender shouldn’t overload the network itself But yet, should make efficient use of available network capacity While sharing available capacity fairly with other flows And adapting to changes in available capacity

How? Study the TCP state machine diagram from the text Also posted on piazza (thanks Andrew!)

TCP State Machine (partial)

slow start

congstn. avoid.

fast recovery

cwnd > ssthresh

timeout

dupACK=3

timeout

dupACK=3new ACK

dupACK

new ACK

timeout

new ACKdupACK

dupACK

Congestion Control: Details to know

Slow Start: Why: discover available bandwidth from a cold start How: exponential increase (every ACK, cwnd = cwnd + 1)

Congestion Avoidance: Why: adapt to variations in available bandwidth How: AIMD (every ACK, cwnd = cwnd + 1/cwnd) Why AIMD? For fairness

Fast Recovery: Keeps packets “in flight” after an isolated loss (why?) How: artificially inflate the CWND on every duplicate ACK (for a

while)

CC and Fairness: More things you should know

TCP throughput equation Implications

Max-Min Fairness Definition, simple example of how to calculate

Fair Queuing in routers Pros and cons (router complexity, use in congestion control)

Router assisted congestion control pros (better info.) and cons (more complexity in routers) e.g., explicit rate allocation (e.g., RCP): basic idea + pros/cons e.g., explicit congestion notification (e.g., ECN) : basic idea only

Final Questions?

Good luck!

Documents

Midterm Review EE 122, Fall 2013 Sylvia Ratnasamy ee122/ Material thanks to Ion Stoica, Scott Shenker, Jennifer Rexford,