final review
Skip this Video
Download Presentation
Final Review

Loading in 2 Seconds...

play fullscreen
1 / 49

Final Review - PowerPoint PPT Presentation

  • Uploaded on

Final Review. EE 122, Fall 2013 Sylvia Ratnasamy / 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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Final Review' - declan

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
final review

Final Review

EE 122, Fall 2013

Sylvia Ratnasamy

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

  • 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
general guidelines 1
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.
general guidelines 2
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
general guidelines 3
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.
general guidelines 4
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
expect a question on
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
from here on
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
application layer lecture 14
Application Layer (lecture 14)
  • Domain Name System (DNS)
    • What’s behind (e.g.)
  • HTTP and the Web
    • What happens when you click on a link?
internet names addresses
Internet Names & Addresses
  • Machine addresses: e.g.,
    • router-usable labels for machines
    • conforms to network structure (the “where”)
  • Machine names: e.g.,
    • 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
key to dns design hierarchy
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
things to know about dns
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
web and http
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
steps in http request response



Steps in HTTP Request/Response






TCP syn + ack






Close connection

things to know about http
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
physical layer lecture 15
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
datalink layer lectures 15 18
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)
media access lectures 15 16 17
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
random access protocols
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
key ideas of random access
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
csma csma cd lecture 16
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
wireless lecture 17
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
wireless lecture 171
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.)
wireless lecture 172
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
wireless lecture 173
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
wireless lecture 174
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)
switched ethernet lectures 18 20
Switched Ethernet (Lectures 18, 20)






  • 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.
switched ethernet lectures 18 201
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
switched ethernet lectures 18 202
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
naming and discovery lecture 18
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
  • 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!
  • 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)
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?
  • “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)
dhcp operation
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
arp address resolution protocol
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”
    • Receiver responds: “MAC address 58-23-D7-FA-20-B0”
    • Sender caches result in its ARP table
key ideas in both arp and dhcp
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
putting the pieces together lec 18
Putting the pieces together (Lec 18)

Walk through the steps required to download from your laptop

  • Assume: `cold start’ -- nothing cached anywhere
  • Assume: yourDNS on a different subnet from yourDHCP
  • Ignore intra- and interdomain routing protocols



Understand this!

Google’s datacenter








  • 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
security lecture 19
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
security lecture 21
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
security lecture 211
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

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
typical datacenter architecture hw
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
typical datacenter traffic workload
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)
goals for datacenter networks
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
characteristics of a datacenter network
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!

  • 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
good luck
Good luck!

Final questions?