Final Review

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

2. Logistics • Test is closed book, closed notes • Will start on time + “settling in” delay • Single two-sided “cheat sheet”, 8pt minimum • No calculators, electronic devices, etc. • Test does not require any complicated calculation

3. General Guidelines (1) • Exam format (tentative!) • Similar to the midterm but between 50-75% longer • (Q1) A set of multiple choice questions • ordered roughly from easiest to hardest • (Q2) Design scenarios • ordered roughly from easiest to hardest within each scenario • (Q3+) more traditional questions • ordered from easiest to hardest • Pace yourself accordingly.

4. General Guidelines (2) • Questions based on material covered in lecture & sections from the entire semester • Slightly more emphasis on post-midterm material • but you really can’t tackle post-midterm material without thoroughly understanding the pre-midterm material! • Several questions will require you to understand how the various pieces fit in a complete solution • e.g., TCP through a security lens • e.g., Components of delay through the lens of an HTTP caching system

5. General Guidelines (3) • 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 • make sure you understand pros/cons, when a solution is useful/breaks/etc.

6. General Guidelines (4) • 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..” • Consider the `complete picture’ • e.g., HTTP over TCP when my NAT fails… • If you’re unsure, put down your assumptions

7. Expect a question on … • IP routing (not on the detailed operation of DV ) • TCP congestion control • Reliable transport • “Sequence of messages when A talks to B” (lec 18) • HTTP performance • DNS • Wireless • Ethernet spanning tree and self learning • Datacenters

8. From here on… • Walk through what I expect you to know: key topics, important aspects of each • will enumerate, not explain, important points • Focus on post-midterm material • See midterm review for pre-midterm material • 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

9. Application Layer (lecture 14) • Domain Name System (DNS) • What’s behind (e.g.) xyz.cs.berkeley.edu • HTTP and the Web • What happens when you click on a link?

10. Internet Names & Addresses • Machine addresses: e.g., 169.229.131.109 • router-usable labels for machines • conforms to network structure (the “where”) • Machine names: e.g., instr.eecs.berkeley.edu • human-usable labels for machines • conforms to organizational structure (the “who”) • The Domain Name System (DNS) is how we map from one to the other

11. Key to DNS design: Hierarchy Three intertwined hierarchies • Hierarchical namespace • As opposed to original flat namespace • Hierarchically administered • As opposed to centralized • (Distributed) hierarchy of servers • As opposed to centralized storage

12. Things to know about DNS • Steps in resolving a DNS request • from the viewpoint of three different hierarchies • make sure you can walk through the sequence of messages exchanged between different servers • Role of caching • impact on performance, availability, consistency • repeat above walk-through with “cold” vs. “warm” cache • Pros/cons of the design

13. Web and HTTP • Web content is named using URLs • URLs use DNS hostnames • Thus, content names are tied to specific hosts • Protocol for exchanging information: HTTP • Synchronous request/reply protocol • Runs over TCP, Port 80 • Stateless • Client-server architecture • server is “always on” and “well known” • clients initiate contact to server

14. . . . Steps in HTTP Request/Response Client Server TCP Syn Establish connection TCP syn + ack Client request TCP ack + HTTP GET Request response Close connection

15. Things to know about HTTP • Steps in HTTP request/response • Broad form of request/response messages • only to the level of detail covered in lecture/section • not details of request/responseheaders • Performance • persistent vs. concurrent vs. pipelined connections • why they’re needed; what performance benefit they offer • when and how caching and replication help performance

16. Physical Layer (lecture 15) • Function: how to send a bit across a physical link • Protocol: coding scheme used to represent a bit, voltage levels, duration of a bit, etc. • Things to know: • concept of signal-to-noise ratio • difference between physical layer errors vs. higher layer packet drops (noise vs. buffer overflows) • relationship between channel capacity and signal-to-noise • Will not ask you numerical derivations/problems

17. DatalinkLayer (lectures 15- 18) • Function: send a data unit (packet) to a machine connected to the same physical media • e.g., Ethernet, wireless • Components: • Framing • Error detection and correction • Link layer addressing (e.g., Ethernet MAC addr.) • Medium access: arbitrate access to common physical media (e.g., CSMA/CD)

18. Media Access (lectures 15, 16, 17) • Given a shared broadcast channel • Must avoid having multiple nodes speaking at once • Otherwise, collisions lead to garbled data • Need algorithm that determines which node can transmit • Three classes of techniques • Channel partitioning: divide channel into pieces • Taking turns: algo that determines who gets to transmit • Random access: allow collisions, and then recover

19. Random Access Protocols • When node has packet to send • Transmit at full channel data rate • No a prioripartitioning among nodes • Two or more transmitting nodes collision • Data lost • Random access MAC protocol specifies: • How to detect or avoid collisions • How to recover from collisions • Examples • ALOHA, Slotted ALOHA, CSMA, CSMA/CD, CSMA/CA

20. Key Ideas of Random Access • Carrier sense • Before sending, check if someone else is already sending data • Collision detection • If someone else starts talking at the same time, stop • But make sure everyone knows there was a collision! • Collision avoidance • Explicit ACK from receiver signals (lack of) collision and impending communication • Randomness • If you can’t talk, wait for a random time before trying again

21. CSMA, CSMA/CD (lecture 16) • Things to know/understand • why CSMA alone doesnot eliminate all collisions (because of nonzero propagation delay) • collision detection is easy in wired (broadcast) LANs but difficult in wireless LANs (hence CSMA/CA) • why and how collision detection imposes a bound on max length of a wire and minimum length of frame

22. Wireless (lecture 17) Things you need to know: • Properties of the medium • broadcast  collisions happen • but broadcast has limited range no concept of a “global” collision  simultaneous transmissions are possible • can’t receive while transmitting  can’t detect collisions • complex signal deterioration(no well-defined radio range)  hard to predict who you’ll collide with (unless otherwise stated, we’ll ignore this one) • Fundamentals of communication • How to analyze a given media access protocol

23. Wireless (lecture 17) Things you need to know: • Properties of the medium • Canonical scenarios • hidden terminal (carrier sense fails to prevent collisions) • exposed terminal (carrier sense needlessly limits commn.)

24. Wireless (lecture 17) Things you need to know: • Properties of the medium • Canonical scenarios • Techniques for congestion avoidance • carrier sense • explicit request/response (RTS/CTS) • backoff

25. Wireless (lecture 17) Things you need to know: • Properties of the medium • Canonical scenarios • Techniques for congestion avoidance • How to analyze a given media access protocol that uses the above techniques • We’ll give you the protocol rules; you analyze how (and how well) data exchange proceeds • You don’t need to memorize protocol rules • e.g., Q3 on HW3

26. Wireless (lecture 17) Things you need to know: • Properties of the medium • Canonical scenarios • Techniques for congestion avoidance • How to analyze a given media access protocol that uses the above techniques Things we don’t expect you to know • mathematical understanding of wireless signals (free space loss, interference, attenuation, etc.) • details of specific protocols (e.g., 802.11)

27. Switched Ethernet (Lectures 18, 20) B A C switch D • Why? Concurrent communication • Host A can talk to C, while B talks to D • No collisions  no need for CSMA, CD • No constraints on link lengths, etc.

28. Switched Ethernet (Lectures 18, 20) • How? Two pieces • Build a spanning tree • Why? For loop-free flooding* • How? Shortest path tree rooted at node with the lowest ID (MAC address) • “Self Learning” switches • Why? So switches learn how to reach destination without flooding • How? If packet from A arrives on port X, switch learns to send packets to A via port X

29. Switched Ethernet (Lectures 18, 20) • What you should know about switched Ethernet • why spanning tree and self-learning are needed • how the spanning tree is constructed • role of soft state • how self-learning works • role of caching (see HW3 problem) • compare/contrast style of Ethernet vs. IP routing

30. Naming and Discovery (Lecture 18) • What you should know • Naming schemes at different layers (Ethernet, IP, DNS) • format; what they represent; what role they play • How we discover and translate between names • DNS, ARP, DHCP • role of broadcast, soft state and caching

31. Naming • Application layer: URLs and domain names • names “resources” -- hosts, content, program • (recall: mixes the what and where of an object) • Network layer: IP addresses • host’s network location • Link layer: MAC addresses • host identifier • Use all three for end-to-end communication!

32. Discovery • A host is “born” knowing only its MAC address • Must discover lots of information before it can communicate with a remote host B • what is my IP address? • what is B’s IP address? (remote) • what is B’s MAC address? (if B is local) • what is my first-hop router’s address? (if B is not local) • …

33. ARP and DHCP • Link layer discovery protocols • Serve two functions • Discovery of local end-hosts • for communication between hosts on the same LAN • Bootstrap communication with remote hosts • what’s my IP address? • who/where is my local DNS server? • who/where is my first hop router?

34. DHCP • “Dynamic Host Configuration Protocol” • A host uses DHCP to discover • its own IP address • its netmask • IP address(es) for its DNS name server(s) • IP address(es) for its first-hop “default” router(s)

35. DHCP: operation • One or more local DHCP servers maintain required information • Client broadcasts a DHCP discovery message • One or more DHCP servers responds with a DHCP “offer” message • Client broadcasts a DHCP request message • Selected DHCP server responds with an ACK

36. ARP: Address Resolution Protocol • Every host maintains an ARP table • list of (IP address MAC address) pairs • Consult the table when sending a packet • Map destination IP address to destination MAC address • Encapsulate the (IP) data packet with MAC header; transmit • But: what if IP address not in the table? • Sender broadcasts: “Who has IP address 1.2.3.156?” • Receiver responds: “MAC address 58-23-D7-FA-20-B0” • Sender caches result in its ARP table

37. Key Ideas in Both ARP and DHCP • Broadcasting: used for initial bootstrap • Caching: remember the past for a while • Store the information you learn to reduce overhead • Remember your own address & other host’s addresses • Key optimization for performance • Soft state: eventually forget the past • Associate a time-to-live field with the information • … and either refresh or discard the information • Key for robustness

38. Putting the pieces together (Lec 18) Walk through the steps required to download www.google.com/index.html from your laptop • Assume: `cold start’ -- nothing cached anywhere • Assume: yourDNS on a different subnet from yourDHCP • Ignore intra- and interdomain routing protocols yourDNS yourDHCP Understand this! Google’s datacenter You R UCB router Dorm

