1 / 89

Networking Review

In the Name of the Most High. Networking Review. By Behzad Akbari. These power point slides have been adapted from slides prepared by Prof . Jim Kurose (U Mass). Goals: review key topics from intro networks course equalize backgrounds identify remedial work ease into course. Overview:

tanuja
Download Presentation

Networking Review

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. In the Name of the Most High Networking Review By Behzad Akbari These power point slides have been adapted from slides prepared by Prof. Jim Kurose (U Mass)

  2. Goals: review key topics from intro networks course equalize backgrounds identify remedial work ease into course Overview: overview error control flow control congestion control routing LANs addressing Networking Review

  3. millions of connected computing devices: hosts = end systems running network apps PC Mobile network server Global ISP wireless laptop cellular handheld Home network Regional ISP access points wired links Institutional network router What’s the Internet: “nuts and bolts” view • communication links • fiber, copper, radio, satellite • transmission rate = bandwidth • routers: forward packets (chunks of data)

  4. protocolscontrol sending, receiving of msgs e.g., TCP, IP, HTTP, Skype, Ethernet Internet: “network of networks” loosely hierarchical public Internet versus private intranet Internet standards RFC: Request for comments IETF: Internet Engineering Task Force Mobile network Global ISP Home network Regional ISP Institutional network What’s the Internet: “nuts and bolts” view

  5. human protocols: “what’s the time?” “I have a question” introductions … specific msgs sent … specific actions taken when msgs received, or other events network protocols: machines rather than humans all communication activity in Internet governed by protocols What’s a protocol? protocols define format, order of msgs sent and received among network entities, and actions taken on msg transmission, receipt

  6. a human protocol and a computer network protocol: TCP connection response Get http://www.awl.com/kurose-ross Got the time? 2:00 <file> time What’s a protocol? Hi TCP connection request Hi Q: Other human protocols?

  7. network edge: applications and hosts A closer look at network structure: • access networks, physical media: wired, wireless communication links • network core: • interconnected routers • network of networks

  8. end systems (hosts): run application programs e.g. Web, email at “edge of network” peer-peer client/server The network edge: • client/server model • client host requests, receives service from always-on server • e.g. Web browser/server; email client/server • peer-peer model: • minimal (or no) use of dedicated servers • e.g. Skype, BitTorrent

  9. Goal: data transfer between end systems handshaking: setup (prepare for) data transfer ahead of time Hello, hello back human protocol set up “state” in two communicating hosts TCP - Transmission Control Protocol Internet’s reliable data transfer service TCP service[RFC 793] reliable, in-order byte-stream data transfer loss: acknowledgements and retransmissions flow control: sender won’t overwhelm receiver congestion control: senders “slow down sending rate” when network congested Network edge: reliable data transfer service

  10. Goal: data transfer between end systems same as before! UDP - User Datagram Protocol [RFC 768]: connectionless unreliable data transfer no flow control no congestion control App’s using TCP: HTTP (Web), FTP (file transfer), Telnet (remote login), SMTP (email) App’s using UDP: streaming media, teleconferencing, DNS, Internet telephony Network edge: best effort (unreliable) data transfer service

  11. Q: How to connect end systems to edge router? residential access nets institutional access networks (school, company): LAN mobile access networks Keep in mind: bandwidth (bits per second) of access network? shared or dedicated? Access networks and physical media

  12. company/univ local area network (LAN) connects end system to edge router Ethernet: 10 Mbs, 100Mbps, 1Gbps, 10Gbps Ethernet modern configuration: end systems connect into Ethernetswitch Question: switch versus router? Local area networks

  13. shared wireless access network connects end system to router via base station aka “access point” wireless LANs: 802.11b/g (WiFi): 11 or 54 Mbps wider-area wireless access provided by telco operator ~1Mbps over cellular system (EVDO, HSDPA) next up (?): WiMAX (10’s Mbps) over wide area Wireless access networks router base station mobile hosts

  14. mesh of interconnected routers the fundamental question: how is data transferred through net? circuit switching: dedicated circuit per call: telephone net packet-switching: data sent thru net in discrete “chunks” The Network Core

  15. End-end resources reserved for “call” link bandwidth, switch capacity dedicated resources: no sharing circuit-like (guaranteed) performance call setup required Network Core: Circuit Switching

  16. network resources (e.g., bandwidth) divided into “pieces” pieces allocated to calls resource piece idle if not used by owning call (no sharing) Network Core: Circuit Switching • Qiestion: how is bandwidth divided into “pieces”

  17. each end-end data stream divided into packets user A, B packets share network resources each packet uses full link bandwidth resources used as needed Bandwidth division into “pieces” Dedicated allocation Resource reservation Network Core: Packet Switching resource contention: • aggregate resource demand can exceed amount available • congestion: packets queue, wait for link use • store and forward: packets move one hop at a time • Node receives complete packet before forwarding

  18. Question: why packet switching? D E Packet Switching: Statistical Multiplexing 100 Mb/s Ethernet C A statistical multiplexing 1.5 Mb/s B queue of packets waiting for output link

  19. roughly hierarchical at center: “tier-1” ISPs (e.g., Verizon, Sprint, AT&T, Cable and Wireless), national/international coverage treat each other as equals Tier-1 providers interconnect (peer) privately Internet structure: network of networks Tier 1 ISP Tier 1 ISP Tier 1 ISP

  20. POP: point-of-presence to/from backbone peering … …. … … … to/from customers Tier-1 ISP: e.g., Sprint

  21. “Tier-2” ISPs: smaller (often regional) ISPs Connect to one or more tier-1 ISPs, possibly other tier-2 ISPs Tier-2 ISPs also peer privately with each other. • Tier-2 ISP pays tier-1 ISP for connectivity to rest of Internet • tier-2 ISP is customer of tier-1 provider Tier-2 ISP Tier-2 ISP Tier-2 ISP Tier-2 ISP Tier-2 ISP Internet structure: network of networks Tier 1 ISP Tier 1 ISP Tier 1 ISP

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

  23. a packet passes through many networks! Tier 3 ISP local ISP local ISP local ISP local ISP local ISP local ISP local ISP local ISP Tier-2 ISP Tier-2 ISP Tier-2 ISP Tier-2 ISP Tier-2 ISP Internet structure: network of networks Tier 1 ISP Tier 1 ISP Tier 1 ISP

  24. Networks are complex! many “pieces”: hosts routers links of various media applications protocols hardware, software Protocol “Layers”

  25. application: supporting network applications (FTP, SMTP, HTTP) transport: process-process data transfer (TCP, UDP) network: routing of datagrams from source to destination IP, routing protocols link: data transfer between neighboring network elements PPP, Ethernet physical: bits “on the wire” application transport network link physical Internet protocol stack Question: anything missing?

  26. network link physical link physical M M M Ht M Hn Hn Hn Hn Ht Ht Ht Ht M M M M Hn Ht Ht Hl Hl Hl Hn Hn Hn Ht Ht Ht M M M source Encapsulation message application transport network link physical segment datagram frame switch destination application transport network link physical router

  27. Goals: review key topics from intro networks course equalize backgrounds identify remedial work ease into course Overview: overview error control flow control congestion control routing LANs addressing synthesis: control timescales Networking Review

  28. reliable point-point communication generic problem: app-to-app, over path, over link error model? bits flipped in packet packets “lost packets delayed or reordered service implementation provided service Error control

  29. Bit level error detection • EDC= Error Detection and Correction bits (redundancy) • D = Data protected by error checking, may include header fields • Error detection not 100% reliable! • protocol may miss some errors, but rarely • larger EDC field yields better detection and correction

  30. Parity Checking Two Dimensional Bit Parity: Detect and correct single bit errors Single Bit Parity: Detect single bit errors Much more powerful error detection/correction schemes: Cyclic Redundancy Check (CRC) 0 0 Simple form of forward error correction (FEC)

  31. Sender: treat segment contents as sequence of 16-bit integers checksum: addition (1’s complement sum) of segment contents sender puts checksum value into segment checksum field Receiver: compute checksum of received segment check if computed checksum equals checksum field value: NO - error detected YES - no error detected. But maybe errors nonetheless? Internet checksum Goal: detect “errors” (e.g., flipped bits) in transmitted segment (note: used at transport layer only)

  32. Recovering from lost packets • why are packets lost? • limited storage, discarded in congestion • outages: eventually reroute around failure (~sec recovery times hopefully) • dropped at end system e.g., on NIC • ARQ: automatic request repeat • sender puts sequence numbers on packets (why) • receiver positively or negatively acknowledges correct receipt of packet • sender starts (logical) timer for each packet, timeout and retransmits

  33. Assumption: underlying channel can corrupt, lose packets (data or ACKs) need checksum, seq. #, ACKs, retransmissions, timer seq #s detect reordering ACK, NAKing detect missing packet duplicate detection due to retransmissions 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 0,1 seq. #’s already handles this receiver must specify seq # of pkt being ACKed requires countdown timer Reference: section 3.4 in K&R rdt3.0: channels with errors and loss

  34. Wait for ACK0 Wait for ACK1 rdt3.0 sender rdt_send(data) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer L rdt_rcv(rcvpkt) L wait for call from above timeout 0 udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) stop_timer stop_timer wait for call from above timeout 1 udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) L rdt_send(data) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) ) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer L FSM specification of sender (details not important)

  35. rdt3.0 in action

  36. rdt3.0 in action

  37. Forward error control • add redundancy to recover from losses original file (n blocks) encoding (potentially) infinite number of blocks lossy channel eventually receive n(1+e) blocks decoding recover file

  38. Forward error control • e controls computation cost, BW usage • used for video delivery; large file transfers

  39. Goals: review key topics from intro networks course equalize backgrounds identify remedial work ease into course Overview: overview error control flow control congestion control routing LANs addressing synthesis: “a day in the life” control timescales Networking Review

  40. receiver: explicitly informs sender of (dynamically changing) amount of free buffer space RcvWindow field in TCP segment sender: keeps the amount of transmitted, unACKed data less than most recently received RcvWindow flow control sender won’t overrun receiver’s buffers by transmitting too much, too fast Flow Control (in TCP) RcvBuffer= size of TCP Receive Buffer RcvWindow = amount of spare room in Buffer receiver buffering

  41. Congestion: informally: “too many sources sending too much data too fast for network to handle” different from flow control! manifestations: lost packets (buffer overflow at routers) long delays (queueing in router buffers) Principles of Congestion Control

  42. two senders, two receivers one router, infinite buffers no retransmission large delays when congested maximum achievable throughput lout lin : original data unlimited shared output link buffers Host A Host B Causes/costs of congestion: scenario 1

  43. one router, finite buffers sender retransmission of lost packet Causes/costs of congestion: scenario 2 Host A lout lin : original data l'in : original data, plus retransmitted data l‘out : original data, duplicates Host B finite shared output link buffers

  44. always: (goodput) “perfect” retransmission only when loss: retransmission of delayed (not lost) packet makes larger (than perfect case) for same l l l > = l l l R/2 in in in R/2 R/2 out out out R/3 lout lout lout R/4 R/2 R/2 R/2 lin lin lin a. b. c. Causes/costs of congestion: scenario 2 “costs” of congestion: • more work (retrans) for given “goodput” • unneeded retransmissions: link carries multiple copies of pkt

  45. four senders multihop paths timeout/retransmit l l in in Host A Host B Causes/costs of congestion: scenario 3 Q:what happens as and increase ? lout lin : original data l'in : original data, plus retransmitted data finite shared output link buffers

  46. Host A Host B Causes/costs of congestion: scenario 3 lout Another “cost” of congestion: • when packet dropped, any “upstream transmission capacity used for that packet was wasted!

  47. End-end congestion control: no explicit feedback from network congestion inferred from end-system observed loss, delay approach taken by TCP Network-assisted congestion control: routers provide feedback to end systems single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM) explicit rate sender should send at Approaches towards congestion control Two broad approaches towards congestion control:

  48. ABR: available bit rate: “elastic service” if sender’s path “underloaded”: sender should use available bandwidth if sender’s path congested: sender throttled to minimum guaranteed rate RM (resource management) cells: sent by sender, interspersed with data cells bits in RM cell set by switches (“network-assisted”) NI bit: no increase in rate (mild congestion) CI bit: congestion indication RM cells returned to sender by receiver, with bits intact Case study: ATM ABR congestion control

  49. two-byte ER (explicit rate) field in RM cell congested switch may lower ER value in cell sender’ send rate thus minimum supportable rate on path EFCI bit in data cells: set to 1 in congested switch if data cell preceding RM cell has EFCI set, sender sets CI bit in returned RM cell Case study: ATM ABR congestion control

  50. end-end control (no network assistance) transmission rate limited by congestion window size, Congwin, over segments: TCP Congestion Control Congwin

More Related