Midterm Review EE 122 Fall 2013 Sylvia Ratnasamy

  • Slides: 70
Download presentation
Midterm Review EE 122, Fall 2013 Sylvia Ratnasamy http: //inst. eecs. berkeley. edu/~ee 122/

Midterm Review EE 122, Fall 2013 Sylvia Ratnasamy http: //inst. eecs. berkeley. edu/~ee 122/ Material thanks to Ion Stoica, Scott Shenker, Jennifer Rexford, Nick Mc. Keown, and many other colleagues

Logistics l Test is in this classroom starting at 5: 40 exactly l Closed

Logistics l Test is in this classroom starting at 5: 40 exactly l Closed book, closed notes, etc. l Single two-sided “cheat sheet”, 8 pt minimum l No calculators, electronic devices, etc. l l Test does not require any complicated calculation I will have extra office hours tomorrow, Oct 22. l 11 am-1 pm in 413 Soda Hall

General Guidelines (1) l Test only assumes material covered in lecture & sections l

General Guidelines (1) l Test only assumes material covered in lecture & sections l l The test doesn’t require you to do complicated calculations or packet accounting l l Use this as a hint to whether you are on the right track You don’t need to memorize packet headers l l Text: only to clarify details and context for the above We’ll provide the IP header for your reference on the exam sheet You do need to understand how things work l not for the sake of knowing gory details but to understand pros/cons, when a solution is applicable/useful/useless, etc.

General Guidelines (2) l Be prepared to: l Weigh design options outside of the

General Guidelines (2) l Be prepared to: l Weigh design options outside of the context we studied them in e. g. , I had a TCP connection, then BGP went nuts…” l Contemplate new designs we haven’t talked about l l l 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…

General Guidelines (3) l Exam format (tentative!) Q 1) 20 multiple-choice questions l ordered

General Guidelines (3) l Exam format (tentative!) Q 1) 20 multiple-choice questions l ordered (roughly) from easiest to hardest Q 2) A set of “here’s a scenario, tell me if the following is true/false”-style questions l ordered (roughly) from easiest to hardest within each scenario Q 3, 4, 5, 6: more traditional questions l l l (we think) 3 < 4 < 5 < 6 (< implies easier than) sub-questions within each question ordered easiest to hardest Pace yourself accordingly.

This Review l Walk through what we expect you to know: key topics, important

This Review l Walk through what we expect you to know: key topics, important aspects of each l Just because I didn’t cover it in review doesn’t mean you don’t need to know it l l But if I covered it today, you should know it My plan: summarize, not explain l Stop me when you want to discuss something further!