39. Security Guideline: • Test will be limited to straightforward questions based on the material covered in Vern’s lectures • will not be a major question • What this means: • understand the exact vulnerabilities and defenses Vern covered • won’t ask you to do a security analysis of protocols or scenariosnot covered in the security lectures • won’t ask you to uncover vulnerabilities not discussed in lecture • won’t ask you to design new forms of defenses

40. Security (Lecture 19) Things to know • Goals: confidentiality, integrity, availability • Common vulnerabilities/defenses by layer • physical layer: eavesdropping, disruption, spoofing • network layer: DoS, manipulate routing, spoofing • transport (TCP): injection (RST, data), spoofing, cheating • Security analysis of two protocols: DHCP and TCP

41. Security (Lecture 21) Things to know • Basic cryptographic concepts • symmetric/asymmetric keys • preventing eavesdropping through encryption • preventing alterations with message authentication codes • signatures and certificates to prevent impersonation

42. Security (Lecture 21) Things to know • Basic cryptographic concepts • Transport Layer Security and HTTPs • steps involved in establishing an HTTPs connection • what security properties this offers • issues/limitations of TLS/SSL

43. Datacenters What you should know • Nature of a datacenter environment • How and why DC networks are different (vs. WAN) • in terms of workload, goals, characteristics • How traditional solutions fare in this environment • e.g., IP, Ethernet, TCP, ARP, DHCP • Not details of how datacenter networks operate

