1 / 49

Final Review

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. Logistics. Test is closed book, closed notes Will start on time + “settling in” delay

declan
Télécharger la présentation

Final Review

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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?

More Related