Final review
Download
1 / 49

Final Review - PowerPoint PPT Presentation


  • 99 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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

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

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


Logistics
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


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.) xyz.cs.berkeley.edu

    • HTTP and the Web

      • What happens when you click on a link?


    Internet names addresses
    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


    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

    Client

    Server

    TCP Syn

    Establish

    connection

    TCP syn + ack

    Client

    request

    TCP ack + HTTP GET

    Request

    response

    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

      • ALOHA, Slotted ALOHA, CSMA, CSMA/CD, CSMA/CA


    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)

    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.


    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


    Naming
    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!


    Discovery
    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)


    Arp and dhcp
    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?


    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)


    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 1.2.3.156?”

      • 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 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


    Security
    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


    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


    Datacenters
    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


    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!


    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


    Good luck
    Good luck!

    Final questions?


    ad