Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
75 Cards in this Set
- Front
- Back
More sophisticated transport protocol then UDP but packet end to end framework is still the same |
TCP |
|
TCP properties |
1) process to process communication 2) processes are identified using parts 3) congestion control 4) network reliability 5) flow control 6) byte stream oriented -> segmentation into packets 7) connection oriented 8) bidirectional 9) connection between 2 hosts only |
|
UDP properties |
1) process to process communication2) processes are identified using parts3) no congestion control4) "best effort" service, not reliable5) no flow control6) message oriented -> no segmentation7) connectionless8) unicast, broadcast |
|
Goal: avoid overwhelming the network with traffic |
Congestion control |
|
Goal: retransmit in case of packet loss on timeout |
Network reliability |
|
Goal: avoid overwhelming the receiving host |
Flow control |
|
__ control & __ control work together complementary |
Flow & congestion |
|
TCP will segment application's data into IP packets that fit into the link MTU |
Byte-stream oriented |
|
Sharing initial data in order to carry out different services; connection setup exchanges initial state between 2 hosts (ex: initial available buffer space, initial sequence numbers, addressing info (IP address and port)) |
Connection oriented |
|
Why use UDP? |
1) Applications that require broadcast (ex: DHCP discover request) 2) service discovery protocols (ex: printer discovery) 3) Applications that need to send a single packet (or small # of packets) may use UDP to avoid overhead of connection setup (ex: DNS & DHCP) 4) applications that value timeliness over reliability (ex: voice, interactive exchange (phone call), games) 5) some services offered by TCP applications don't need, so they won't use TCP |
|
Addresses issues related to IP packets since IP is a "best effort" service |
Network reliability |
|
What are the 4 issues with IP packets that Network reliability addresses? |
1) IP packet dropped due to buffer overflow due to congestion 2) IP packet can be corrupted: link interface of faulty memory 3) IP packet can be delayed 4) IP packets can arrive at destination out of order |
|
Ack sequence # matches the packet being acknowledged |
Selective acks |
|
Ack with sequence # N means all packets up to sequence # N have arrived |
Cumulative acks |
|
Case 1: Normal operation mechanism |
Mechanism for response (acknowledge). Explicit: acknowledgement message, implicit: application response is the acknowledge |
|
Case 2: packet doesn't get to receiver (lost packet) mechanism |
Use timer; retransmit on timeout; base timeout on RTT weighted moving average |
|
Case 3: packet sent to receiver, no ack received (lost ack) mechanism |
Unique message id per packet; see duplicate packet, ignore packet and send ack |
|
Case 4: premature timeout |
Ack will have message is of corresponding packet; see duplicate packet, ignore packet and send ack; sender will receive duplicate ack that contains same id as packet message id |
|
Describe TCP implementation of network reliability |
Supports pipelining; sequence #s are in terms of bytes, not packets |
|
The byte stream # of the first byte in the packet |
Sequence # |
|
Byte stream # of the packet expected next cumulative acks |
Ack # |
|
TCP connection set up (3 way handshake) |
Client: SYN (seq#: 0, len: 0) Server: SYNACK (seq#: 0, ack#: 1, len: 0) Client: ACK (seq#: 1, ack#: 1, len: 0) |
|
Seq # = ? Only changed when sending data |
Seq # + len |
|
TCP echo client and server sending 20000 bytes each (link MTU = 16384 bytes, IP = 32 bytes). Assume window size>=2 (skip 3 way handshake) |
Client: DATA (seq#: 1, ack#: 1, len: 16332) Client: DATA (seq#: 16333, ack#: 1, len: 3668)Server: ACK (seq#: 1, ack#: 16333, len: 0)Server: ACK (seq#: 1, ack#: 20001, len: 0) Server: DATA (seq#: 1, ack#: 20001, len: 16332)Server: DATA (seq#: 16333, ack#: 20001, len: 3668) Client: ACK (seq#: 20001, ack#: 20001, len: 0) <--- delayed ack |
|
When host sees that a packet uses up all of its bytes, it will wait before acknowledging since it's likely there's another packet coming |
Delayed ack |
|
What is the web? |
Interconnected objects residing on hosts distributed across the internet |
|
Examples of web objects |
Web page (text/html) - audio Images, video |
|
How are web objects referenced? |
Using URLs |
|
Url format: Http(s)://www.example.org:12000/home/intro.html |
Http(s):// - schema www.example.org - DNS hostname of host running web server 12000 - port server is running on Home/intro.html - path to object Entire thing: absolute URL Path to object: relative URL |
|
Operation: fetch contents of object HTTP Message: |
GET |
|
Operation: sending data, such as filling in a form HTTP Message: |
POST |
|
Operation: update the object HTTP Message: |
PUT |
|
Operation: delete web object HTTP Message: |
DELETE |
|
Properties of HTTP message |
Text based, message is an encoded string of the HTTP message format |
|
Example of HTTP GET request |
GET home/intro.html HTTP1.1\r\n (Called the request line: Operation, relative URL, version, indicate end of line) Host: www.example.org:12000\r\n (One or more header lines) \r\n (Designate end of header) |
|
Example of HTTP GET response |
HTTP1.1 200 OK\r\n (Status line: version, return code) Date: Thu, 7 Mar 2018 10:15:20 GMT\r\n (Current time when request was processed) Last-Modified: Wed, 6 Mar 2018 15:16:18 GMT\r\n (Time when object was last updated) Content-Length: (length of web object in response)\r\n Content-Type: text/html; charset = UTF-8\r\n \r\n <contents of web object> |
|
How do you deal with out of date data in web caches? |
Supports a mechanism similar to DNS TTL value (absolute expiration time, relative time) |
|
Conditional GET |
Request sent to origin server -> only return the object contents if the object has been modified since the last time object was fetched |
|
How does Conditional GET differ from a regular GET request? |
Same first two lines If-Modified-Since: Wed, 6 Mar 2018 15:16:18 GMT\r\n \r\n |
|
Example of a not modified response |
HTTP1.1 304 Not Modified\r\n Date: <current time>\r\n \r\n |
|
Difference between HTTP 1.0 and HTTP 1.1 |
HTTP 1.0: non-persistent, limit: one object per connection one round trip time overhead per object HTTP 1.1: persistent, multiple objects per connection one round trip time overhead for all objects |
|
HTTP object not found response |
HTTP1.1 404 Not Found\r\n Date: <current date>\r\n \r\n |
|
Send window = min( , ) |
Min(receive window, congestion window) |
|
Prevent sender from over-running the receiving host (overflowing the receiver's buffer) |
Flow control |
|
Limit sender's transmission rate to the available bandwidth (cwnd) |
Congestion control |
|
Number of packets (bytes) that can be transmitted but not acknowledged ("in-flight") |
Send window |
|
Available buffer space to receive packets in receiver |
Receive window |
|
Which two windows are always changing size? |
Send and receive |
|
What is the goal of TCP congestion control? |
Do not overrun the network |
|
How does TCP congestion control work? |
No explicit indication; sender determines there's an issue through loss; starts off by sending at very slow rate with a small window size; increases sending rate as long as there is no loss; if there's loss, it'll slow down |
|
What are the three states of TCP congestion control? |
1) slow start 2) congestion avoidance 3) fast recovery |
|
Describe TCP congestion control: slow start |
State entered on connection start and when it times out Initial state: cwnd = 1 packet Each RTT, cwnd doubles |
|
Describe TCP congestion control: congestion avoidance |
New variable called ssthresh Ssthresh keeps track of the cwnd size when loss last occurred Ssthresh = cwnd / 2 when loss occurs Congestion avoidance entered when cwnd >= ssthresh Increase sending rate linearly, each RTT -> cwnd = cwnd + 1 |
|
Describe TCP congestion control: fast retransmit |
Only lose a single packet, congestion can't be too bad, so retransmit earlier than normal |
|
Describe TCP congestion control: fast recovery |
Fast recovery entered on a triple duplicate ack Halves the transmission rate State retransmits the lost packet (fast retransmit) and waits for the ackHalves the transmission rate On entry to fast recovery, ssthresh = cwnd / 2On exit from fast recovery, cwnd = ssthresh On entry to fast recovery, ssthresh = cwnd / 2 On exit from fast recovery, cwnd = ssthresh |
|
The data plane is in charge of |
Forwarding |
|
The control plane is in charge of |
Routing |
|
Which routing processes can routing processes talk to? |
Only those directly connected to each other |
|
What is the call of routing processes? |
Find the least cost path, which may be the shortest, quickest, or least congested |
|
Describe the link state |
Routers know global topology; Shortest path algorithm applied (dijkstra algorithm) |
|
Describe distance vector |
Routers do not have global topology; Communicates distance vectors to neighbors; Distributed computation |
|
Routing processes can only talk to routing processes __ __ to each other |
Directly connected |
|
What are the goals of routing? |
Least cost path (shortest, quickest, least congested) |
|
Two types of routing processes |
Link state and Distance vector |
|
Describe the Link state routing process |
Routers know global topology; shortest path algorithm applied (Dijkstra's algorithm) |
|
Describe the Distance vector routing process |
Routers do not have global topology; communicates distances vectors to neighbors; distributed computation; bellman Ford equation |
|
Describe the host sending rules for Ethernet switching |
Host determines whether the destination IP address is on the same subnet or not; if it is, the host can communicate with the destination host directly (without going through a router); if not, host sends packet via router |
|
Forward packet based on destination IP address; using a forwarding table, populated using a routing protocol; network layer or L3 device |
Router |
|
Forwards (bridges, switches) packets based on destination MAC addresses; uses the MAC/switch table to forward packets out the right interface (MAC, outgoing interface); switch/MAC table is populated by snooping the MAC address in LL header of packets; LL or L2 device |
Ethernet switch |
|
LL or L2 device; supports Wi-Fi & converts between Wi-Fi and Ethernet; wifi support several modes; infrastructure mode is used when connecting to the internet; bridging using destination MAC address |
Wireless Access Point (AP) |
|
How is the MAC table populated for an incoming packet (when a packet arrives on a switch interface)? |
Record the source MAC address and the incoming interface in the MAC table; update the aging timer |
|
How is the MAC table populated for an outgoing packet (which interface to send packet out of)? |
If destination MAC address is in the MAC table, send packet out of the corresponding interface; if not, send packet out all interfaces except the incoming one |
|
What is LAN? |
Local area network (link) - ethernet, Wi-Fi |
|
What is Virtual LAN? |
Software configured LAN; enable a single physical switch to operate as multiple logical switches |
|
Packets carry a VLAN id or VLAN tag in LL header |
Trunk part |