* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download 4th Edition: Chapter 1
Survey
Document related concepts
Distributed operating system wikipedia , lookup
Distributed firewall wikipedia , lookup
Deep packet inspection wikipedia , lookup
Remote Desktop Services wikipedia , lookup
Airborne Networking wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
IEEE 802.1aq wikipedia , lookup
Internet protocol suite wikipedia , lookup
Dynamic Host Configuration Protocol wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Transcript
Internet structure: network of networks “Tier-3” ISPs and local ISPs last hop (“access”) network (closest to end systems) local ISP Local and tier3 ISPs are customers of higher tier ISPs connecting them to rest of Internet Tier 3 ISP Tier-2 ISP local ISP local ISP local ISP Tier-2 ISP Tier 1 ISP Tier 1 ISP Tier-2 ISP local local ISP ISP Tier 1 ISP Tier-2 ISP local ISP Tier-2 ISP local ISP Introduction 1-1 Processes communicating Process: program running within a host. within same host, two processes communicate using inter-process communication (defined by OS). 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 P2P architectures have client processes & server processes 2: Application Layer 2 Sockets process sends/receives messages to/from its socket socket analogous to door 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 host or server process controlled by app developer process socket 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 to receive messages, Q: does IP address of host on which process process must have runs suffice for identifier identifying the process? host device has unique A: No, many processes 32-bit IP address can be running on Exercise: use ipconfig same from command prompt to Identifier includes both get your IP address IP address and port (Windows) numbers associated with process on host. Example port numbers: HTTP server: 80 Mail server: 25 2: Application Layer 4 Scenario: Alice sends message to Bob 1) Alice uses UA to compose message and “to” [email protected] 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 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 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 no loss no loss loss-tolerant no no no yes, 100’s msec stored audio/video interactive games instant messaging loss-tolerant loss-tolerant no loss elastic elastic elastic audio: 5kbps-1Mbps video:10kbps-5Mbps same as above few kbps up elastic Application yes, few secs yes, 100’s msec yes and no 2: Application Layer 6 Rdt2.0: channel with bit errors underlying channel may flip bits in packet checksum to detect bit errors the question: how to recover from errors: acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors sender retransmits pkt on receipt of NAK new mechanisms in rdt2.0 (beyond rdt1.0): error detection receiver feedback: control msgs (ACK,NAK) rcvr->sender rdt2.0 has a fatal flaw! What happens if ACK/NAK corrupted? sender doesn’t know what happened at receiver! can’t just retransmit: possible duplicate Handling duplicates: sender retransmits current pkt if ACK/NAK garbled sender adds sequence number to each pkt receiver discards (doesn’t deliver up) duplicate pkt stop and wait Sender sends one packet, then waits for receiver response rdt3.0: channels with errors and loss New assumption: underlying channel can also lose packets (data or ACKs) checksum, seq. #, ACKs, retransmissions will be of help, but not enough Approach: sender waits “reasonable” amount of time for ACK retransmits if no ACK received in this time if pkt (or ACK) just delayed (not lost): retransmission will be duplicate, but use of seq. #’s already handles this receiver must specify seq # of pkt being ACKed requires countdown timer TCP: retransmission scenarios Host A X loss Sendbase = 100 SendBase = 120 SendBase = 100 time SendBase = 120 lost ACK scenario Host B Seq=92 timeout Host B Seq=92 timeout timeout Host A time premature timeout TCP retransmission scenarios (more) timeout Host A Host B X loss SendBase = 120 time Cumulative ACK scenario Host A seq # x1 seq # x2 seq # x3 seq # x4 seq # x5 timeout triple duplicate ACKs time Host B X ACK x1 ACK x1 ACK x1 ACK x1 TCP Flow Control receive side of TCP connection has a receive buffer: (currently) TCP data application IP unused buffer (in buffer) process datagrams space app process may be slow at reading from buffer flow control sender won’t overflow receiver’s buffer by transmitting too much, too fast speed-matching service: matching send rate to receiving application’s drain rate TCP congestion control: goal: TCP sender should transmit as fast as possible, but without congesting network Q: how to find rate just below congestion level decentralized: each TCP sender sets its own rate, based on implicit feedback: ACK: segment received (a good thing!), network not congested, so increase sending rate lost segment: assume loss due to congested network, so decrease sending rate TCP Slow Start when connection begins, cwnd = Host A Host B RTT 1 MSS example: MSS = 500 bytes & RTT = 200 msec initial rate = 20 kbps available bandwidth may be >> MSS/RTT desirable to quickly ramp up to respectable rate increase rate exponentially until first loss event or when threshold reached double cwnd every RTT done by incrementing cwnd by 1 for every ACK received time Summary: TCP Congestion Control when cwnd < ssthresh, sender in slow-start phase, window grows exponentially. when cwnd >= ssthresh, sender is in congestion- avoidance phase, window grows linearly. when triple duplicate ACK occurs, ssthresh set to cwnd/2, cwnd set to ~ ssthresh when timeout occurs, ssthresh set to cwnd/2, cwnd set to 1 MSS. Routing Algorithm classification Global or decentralized information? Global: all routers have complete topology, link cost info “link state” algorithms Decentralized: router knows physicallyconnected neighbors, link costs to neighbors iterative process of computation, exchange of info with neighbors “distance vector” algorithms Static or dynamic? Static: routes change slowly over time Dynamic: routes change more quickly periodic update in response to link cost changes A Link-State Routing Algorithm Dijkstra’s algorithm net topology, link costs known to all nodes accomplished via “link state broadcast” all nodes have same info computes least cost paths from one node (‘source”) to all other nodes gives forwarding table for that node iterative: after k iterations, know least cost path to k dest.’s Notation: c(x,y): link cost from node x to y; = ∞ if not direct neighbors D(v): current value of cost of path from source to dest. v p(v): predecessor node along path from source to v N': set of nodes whose least cost path definitively known Distance vector algorithm (4) Basic idea: From time-to-time, each node sends its own distance vector estimate to neighbors Asynchronous 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 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 cost to x y z from 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 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 from from 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 x 0 2 3 y 2 0 1 z 3 1 0 cost to x y z from from 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 cost to x y z from from x 0 2 7 y ∞∞ ∞ z ∞∞ ∞ node y table cost to x y z 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 all routers identical network “flat” … not true in practice scale: with 200 million destinations: can’t store all dest’s in routing tables! routing table exchange would swamp links! administrative autonomy internet = network of networks each network admin may want to control routing in its own network Slotted ALOHA Pros single active node can continuously transmit at full rate of channel highly decentralized: only slots in nodes need to be in sync simple Cons collisions, wasting slots idle slots nodes may be able to detect collision in less than time to transmit packet clock synchronization Switch link-layer device: smarter than hubs, take active role store, forward Ethernet frames 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 transparent hosts are unaware of presence of switches plug-and-play, self-learning 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: host broadcasts “DHCP discover” msg [optional] DHCP server responds with “DHCP offer” msg [optional] host requests IP address: “DHCP request” msg DHCP server sends address: “DHCP ack” msg