44. Typical datacenter architecture (HW) • Servers organized in racks • Each rack has a `Top of Rack’ (ToR) switch • An `aggregation fabric’ interconnects ToR switches • Connected to the outside via `core’ switches • note: blurry line between aggregation and core • With network redundancy of ~2x for robustness

45. Typical datacenter traffic workload • “North-South traffic” • Traffic between outside world and the datacenter • “East-West traffic” • Traffic between machines in the datacenter • Commn. within “big data” computations (e.g. Map Reduce)

46. Goals for datacenter networks • The usual: scalability, efficiency, availability, low cost • Plus • Full bisection bandwidth • Very low latency communication • Predictable, deterministic performance • Isolation/differentiation between clients

47. Characteristics of a datacenter network • Huge scale • Limited geographic scope • Limited heterogeneity • regular topologies, link speeds, technologies, latencies, … • Single administrative domain • Control over one/both endpoints • Control over the placement of traffic sources/sinks • Control over topology (e.g., trees/fat-trees) New degrees of freedom for network design!

48. SDN • Was mostly for fun and early exposure • won’t test you on details of SDN (philosophy or mechanism) • How I expect you to use the lessons from Scott’s lecture • expect design questions that ask you to consider radicallydifferent network designs (e.g., centralized route calculations) • expect questions that ask you to consider new desig goals that we haven’t studied in depth (e.g., balancing traffic load, traffic isolation) • for all such questions: we’ll provide the design goals and options; your job will be to tell us whether/when/why our designis a good one

49. Good luck! Final questions?