Internet structure network of networks q Tier3 ISPs

Internet structure: network of networks q “Tier-3” ISPs and local ISPs v last hop (“access”) network (closest to end systems) local ISP Local and tier 3 ISPs are customers of higher tier ISPs connecting them to rest of Internet Tier 3 ISP Tier-2 ISP local ISP Tier-2 ISP Tier 1 ISP Tier-2 ISP local ISP Introduction 1 -1

Processes communicating Process: program running within a host. q within same host, two processes communicate using inter-process communication (defined by OS). q processes in different hosts communicate by exchanging messages Client process: process that initiates communication Server process: process that waits to be contacted r Note: applications with P 2 P architectures have client processes & server processes 2: Application Layer 2

Sockets q process sends/receives messages to/from its socket q socket analogous to door v v sending process shoves message out door sending process relies on transport infrastructure on other side of door which brings message to socket at receiving process host or server process controlled by app developer process socket TCP with buffers, variables Internet TCP with buffers, variables controlled by OS r API: (1) choice of transport protocol; (2) ability to fix a few parameters (lots more on this later) 2: Application Layer 3

Addressing processes q to receive messages, q Q: does IP address of host on which process must have runs suffice for identifier identifying the process? q host device has unique 32 v A: No, many processes -bit IP address can be running on q Exercise: use ipconfig same from command prompt to q Identifier includes both get your IP address and port (Windows) numbers associated with process on host. q Example port numbers: v v HTTP server: 80 Mail server: 25 2: Application Layer 4

Scenario: Alice sends message to Bob 4) SMTP client sends Alice’s message over the TCP connection 5) Bob’s mail server places the message in Bob’s mailbox 6) Bob invokes his user agent to read message 1) Alice uses UA to compose message and “to” bob@someschool. edu 2) Alice’s UA sends message to her mail server; message placed in message queue 3) Client side of SMTP opens TCP connection with Bob’s mail server 1 user agent 2 mail server 3 mail server 4 5 6 user agent 2: Application Layer 5

Transport service requirements of common apps Data loss Throughput Time Sensitive file transfer e-mail Web documents real-time audio/video no loss-tolerant no no no yes, 100’s msec stored audio/video interactive games instant messaging loss-tolerant no loss elastic audio: 5 kbps-1 Mbps video: 10 kbps-5 Mbps same as above few kbps up elastic Application yes, few secs yes, 100’s msec yes and no 2: Application Layer 6

Rdt 2. 0: channel with bit errors q underlying channel may flip bits in packet v checksum to detect bit errors q the question: how to recover from errors: v acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK v negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors v sender retransmits pkt on receipt of NAK q new mechanisms in rdt 2. 0 (beyond rdt 1. 0): v v error detection receiver feedback: control msgs (ACK, NAK) rcvr->sender

rdt 2. 0 has a fatal flaw! What happens if ACK/NAK corrupted? q sender doesn’t know what happened at receiver! q can’t just retransmit: possible duplicate Handling duplicates: q sender retransmits current pkt if ACK/NAK garbled q sender adds sequence number to each pkt q receiver discards (doesn’t deliver up) duplicate pkt stop and wait Sender sends one packet, then waits for receiver response

rdt 3. 0: channels with errors and loss New assumption: underlying channel can also lose packets (data or ACKs) v checksum, seq. #, ACKs, retransmissions will be of help, but not enough Approach: sender waits “reasonable” amount of time for ACK q retransmits if no ACK received in this time q if pkt (or ACK) just delayed (not lost): v retransmission will be duplicate, but use of seq. #’s already handles this v receiver must specify seq # of pkt being ACKed q requires countdown timer

TCP: retransmission scenarios Host A 2, 8 by tes da t Seq=92 timeout a 100 X = ACK loss Seq=9 2, 8 by tes da ta 100 Sendbase = 100 Send. Base = 120 = ACK Send. Base = 100 time Host B Seq=9 Send. Base = 120 lost ACK scenario 2, 8 by tes da ta Seq= 100, 2 0 byte s data 0 10 = K 120 = C K A AC Seq=9 2, 8 by Seq=92 timeout Seq=9 timeout Host A Host B time tes da t a 20 K=1 AC premature timeout

TCP retransmission scenarios (more) Host A Host B Seq=9 timeout 2, 8 by Send. Base = 120 Seq=1 tes da t a =100 K C A 00, 20 bytes data X loss 120 = ACK time Cumulative ACK scenario

Host A Host B seq # x 1 seq # x 2 seq # x 3 seq # x 4 seq # x 5 triple duplicate ACKs X ACK x 1 timeout resend time ACK x 1 seq X 2

TCP Flow Control q receive side of TCP connection has a receive buffer: (currently) TCP data application IP unused buffer (in buffer) process datagrams space q app process may be slow at reading from buffer flow control sender won’t overflow receiver’s buffer by transmitting too much, too fast q speed-matching service: matching send rate to receiving application’s drain rate

TCP congestion control: q goal: TCP sender should transmit as fast as possible, but without congesting network v Q: how to find rate just below congestion level q decentralized: each TCP sender sets its own rate, based on implicit feedback: v ACK: segment received (a good thing!), network not congested, so increase sending rate v lost segment: assume loss due to congested network, so decrease sending rate

