SC250 Computer Networking I Review Exercises Prof. Matthias Grossglauser School of Computer and Communication Sciences EPFL http://lcawww.epfl.ch 1
Reliable transport: rdt3.0 ACK packets receiver->sender do not have sequence numbers (as opposed to normal packets). Question: Why is it NOT necessary for the ACK packets to have their own sequence numbers? Sender rdt3.0 ignores (=no action) packets that are corrupted or acknowledge wrong sequence number. Question: If you modified rdt3.0 to retransmit the current data packet, would the protocol still work? 2
Reliable transport: rdt3.0 ACK packets receiver->sender do not have sequence numbers (as opposed to normal packets). Answer: Why is it NOT necessary for the ACK packets to have sequence numbers? We had to add sequence numbers to data packets to avoid duplication, i.e., that a single packet at the sender results in multiple (identical) packets at the receiver; this requirement does not exist for ACK packets per se, as they are omnipotent, i.e., whether we receive one or several ACKs for the same packet does not matter to the application 3
Reliable transport: rdt3.0 Sender rdt3.0 ignores (=no action) packets that are corrupted or acknowledge wrong sequence number. If you modified rdt3.0 to retransmit the current data packet, would the protocol still work? Answer: Yes, the protocol would still work. A retransmission happens anyway for lost packets, and the receiver does not know the difference. 4
Reliable transport: pipelining Previous example: rdt3.0 1 Gbps link, 15 ms end-to-end prop. delay, 1KB packet Question: How large should the window be to allow for 90% link utilization? 5
Reliable transport: pipelining Previous example: rdt3.0 1 Gbps link, 15 ms end-to-end prop. delay, 1KB packet Question: How large should the window be to allow for 90% link utilization? Answer: nl /R =0.9 n=3377 RTTL/R 6
Pipelining: Go-Back-N Let's explore sender-receiver interaction in GBN in more detail. Example: Suppose at some time t, the receiver is expecting the next inorder packet with sequence number k Assume that the network does not reorder packets Window size N, sequence number range >> N (so no problem with wrap-around) Questions: What are the possible sets of sequence numbers inside the sender's window at time t? What are all possible values of ACK field in all possible messages currently propagating back to the sender at time t? 7
Pipelining: Go-Back-N Let's explore sender-receiver interaction in GBN in more detail. Answers: What are the possible sets of sequence numbers inside the sender's window at time t? Receiver has received and ACKed everything up to k-1. Distinguish two cases: 1) if sender has received all these ACKs, then sender window is [k, k+n-1] 2) if sender has received none of these ACKs, then sender window is [k-n, k-1] Therefore, sender window is of size N, begins anywhere from k-n to k 8
Pipelining: size of sequence number space Go-Back-N or Selective-Repeat protocols Suppose the sequence number space is of size S (i.e., S distinct sequence numbers, everything mod S) Question: What is the largest allowable sender window size N to avoid confusion? 9
Pipelining: size of sequence number space Go-Back-N or Selective-Repeat protocols Question: What is the largest allowable sender window size N? Answer: Problem is that highest possible seq_num in receiver window falls into sender window Receiver is waiting for seq_num k; its window is [k,k+n-1] Assume sender has not received any of the ACKs for [k- N...k-1]; then sender window is [k-n,k-1] Must avoid that top of receiver window touches bottom of sender window (mod S); therefore, seq_num space should contain at least 2N numbers Intuition: think of a ring 10
TCP Trace: complete! fidji -> delos ETHER Type=0800 (IP), size = 60 bytes fidji -> delos IP D=129.88.38.94 S=129.88.38.84 LEN=44, ID=40098 fidji -> delos TCP D=80 S=36432 Syn Seq=743 Len=0 W=8760 O=<mss 1460> fidji -> delos HTTP C port=36432 delos -> fidji ETHER Type=0800 (IP), size = 60 bytes delos -> fidji IP D=[???????] S=[???????] LEN=44, ID=12700 delos -> fidji TCP D=[???????] S=[???????] Syn Ack=[???????] Seq=138 Len=0 W=32120 O=<mss 1460> delos -> fidji HTTP R port=36432 fidji -> delos ETHER Type=0800 (IP), size = 60 bytes fidji -> delos IP D=129.88.38.94 S=129.88.38.84 LEN=40, ID=40099 fidji -> delos TCP D=80 S=36432 Ack=[???????] Seq=[???????] Len=0 W=8760 fidji -> delos HTTP C port=3643 fidji -> delos ETHER Type=0800 (IP), size = 324 bytes fidji -> delos IP D=129.88.38.94 S=129.88.38.84 LEN=310, ID=40100 fidji -> delos TCP D=80 S=36432 Ack=[???????] Seq=[???????] Len=[???????] W=8760 fidji -> delos HTTP GET / HTTP/1.0 delos -> fidji ETHER Type=0800 (IP), size = 60 bytes delos -> fidji IP D=[???????] S=[???????] LEN=40, ID=12701 delos -> fidji TCP D=[???????] S=[???????] Ack=[???????] Seq=[???????] Len=0 W=31850 delos -> fidji HTTP R port=36432 11
TCP Trace fidji -> delos ETHER Type=0800 (IP), size = 60 bytes fidji -> delos IP D=129.88.38.94 S=129.88.38.84 LEN=44, ID=40098 fidji -> delos TCP D=80 S=36432 Syn Seq=743 Len=0 W=8760 O=<mss 1460> fidji -> delos HTTP C port=36432 delos -> fidji ETHER Type=0800 (IP), size = 60 bytes delos -> fidji IP D=[129.88.38.84] S=[129.88.38.94] LEN=44, ID=12700 delos -> fidji TCP D=[36432] S=[80] Syn Ack=[744] Seq=138 Len=0 W=32120 O=<mss 1460> delos -> fidji HTTP R port=36432 fidji -> delos ETHER Type=0800 (IP), size = 60 bytes fidji -> delos IP D=129.88.38.94 S=129.88.38.84 LEN=40, ID=40099 fidji -> delos TCP D=80 S=36432 Ack=[139] Seq=[744] Len=0 W=8760 fidji -> delos HTTP C port=3643 fidji -> delos ETHER Type=0800 (IP), size = 324 bytes fidji -> delos IP D=129.88.38.94 S=129.88.38.84 LEN=310, ID=40100 fidji -> delos TCP D=80 S=36432 Ack=[139] Seq=[744] Len=[270] W=8760 fidji -> delos HTTP GET / HTTP/1.0 delos -> fidji ETHER Type=0800 (IP), size = 60 bytes delos -> fidji IP D=[129.88.38.84] S=[129.88.38.94] LEN=40, ID=12701 delos -> fidji TCP D=[36432] S=[80] Ack=[1014] Seq=[139] Len=0 W=31850 delos -> fidji HTTP R port=36432 12
TCP Congestion Control & AIMD We saw that additive-increase-multiplicative-decrease (AIMD) leads to a fair sharing of the link capacity (under some idealized assumptions) Q: What happens if RTT1 = 2 x RTT2 Connection 2 throughput R Connection 1 throughput R 13
TCP Congestion Control & AIMD Q: What happens if RTT1 = 2 x RTT2 A: (x1,x2) converges to (1/3R, 2/3R) Note: throughput is inversely proportional to RTT; the formula we had derived for R(RTT,L) shows this as well Connection 2 throughput R Slope 2 Connection 1 throughput R 14
The Link-State Algorithm Execute the LS algorithm to find the shortest-path tree rooted at x z 14 2 x 6 1 y 3 w 1 1 v 3 4 1 9 u 2 t 4 1 s 15
LS: solution Step N D(s),p(s) D(t), p(t) D(u), p(u) D(v), p(v) D(w), p(w) D(y), p(y) D(z), p(z) 0 x 3,x 1,x 6,x 1 xw 4,w 2,w 6,x 2 xwv 11,v 3,v 3,v 3 xwvu 7,u 5,u 3,v 4 xwvuy 7,u 5,u 17,y 5 xwvuyt 6,t 7,t 6 xwvuyts 7,t Note: when a node is added to N, there can be no further changes to its cost + parent 16
The Distance Vector Algorithm u 1 v 5 2 z 15 2 10 x 1 y Compute the DV table at node z (assuming the algorithm has converged). Hint: try to read the distances directly from the graph by inspection, rather than actually simulating the whole algorithm! 17
The Distance Vector Algorithm: table from z Via v x y Destination u 6 4 13 v 5 5 14 x 8 2 11 y 9 3 10 18
Distance Vector Algorithm: complete! X 2 Y 7 1 Z 19
Distance Vector Algorithm: solution new shortest path to dest (i.e., min over all neighbors changes) best shortest path to dest, no update necessary 2 8 3 7 X 2 Y 7 1 Z 2 4 5 1 7 3 9 1 20
IP Addresses and Prefixes You are given the following three address blocks: 128.178.128.0/17 128.178.128.0/18 128.178.160.0/19 Write down the start and end address for each block Which is the longest prefix matched by address 128.178.140.30? 21
IP Addresses and Prefixes Prefixes: x=128.178.128.0/17=128.178.128.0-128.178.255.255 y=128.178.128.0/18=128.178.128.0-128.178.191.255 z=128.178.160.0/19=128.178.160.0-128.178.191.255 Longest prefix match: 128.178.140.30 matches x,y, but not z y is the longest prefix (smallest block) Write these down in binary if needed (there are only 10 kinds of people: those who know binary, and those who don't) 22
ARP (Address Resolution Protocol) Given this topology, and LAN1=111.111.111/24, LAN2=222.222.222/24, and LAN3=333.333.333/24 Assign IP addresses to all interfaces (adapters) Enumerate steps taken by a packet A->E, when all ARP tables are initially empty Enumerate steps for second packet A->E, with up-to-date ARP tables A R1 R2 B LAN1 E LAN3 C LAN2 D 23
ARP (Address Resolution Protocol) A possible address allocation A B LAN1 111.111.111.1 111.111.111.4 111.111.111.3 R1 222.222.222.1 222.222.222.4 R2 333.333.333.1 333.333.333.3 E LAN3 C D LAN2 24
ARP A->E, empty ARP tables A checks routing table for an entry that matches E (probably finds a default gateway that it sends everything to leaving the network 111.111.111/24; its routing table says that next_hop = 111.111.111.4 A broadcasts ARP request asking who has IP address 111.111.111.4? R1 responds (more specifically, Ethernet adaptor on R1): I have IP address 111.111.111.4, and my MAC address is X; A enters this information into its ARP table A sends the IP packet in an Ethernet frame with src=mac_a, dst = X R1's adaptor on network 111.111.111/24 receives frame, decapsulates, checks its routing table to determine that next hop is 222.222.222.4, finds interface connected to it, and hands packet to adaptor for 222.222.222/24 This adaptor repeats same process as above, etc. If ARP tables are already populated, the broadcast steps do not happen 25
CSMA/CD in Ethernet Given: Two nodes A and B on the same Ethernet segment Propagation (one-way) delay 225 bit times (bit-time = 1 bit/10mbps) (this corresponds to dist. 225 x 0.1us x 2e5km/s = 4.5km) Suppose A sends a frame; before the first bit of that frame reaches B, B starts sending a frame as well -> collision Question: Is it possible that A finishes transmitting its frame before it detects that B is transmitting as well? Note: If this happens, it would mean that A erroneously assumes that its frame got through, although it did not Minimum Ethernet frame size is 512+64=576 bits 26
CSMA/CD in Ethernet A Start xmit A B Worst-case assumptions: A and B are at different extremities of cable Transmission at B starts right before A's transmission arrives at B Start xmit B Then: A still transmitting -> collision detected B's transmission arrives at A at the latest at 2RTT = 450 bit-times; therefore, Ethernet minimum frame size ensures that A's transmission is still going on, i.e., A detects collision Any other node between A and B also detects collision 27