Topics l l Architecture: concepts and principles (lecs. 2, 3) IP Routing (lecs. 4

Topics l l Architecture: concepts and principles (lecs. 2, 3) IP Routing (lecs. 4 -9) l l l Transport (lecs. 10 -13) l l Overall context Computing routes (DV, LS, path vector) IP addressing Inter-domain Router architecture Role of the transport layer UDP vs. TCP details: reliability, flow and congestion control Fairness and Router-assisted CC (lec. 13)

Architecture l Concepts you should be familiar with l l l packet delays packet

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

Properties of Links bandwidth delay x bandwidth Latency l Bandwidth (capacity): “width” of the

Properties of Links bandwidth delay x bandwidth Latency l Bandwidth (capacity): “width” of the link l l Latency (delay): “length” of the link l l number of bits sent (or received) per unit time (bits/sec or bps) propagation time for data to travel along the link (seconds) Bandwidth-Delay Product (BDP): “volume” of the link l amount of data that can be “in flight” at any time

Packet Delay Sending a 100 B packet from A to B? A 1 Mbps,

Packet Delay Sending a 100 B packet from A to B? A 1 Mbps, 1 ms B time=0 Time to transmit 800 bits=800 x 1/106 s 100 Byte packet The last bit reaches B at Time. Delay = (800 x 1/106)+1/103 s Packet Delay = Transmission Delay + Propagation = Delay (Packet Size ÷ Link Bandwidth) + Link Latency 1. 8 ms

Circuit switching Idea: source reserves network capacity along a path A B (1) Node

Circuit switching Idea: source reserves network capacity along a path A B (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

Circuit switching: pros and cons l Pros l l l guaranteed performance fast transfers

Circuit switching: pros and cons l Pros l l l guaranteed performance fast transfers (once circuit is established) Cons l l l wastes bandwidth if traffic is “bursty” connection setup adds delay recovery from failure is slow

Packet Switching l Data is sent as chunks of formatted bits (Packets) l Packets

Packet Switching l Data is sent as chunks of formatted bits (Packets) l Packets consist of a “header” and “payload” l Switches “forward” packets based on their headers l Each packet travels independently l No link resources are reserved in advance. Instead packet switching leverages statistical multiplexing

Packet switching: pros and cons l Cons l l no guaranteed performance header overhead

Packet switching: pros and cons l Cons l l no guaranteed performance header overhead per packet queues and queuing delays Pros l l l efficient use of bandwidth (stat. muxing) no overhead due to connection setup resilient -- can `route around trouble’

Statistical Multiplexing: Three Flows with Bursty Traffic Data Rate 1 Time Data Rate 2

Statistical Multiplexing: Three Flows with Bursty Traffic Data Rate 1 Time Data Rate 2 Capacity Time Data Rate 3 Time

When Each Flow Gets 1/3 rd of Capacity Data Rate 1 Frequent Overloading Time

When Each Flow Gets 1/3 rd of Capacity Data Rate 1 Frequent Overloading Time Data Rate 2 Time Data Rate 3 Time

When Flows Share Total Capacity Time No Overloading Time

When Flows Share Total Capacity Time No Overloading Time

Statistical Multiplexing l Allows efficient use of network bandwidth l Relies on the assumption

Statistical Multiplexing l Allows efficient use of network bandwidth l Relies on the assumption that not all flows burst at the same time l l similar assumption and failure case as insurance Queues absorb transient traffic bursts but also introduce queuing delay l We will not be asking you to do detailed calculations of queuing delay on the test

Layering l Layering is a particular form of modularization l System is broken into

Layering l Layering is a particular form of modularization l System is broken into a vertical hierarchy of logically distinct entities (layers) l Service provided by one layer is based solely on the service provided by layer below l Rigid structure: easy reuse, performance suffers

In the context of the Internet Applications …built on… This is not a typo

In the context of the Internet Applications …built on… This is not a typo Reliable (or unreliable) transport …built on… Best-effort global packet delivery …built on… Best-effort local packet delivery …built on… Physical transfer of bits L 7 Application L 4 Transport L 3 Network L 2 Data link L 1 Physical

Protocols and Layers L 7 Application L 7 L 4 Transport L 4 L

Protocols and Layers L 7 Application L 7 L 4 Transport L 4 L 3 Network L 3 L 2 Data link L 2 L 1 Physical L 1 Communication between peer layers on different systems is defined by protocols

Layer Encapsulation User A User B Appl: Get index. html Trans: Connection ID Net:

Layer Encapsulation User A User B Appl: Get index. html Trans: Connection ID Net: Source/Dest Link: Src/Dest

What gets implemented where? l l Lower three layers implemented everywhere Top two layers

What gets implemented where? l l Lower three layers implemented everywhere Top two layers implemented only at hosts Application Transport Network Datalink Physical Host A Router Host B

Protocols at different layers L 7 Application L 4 Transport L 3 Network L

Protocols at different layers L 7 Application L 4 Transport L 3 Network L 2 Data link L 1 Physical SMTP HTTP DNS TCP NTP UDP IP Ethernet optical copper FDDI radio PPP PSTN There is just one network-layer protocol, IP The “narrow waist” of the Internet hourglass

Implications of Hourglass Benefits of a single network-layer protocol (IP) l Allows arbitrary networks

Implications of Hourglass Benefits of a single network-layer protocol (IP) l Allows arbitrary networks to interoperate l l Any network that supports IP can exchange packets Decouples applications from low-level networking technologies l Applications function on all networks

Benefits of Layering l l l Modularity allows abstraction and reuse Narrow waist allows

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

Drawbacks of Layering l Rigid structure may hurt performance l l Duplication of functionality

Drawbacks of Layering l Rigid structure may hurt performance l l Duplication of functionality Information hiding (Secondary) Headers start to get really big Layer violations l l for performance: e. g. , TCP-over-wireless for security: e. g. , firewalls

Summary of End-to-End Principle l l Design principle guiding the placement of functionality in

Summary of End-to-End Principle l l 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 l l Reliability, security, etc. Supporting these properties in the network may be unwise l l l Doesn’t reduce host implementation complexity Does increase network complexity Might impose overhead on apps that don’t need the functionality l However, implementing in the network can improve performance in some cases l Key argument for why IP offers only “best-effort” delivery l Reliability implemented at the endhost (TCP)

Topics l l Architecture: concepts and principles (lecs. 2, 3) IP Routing (lecs. 4

Topics l l Architecture: concepts and principles (lecs. 2, 3) IP Routing (lecs. 4 -9) l l l Transport (lecs. 10 -13) l l Overall context Computing routes (DV, LS, path vector) IP addressing Inter-domain Router architecture Role of the transport layer UDP vs. TCP details: reliability, flow and congestion control Fairness and Router-assisted CC (lec. 13)

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

“Autonomous System (AS)” or “Domain” Region of a network under a single administrative entity Context and Terminology “End hosts” “Clients”, “Users” “End points” “Border Routers” “Route” or “Path” “Interior Routers”

Internet Routing l Internet Routing works at two levels l Each AS runs an

Internet Routing l Internet Routing works at two levels l Each AS runs an intra-domain routing protocol that establishes routes within its domain l l l 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 l Path Vector, e. g. , Border Gateway Protocol (BGP)

Link State Routing l l l Each node maintains its local “link state” (LS)

Link State Routing l l l 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 l l l every node maintains complete topology link updates flooded everywhere may have transient loops while nodes have inconsistent topology information

Distance Vector Routing l Each router knows the links to its neighbors l Each

Distance Vector Routing l Each router knows the links to its neighbors l Each router has provisional “least cost” estimate to every other router -- its distance vector (DV) l E. g. : Router A: “A can get to B with cost 11” l Routers exchange this DV with their neighbors l Routers look over the set of options offered by their neighbors and select the best one l Iterative process converges to set of shortest paths

DV: You should understand l How DV works l l The counting to infinity

DV: You should understand l How DV works l l The counting to infinity problem l l what’s in a DV; how nodes process and update DVs why it occurs Poison Reverse l when it does/doesn’t fix counting-to-infinity

60 4 A DV: Link Cost Changes Stable state to B C Node B

60 4 A DV: Link Cost Changes Stable state to B C Node B Node C 50 C A sends its DV to B, C B sends its DV to A, C C sends its DV to A, B B B C B 4 51 B 60 51 5 This 50 1 A-B changed via Node A B C C B 60 51 is Cthe 61“Counting to Infinity” 61 50 CProblem 50 C B 60 51 C 61 50 A C A C A C A 4 6 A 60 8 C 9 1 C 65 1 C 110 1 A B A B A B A 50 5 A 50 7 B 54 1 B 101 1 Link cost changes here “bad news travels slowly” (not yet converged)

DV: Poisoned Reverse 60 4 A If B routes through C to get to

DV: Poisoned Reverse 60 4 A If B routes through C to get to A: B tells C its (B’s) distance to A is infinite Stable state to 50 C A sends its DV to B, C B sends its DV to A, C C sends its DV to A, B B C C B C B B 4 51 B 60 51 C 5 50 C 61 50 A C ∞ 6 A Node B A C A C A 60 C ∞ 6 A 60 51 1 ∞ C 65 1 C 110 1 A B A 50 5 B 54 1 A C Node C 1 A-B changed via Node A B 4 ∞ 9 Link cost changes here A A 50 ∞ B 101 B A 5 A 50 61 A 50 B ∞ 61 1 ∞ B 101 1 Converges after C receives another update from B

“Count to Infinity”: root cause A B C • C’s path to A goes

“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

“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 l l Architecture: concepts and principles (lecs. 2, 3) IP Routing (lecs. 4

Topics l l Architecture: concepts and principles (lecs. 2, 3) IP Routing (lecs. 4 -9) l l l Transport (lecs. 10 -13) l l Overall context Computing routes (DV, LS, path vector) IP addressing Inter-domain Router architecture Role of the transport layer UDP vs. TCP details: reliability, flow and congestion control Fairness and Router-assisted CC (lec. 13)

Addressing Goal: Scalable Routing l State: Small forwarding tables at routers l l Much

Addressing Goal: Scalable Routing l State: Small forwarding tables at routers l l Much less than the number of hosts Churn: Limited rate of change in routing tables l Traffic, inconsistencies, complexity Ability to aggregate addresses is crucial for both (one entry to summarize many addresses)

Hierarchy in IP Addressing l l 32 bits are partitioned into a prefix and

Hierarchy in IP Addressing l l 32 bits are partitioned into a prefix and suffix components Prefix is the network component; suffix is host component 12 34 158 5 00001100 0010 10011110 00000101 Network (23 bits) l l Host (9 bits) Interdomain routing operates on the network prefix “slash” notation: 12. 34. 158. 0/23 network with a 23 bit prefix and 29 host addresses

IP addressing scalable routing? l Hierarchical address allocation helps routing scalability if allocation matches

IP addressing scalable routing? l Hierarchical address allocation helps routing scalability if allocation matches topological hierarchy l Problem: may not be able to aggregate addresses for “multi-homed” networks l l similar problem with mobile hosts Two competing forces in scalable routing l l aggregation reduces number of routing entries multi-homing increases number of entries

BGP and Inter-Domain Routing l l l Destinations are IP prefixes (12. 0. 0.

BGP and Inter-Domain Routing l l l Destinations are IP prefixes (12. 0. 0. 0/8) Nodes are Autonomous Systems (ASes) Links represent both physical connections and business relationships l l customer-provider or peer-to-peer BGP is the protocol for inter-domain routing l l path-vector protocol policy-driven route selection

BGP extends DV l With some important differences l l l routes selected based

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

Topology and policy is shaped by the business relationships between ASes l Three basic

Topology and policy is shaped by the business relationships between ASes l Three basic kinds of relationships between ASes l l 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 l l Customer pays provider Peers don’t pay each other l Exchange roughly equal traffic

Policy imposed in how routes are selected and exported Route export Route selection Customer

Policy imposed in how routes are selected and exported Route export Route selection Customer 1 Can reach 128. 3/16 blah 10 Competitor l l 5 Selection: Which path to use? l controls whether/how traffic leaves the network Export: Which path to advertise? l controls whether/how traffic enters the network

Typical Export Policy Destination prefix advertised by… Export route to… Customer Everyone (providers, peers,

Typical Export Policy Destination prefix advertised by… Export route to… Customer Everyone (providers, peers, other customers) Peer Customers Provider Customers We’ll refer to these as the “Gao-Rexford” rules You must know this!-- practice!) (capture common -- but not required!

Typical Selection Policy l In decreasing order of priority l l l make/save money

Typical Selection Policy l In decreasing order of priority l l l 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 l 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 Pr Q A E traffic allowed l l Peer B

Policy Dictates Route Selection Pr Q A E traffic allowed l l Peer B D Cu C F traffic not allowed ASes provide “transit” between their customers Peers do not provide transit between other peers Peer

20 Bytes of Standard Header, then Options 4 -bit 8 -bit 4 -bit Version

20 Bytes of Standard Header, then Options 4 -bit 8 -bit 4 -bit Version Header Type of Service Length (TOS) 3 -bit Flags 16 -bit Identification 8 -bit Time to Live (TTL) 16 -bit Total Length (Bytes) 8 -bit Protocol 13 -bit Fragment Offset 16 -bit Header Checksum 32 -bit Source IP Address 32 -bit Destination IP Address Options (if any) Payload

Comparison of Design Philosophy IPv 6 IPv 4 Version IHL Type of Service Identification

Comparison of Design Philosophy IPv 6 IPv 4 Version IHL Type of Service Identification Time to Live Protocol Total Length Flags Fragment Offset Version Traffic Class Payload Length Flow Label Next Header Hop Limit Header Checksum Source Address Destination Address Options Padding To Destination and Back (expanded) Deal with Problems (greatly reduced) Read Correctly (reduced) Special Handling (similar) Destination Address

Topics l l Architecture: concepts and principles (lecs. 2, 3) IP Routing (lecs. 4

Topics l l Architecture: concepts and principles (lecs. 2, 3) IP Routing (lecs. 4 -9) l l l Transport (lecs. 10 -13) l l Overall context Computing routes (DV, LS, path vector) IP addressing Inter-domain Router architecture Role of the transport layer UDP vs. TCP details: reliability, flow and congestion control Fairness and Router-assisted CC (lec. 13)

What’s inside a router? Input and Output for the same port are on one

What’s inside a router? Input and Output for the same port are on one physical linecard Processes packets on their way in Route/Control Processor Processes packets Linecards (output) before they leave Linecards (input) 1 1 2 2 Interconnect (Switching) Fabric N Transfers packets from input to output ports N

What’s inside a router? Route/Control Processor (1) Implement IGP and BGP forwarding protocols; (2)

What’s inside a router? Route/Control Processor (1) Implement IGP and BGP forwarding protocols; (2) Push compute tables torouting the linetables cards Linecards (input) Linecards (output) 1 1 2 2 Interconnect (Switching) Fabric N N

What’s inside a router? Constitutes the control plane Route/Control Processor Constitutes the data plane

What’s inside a router? Constitutes the control plane Route/Control Processor Constitutes the data plane Linecards (input) Linecards (output) 1 1 2 2 Interconnect Fabric N N

Challenges in Router Design l @ Line cards: destination lookups at high speed l

Challenges in Router Design l @ Line cards: destination lookups at high speed l e. g. , find the longest prefix match (LPM) in the table that matches the packet destination address l @ Switch fabric: head-of-line blocking, scheduling the switch fabric at high speed l @ Route processor: complexity/correctness more a problem than performance l You should understand why these challenges arise but we don’t expect you to know how to fix them l e. g. , specifics of scheduling algorithms or LPM lookups

Topics l l Architecture: concepts and principles (lecs. 2, 3) IP Routing (lecs. 4

Topics l l Architecture: concepts and principles (lecs. 2, 3) IP Routing (lecs. 4 -9) l l l Transport (lecs. 10 -13) l l Overall context Computing routes (DV, LS, path vector) IP addressing Inter-domain Router architecture Role of the transport layer UDP vs. TCP details: reliability, flow and congestion control Fairness and Router-assisted CC (lec. 13)

Role of the Transport Layer l Communication between application processes l l l Mux

Role of the Transport Layer l Communication between application processes l l l Mux and demux from/to application processes Implemented using ports [Optionally] Provide common end-to-end services for app layer l l Reliable, in-order data delivery Well-paced data delivery

UDP vs. TCP l Both UDP and TCP provide multiplexing/demultiplexing via ports UDP TCP

UDP vs. TCP l 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 Applications Video, audio streaming delivery • Congestion control • Flow control File transfer, chat 59

Reliable Transport: General Concepts l l l Checksums (for error detection) Timers (for loss

Reliable Transport: General Concepts l l l Checksums (for error detection) Timers (for loss detection) Acknowledgments (feedback from receiver) l l cumulative: “received everything up to X” selective: “received X” Sequence numbers (detect duplicates, accounting) Sliding Windows You should know: l for efficiency: to allow multiple packets in flight are • what these concepts • why they exist • how TCP uses them

Things to know about TCP l l l How TCP achieves reliability RTT estimation

Things to know about TCP l l l 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 l l Why? TCP uses timeouts to retransmit packets

E. g. , RTT Estimation l l Why? TCP uses timeouts to retransmit packets But RTT may vary (significantly!) for different reasons and on different timescales l l l 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 l proposed solutions use EWMA, incorporate deviations

E. g. , Reliability l Why? IP is best-effort but many apps. need reliable

E. g. , Reliability l Why? IP is best-effort but many apps. need reliable delivery l l Having TCP take care of it simplifies application development How l l l 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 l Why? l l TCP is a stateful protocol

E. g. , Connection Establishment l Why? l l 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 l l 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 l Why? l l l TCP offers a reliable

E. g. , Flow Control l Why? l l l 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 l l Receiver advertises the “right hand edge” of its window to sender Sender agrees not to exceed this amount

E. g. , Congestion Control l Why? l l l Because a sender shouldn’t

E. g. , Congestion Control l Why? l l l 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? l l Study the TCP state machine diagram from the text Also posted on piazza (thanks Andrew!)

TCP State Machine (partial) timeout dup. ACK slow start cwnd > ssthresh timeout new

TCP State Machine (partial) timeout dup. ACK slow start cwnd > ssthresh timeout new ACK congstn. avoid. dup. ACK new ACK timeout new ACK dup. ACK=3 dup. ACK fast recovery

Congestion Control: Details to know l Slow Start: l l l Congestion Avoidance: l

Congestion Control: Details to know l Slow Start: l l l Congestion Avoidance: l l Why: discover available bandwidth from a cold start How: exponential increase (every ACK, cwnd = cwnd + 1) Why: adapt to variations in available bandwidth How: AIMD (every ACK, cwnd = cwnd + 1/cwnd) Why AIMD? For fairness Fast Recovery: l l 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 l TCP throughput equation l l

CC and Fairness: More things you should know l TCP throughput equation l l Max-Min Fairness l l Definition, simple example of how to calculate Fair Queuing in routers l l Implications Pros and cons (router complexity, use in congestion control) Router assisted congestion control l 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? l Good luck!

Final Questions? l Good luck!