TCP Slow Start q when connection begins, cwnd = Host A RTT 1 MSS v example: MSS = 500 bytes & RTT = 200 msec v initial rate = 20 kbps q available bandwidth may be >> MSS/RTT v desirable to quickly ramp up to respectable rate q increase rate exponentially until first loss event or when threshold reached v double cwnd every RTT v done by incrementing cwnd by 1 for every ACK received Host B one segme nt two segme nts four segme nts time

Summary: TCP Congestion Control q when cwnd < ssthresh, sender in slow-start phase, window grows exponentially. q when cwnd >= ssthresh, sender is in congestion- avoidance phase, window grows linearly. q when triple duplicate ACK occurs, ssthresh set to cwnd/2, cwnd set to ~ ssthresh q when timeout occurs, ssthresh set to cwnd/2, cwnd set to 1 MSS.

Routing Algorithm classification Global or decentralized information? Global: q all routers have complete topology, link cost info q “link state” algorithms Decentralized: q router knows physicallyconnected neighbors, link costs to neighbors q iterative process of computation, exchange of info with neighbors q “distance vector” algorithms Static or dynamic? Static: q routes change slowly over time Dynamic: q routes change more quickly v periodic update v in response to link cost changes

A Link-State Routing Algorithm Dijkstra’s algorithm q net topology, link costs known to all nodes v accomplished via “link state broadcast” v all nodes have same info q computes least cost paths from one node (‘source”) to all other nodes v gives forwarding table for that node q iterative: after k iterations, know least cost path to k dest. ’s Notation: q c(x, y): link cost from node x to y; = ∞ if not direct neighbors q D(v): current value of cost of path from source to dest. v q p(v): predecessor node along path from source to v q N': set of nodes whose least cost path definitively known

Distance vector algorithm (4) Basic idea: q From time-to-time, each node sends its own distance vector estimate to neighbors q Asynchronous q When a node x receives new DV estimate from neighbor, it updates its own DV using B-F equation: Dx(y) ← minv{c(x, v) + Dv(y)} for each node y ∊ N q Under minor, natural conditions, the estimate Dx(y) converge to the actual least cost dx(y)

Dx(y) = min{c(x, y) + Dy(y), c(x, z) + Dz(y)} = min{2+0 , 7+1} = 2 node x table cost to x y z from x 0 2 7 y ∞∞ ∞ z ∞∞ ∞ node y table cost to x y z Dx(z) = min{c(x, y) + Dy(z), c(x, z) + Dz(z)} = min{2+1 , 7+0} = 3 x 0 2 3 y 2 0 1 z 7 1 0 x ∞ ∞ ∞ y 2 0 1 z ∞∞ ∞ node z table cost to x y z from x x ∞∞ ∞ y ∞∞ ∞ z 71 0 time 2 y 7 1 z

Dx(y) = min{c(x, y) + Dy(y), c(x, z) + Dz(y)} = min{2+0 , 7+1} = 2 node x table cost to x y z x ∞∞ ∞ y ∞∞ ∞ z 71 0 from x 0 2 7 y 2 0 1 z 7 1 0 cost to x y z x 0 2 7 y 2 0 1 z 3 1 0 x 0 2 3 y 2 0 1 z 3 1 0 cost to x y z from x ∞ ∞ ∞ y 2 0 1 z ∞∞ ∞ node z table cost to x y z x 0 2 3 y 2 0 1 z 7 1 0 cost to x y z from x 0 2 7 y ∞∞ ∞ z ∞∞ ∞ node y table cost to x y z Dx(z) = min{c(x, y) + Dy(z), c(x, z) + Dz(z)} = min{2+1 , 7+0} = 3 x 0 2 3 y 2 0 1 z 3 1 0 time x 2 y 7 1 z

Hierarchical Routing Our routing study thus far - idealization q all routers identical q network “flat” … not true in practice scale: with 200 million destinations: q can’t store all dest’s in routing tables! q routing table exchange would swamp links! administrative autonomy q internet = network of networks q each network admin may want to control routing in its own network

Slotted ALOHA Pros q single active node can continuously transmit at full rate of channel q highly decentralized: only slots in nodes need to be in sync q simple Cons q collisions, wasting slots q idle slots q nodes may be able to detect collision in less than time to transmit packet q clock synchronization

Switch q link-layer device: smarter than hubs, take active role store, forward Ethernet frames v examine incoming frame’s MAC address, selectively forward frame to one-or-more outgoing links when frame is to be forwarded on segment, uses CSMA/CD to access segment v q transparent v hosts are unaware of presence of switches q plug-and-play, self-learning v switches do not need to be configured

DHCP: Dynamic Host Configuration Protocol Goal: allow host to dynamically obtain its IP address from network server when it joins network Can renew its lease on address in use Allows reuse of addresses (only hold address while connected an “on”) Support for mobile users who want to join network (more shortly) DHCP overview: v host broadcasts “DHCP discover” msg [optional] v DHCP server responds with “DHCP offer” msg [optional] v host requests IP address: “DHCP request” msg v DHCP server sends address: “DHCP ack” msg