Chapter 1: roadmap. 1.1 what is the Internet? 1.2 network edge. 1.3 network core

Transcription

1 Chapter 1: roadmap 1.1 what is the Internet? 1.2 network edge end systems, access networks, links 1.3 network core packet switching, circuit switching, network structure 1.4 delay, loss, throughput in networks 1.5 protocol layers, service models Introduction 1-1

2 A closer look at network structure: network edge: hosts: clients and servers servers often in data centers access networks, physical media: wired, wireless communication links mobile network home network global ISP regional ISP network core: interconnected routers network of networks institutional network Introduction 1-2

3 What s the Internet: a service view Infrastructure that provides services to applications: Web, VoIP, , games, e- commerce, social nets, provides programming interface to apps hooks that allow sending and receiving app programs to connect to Internet provides service options, analogous to postal service mobile network home network institutional network global ISP regional ISP Introduction 1-3

4 Access net: digital subscriber line (DSL) central office telephone network DSL modem splitter voice, data transmitted at different frequencies over dedicated line to central office DSLAM DSL access multiplexer ISP use existing telephone line to central office DSLAM data over DSL phone line goes to Internet voice over DSL phone line goes to telephone net < 2.5 Mbps upstream transmission rate (typically < 1 Mbps) < 24 Mbps downstream transmission rate (typically < 10 Mbps) Introduction 1-4

5 Access net: cable network cable headend cable modem splitter data, TV transmitted at different frequencies over shared cable distribution network CMTS cable modem termination system ISP HFC: hybrid fiber coax asymmetric: up to 30Mbps downstream transmission rate, 2 Mbps upstream transmission rate network of cable, fiber attaches homes to ISP router homes share access network to cable headend unlike DSL, which has dedicated access to central office Introduction 1-5

6 Access net: home network wireless devices often combined in single box to/from headend or central office cable or DSL modem wireless access point (54 Mbps) router, firewall, NAT wired Ethernet (100 Mbps) Introduction 1-6

7 Enterprise access networks (Ethernet) institutional link to ISP (Internet) institutional router Ethernet switch institutional mail, web servers typically used in companies, universities, etc 10 Mbps, 100Mbps, 1Gbps, 10Gbps transmission rates today, end systems typically connect into Ethernet switch Introduction 1-7

8 Wireless access networks shared wireless access network connects end system to router via base station aka access point wireless LANs: within building (100 ft) b/g (WiFi): 11, 54 Mbps transmission rate wide-area wireless access provided by telco (cellular) operator, 10 s km between 1 and 10 Mbps 3G, 4G: LTE to Internet to Internet Introduction 1-8

9 The network core mesh of interconnected routers packet-switching: hosts break application-layer messages into packets forward packets from one router to the next, across links on path from source to destination each packet transmitted at full link capacity Introduction 1-9

10 Packet-switching: store-and-forward L bits per packet source R bps R bps destination takes L/R seconds to transmit (push out) L-bit packet into link at R bps store and forward: entire packet must arrive at router before it can be transmitted on next link end-end delay = 2L/R (assuming zero propagation delay) one-hop numerical example: L = 7.5 Mbits R = 1.5 Mbps one-hop transmission delay = 5 sec more on delay shortly Introduction 1-10

11 Packet Switching: queueing delay, loss A R = 100 Mb/s C B queue of packets waiting for output link R = 1.5 Mb/s D E queuing and loss: If arrival rate (in bits) to link exceeds transmission rate of link for a period of time: packets will queue, wait to be transmitted on link packets can be dropped (lost) if memory (buffer) fills up Introduction 1-11

12 Two key network-core functions routing: determines sourcedestination route taken by packets routing algorithms forwarding: move packets from router s input to appropriate router output routing algorithm local forwarding table header value output link dest address in arriving packet s header Network Layer 4-12

13 Alternative core: circuit switching end-end resources allocated to, reserved for call between source & dest: In diagram, each link has four circuits. call gets 2 nd circuit in top link and 1 st circuit in right link. dedicated resources: no sharing circuit-like (guaranteed) performance circuit segment idle if not used by call (no sharing) Commonly used in traditional telephone networks Introduction 1-13

14 Packet switching versus circuit switching packet switching allows more users to use network! example: 1 Mb/s link each user: 100 kb/s when active active 10% of time N users 1 Mbps link circuit-switching: 10 users packet switching: with 35 users, probability > 10 active at same time is less than.0004 Q: how did we get value ? Q: what happens if 50 users? Introduction 1-14

15 Internet structure: network of networks Tier 1 ISP Tier 1 ISP Google IXP Regional ISP IXP Regional ISP IXP access ISP access ISP access ISP access ISP access ISP access ISP access ISP access ISP at center: small # of well-connected large networks tier-1 commercial ISPs (e.g., Level 3, Sprint, AT&T, NTT), national & international coverage content provider network (e.g, Google): private network that connects it data centers to Internet, often bypassing tier-1, regional ISPs 1-15 Introduction

16 Four sources of packet delay A transmission propagation B nodal processing queueing d nodal = d proc + d queue + d trans + d prop d proc : nodal processing check bit errors determine output link typically < msec d queue : queueing delay time waiting at output link for transmission depends on congestion level of router Introduction 1-16

17 Four sources of packet delay A transmission propagation B nodal processing queueing d nodal = d proc + d queue + d trans + d prop d trans : transmission delay: L: packet length (bits) R: link bandwidth (bps) d trans = L/R d trans and d prop very different d prop : propagation delay: d: length of physical link s: propagation speed in medium (~2x10 8 m/sec) d prop = d/s Introduction 1-17

18 Packet loss queue (aka buffer) preceding link in buffer has finite capacity packet arriving to full queue dropped (aka lost) lost packet may be retransmitted by previous node, by source end system, or not at all A buffer (waiting area) packet being transmitted B packet arriving to full buffer is lost Introduction 1-18

19 Throughput throughput: rate (bits/time unit) at which bits transferred between sender/receiver instantaneous: rate at given point in time average: rate over longer period of time server server, sends withbits (fluid) file of into F bits pipe to send to client link pipe capacity that can carry R s bits/sec fluid at rate R s bits/sec) link pipe capacity that can carry R c bits/sec fluid at rate R c bits/sec) Introduction 1-19

20 Throughput: Internet scenario per-connection endend throughput: min(r c,r s,r/10) in practice: R c or R s is often bottleneck R s R s R s R R c R c R c 10 connections (fairly) share backbone bottleneck link R bits/sec Introduction 1-20

21 Why layering? dealing with complex systems: explicit structure allows identification, relationship of complex system s pieces layered reference model for discussion modularization eases maintenance, updating of system change of implementation of layer s service transparent to rest of system e.g., change in gate procedure doesn t affect rest of system layering considered harmful? Introduction 1-21

22 Internet protocol stack application: supporting network applications FTP, SMTP, HTTP transport: process data transfer TCP, UDP network: routing of datagrams from source to destination IP, routing protocols link: data transfer between neighboring network elements Ethernet, (WiFi), PPP physical: bits on the wire application transport network link physical Introduction 1-22

23 segment datagram frame message H l H t H n H t H n H t M M M M source application transport network link physical Encapsulation link physical switch H l H n H n H t H t H t M M M M destination application transport network link physical H l H n H n H t H t M M network link physical H n H t M router Introduction 1-23

24 Chapter 2: outline 2.1 principles of network applications 2.2 Web and HTTP 2.3 FTP 2.4 electronic mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P applications 2.7 socket programming with UDP and TCP Application Layer 2-24

25 Creating a network app write programs that: run on (different) end systems communicate over network e.g., web server software communicates with browser software no need to write software for network-core devices network-core devices do not run user applications applications on end systems allows for rapid app development, propagation application transport network data link physical application transport network data link physical application transport network data link physical Application Layer 2-25

26 Client-server architecture server: always-on host permanent IP address data centers for scaling client/server clients: communicate with server may be intermittently connected may have dynamic IP addresses do not communicate directly with each other Application Layer 2-26

27 P2P architecture no always-on server arbitrary end systems directly communicate peers request service from other peers, provide service in return to other peers self scalability new peers bring new service capacity, as well as new service demands peers are intermittently connected and change IP addresses complex management peer-peer Application Layer 2-27

28 Sockets process sends/receives messages to/from its socket (SW interface) socket analogous to door sending process shoves message out door sending process relies on transport infrastructure on other side of door to deliver message to socket at receiving process application process socket application process controlled by app developer transport network link physical Internet transport network link physical controlled by OS Application Layer 2-28

29 Addressing processes to receive messages, process must have identifier host device has unique 32- bit IP address Q: does IP address of host on which process runs suffice for identifying the process? A: no, many processes can be running on same host identifier includes both IP address and port numbers associated with process on host. example port numbers: HTTP server: 80 mail server: 25 to send HTTP message to gaia.cs.umass.edu web server: IP address: port number: 80 more shortly Application Layer 2-29

30 App-layer protocol defines types of messages exchanged, e.g., request, response message syntax: what fields in messages & how fields are delineated message semantics meaning of information in fields rules for when and how processes send & respond to messages open protocols: defined in RFCs allows for interoperability e.g., HTTP (RFC2616), SMTP (RFC5321) proprietary protocols: e.g., Skype Application Layer 2-30

31 What transport service does an app need? data integrity some apps (e.g., file transfer, web transactions) require 100% reliable data transfer other apps (e.g., audio) can tolerate some loss timing some apps (e.g., Internet telephony, interactive games) require low delay to be effective throughput some apps (e.g., multimedia) require minimum amount of throughput to be effective other apps ( elastic apps ) make use of whatever throughput they get security encryption, data integrity, Application Layer 2-31

32 Web and HTTP First, a review web page consists of objects object can be HTML file, JPEG image, Java applet, audio file, web page consists of base HTML-file which includes several referenced objects each object is addressable by a URL (Uniform Resource Locator), e.g., host name path name Application Layer 2-32

33 HTTP overview HTTP: hypertext transfer protocol Web s application layer protocol client/server model client: browser that requests, receives, (using HTTP protocol) and displays Web objects server: Web server sends (using HTTP protocol) objects in response to requests PC running Firefox browser iphone running Safari browser server running Apache Web server Application Layer 2-33

34 HTTP overview (continued) uses TCP: client initiates TCP connection (creates socket) to server, port 80 server accepts TCP connection from client HTTP messages (application-layer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server) TCP connection closed HTTP is stateless server maintains no information about past client requests aside protocols that maintain state are complex! past history (state) must be maintained if server/client crashes, their views of state may be inconsistent, must be reconciled Application Layer 2-34

35 HTTP connections non-persistent HTTP at most one object sent over TCP connection connection then closed downloading multiple objects required multiple connections persistent HTTP multiple objects can be sent over single TCP connection between client, server Application Layer 2-35

36 HTTP request message two types of HTTP messages: request, response HTTP request message: ASCII (human-readable format) request line (GET, POST, HEAD, PUT, DELETE commands) header lines carriage return, line feed at start of line indicates end of header lines carriage return character line-feed character GET /index.html HTTP/1.1\r\n Host: www-net.cs.umass.edu\r\n User-Agent: Firefox/3.6.10\r\n Accept: text/html,application/xhtml+xml\r\n Accept-Language: en-us,en;q=0.5\r\n Accept-Encoding: gzip,deflate\r\n Accept-Charset: ISO ,utf-8;q=0.7\r\n Keep-Alive: 115\r\n Connection: keep-alive\r\n \r\n Application Layer 2-36

37 HTTP response message status line (protocol version status code status phrase) header lines data, e.g., requested HTML file HTTP/ OK\r\n Date: Sun, 26 Sep :09:20 GMT\r\n Server: Apache/ (CentOS)\r\n Last-Modified: Tue, 30 Oct :00:02 GMT\r\n ETag: "17dc6-a5c-bf716880"\r\n Accept-Ranges: bytes\r\n Content-Length: 2652\r\n Keep-Alive: timeout=10, max=100\r\n Connection: Keep-Alive\r\n Content-Type: text/html; charset=iso \r\n \r\n data data data data data... Application Layer 2-37

38 User-server state: cookies many Web sites use cookies four components: 1) cookie header line of HTTP response message 2) cookie header line in next HTTP request message 3) cookie file kept on user s host, managed by user s browser 4) back-end database at Web site example: Susan always access Internet from PC visits specific e-commerce site for first time when initial HTTP requests arrives at site, site creates: unique ID entry in backend database for ID Application Layer 2-38

39 Web caches (proxy server) goal: satisfy client request without involving origin server user sets browser: Web accesses via cache browser sends all HTTP requests to cache object in cache: cache returns object else cache requests object from origin server, then returns object to client client client proxy server origin server origin server Application Layer 2-39

40 More about Web caching cache acts as both client and server server for original requesting client client to origin server typically cache is installed by ISP (university, company, residential ISP) why Web caching? reduce response time for client request reduce traffic on an institution s access link Enables poor content providers to effectively deliver content Application Layer 2-40

41 Caching example possible solution: install cache suppose hit rate is 0.4 consequence 40% requests will be satisfied almost immediately 60% requests satisfied by origin server utilization of access link reduced to 60%, resulting in negligible delays (say 70 msec) total avg delay = Internet delay + access delay + LAN delay = 0.6*( ) secs + 0.4* ( ) = 1.3 secs institutional network public Internet 15 Mbps access link 100 Mbps LAN origin servers institutional cache 2: Application Layer 41

42 Conditional GET Goal: don t send object if cache has up-to-date cached version no object transmission delay lower link utilization cache: specify date of cached copy in HTTP request If-modified-since: <date> server: response contains no object if cached copy is up-to-date: HTTP/ Not Modified cache HTTP request msg If-modified-since: <date> HTTP response HTTP/ Not Modified HTTP request msg If-modified-since: <date> HTTP response HTTP/ OK <data> server object not modified before <date> object modified after <date> Application Layer 2-42

43 FTP: the file transfer protocol user at host FTP user interface FTP client local file system file transfer FTP server remote file system transfer file to/from remote host client/server model client: side that initiates transfer (either to/from remote) server: remote host ftp: RFC 959 ftp server: port 21 Application Layer 2-43

44 FTP: separate control, data connections FTP client contacts FTP server at port 21, using TCP client authorized over control connection client browses remote directory, sends commands over control connection when server receives file transfer command, server opens 2 nd TCP data connection (for file) to client after transferring one file, server closes data connection FTP client TCP control connection, server port 21 TCP data connection, server port 20 FTP server server opens another TCP data connection to transfer another file control connection: out of band Application Layer 2-44

45 Electronic mail Three major components: user agents mail servers simple mail transfer protocol: SMTP User Agent a.k.a. mail reader composing, editing, reading mail messages e.g., Outlook, Thunderbird, iphone mail client outgoing, incoming messages stored on server mail server SMTP mail server user agent user agent SMTP SMTP user agent outgoing message queue mail server user mailbox user agent user agent user agent Application Layer 2-45

46 Electronic mail: mail servers mail servers: mailbox contains incoming messages for user message queue of outgoing (to be sent) mail messages SMTP protocol between mail servers to send messages client: sending mail server server : receiving mail server mail server SMTP mail server user agent user agent SMTP SMTP user agent mail server user agent user agent user agent Application Layer 2-46

47 Electronic Mail: SMTP [RFC 2821] uses TCP to reliably transfer message from client to server, port 25 direct transfer: sending server to receiving server three phases of transfer handshaking (greeting) transfer of messages closure command/response interaction (like HTTP, FTP) commands: ASCII text response: status code and phrase messages must be in 7-bit ASCII Application Layer 2-47

48 Mail access protocols user agent SMTP SMTP mail access protocol (e.g., POP, IMAP) user agent sender s mail server receiver s mail server SMTP: delivery/storage to receiver s server mail access protocol: retrieval from server POP: Post Office Protocol [RFC 1939]: authorization, download IMAP: Internet Mail Access Protocol [RFC 1730]: more features, including manipulation of stored msgs on server HTTP: gmail, Hotmail, Yahoo! Mail, etc. Application Layer 2-48

49 DNS: domain name system people: many identifiers: SSN, name, passport # Internet hosts, routers: IP address (32 bit) - used for addressing datagrams name, e.g., - used by humans Q: how to map between IP address and name, and vice versa? Domain Name System: distributed database implemented in hierarchy of many name servers application-layer protocol: hosts, name servers communicate to resolve names (address/name translation) note: core Internet function, implemented as applicationlayer protocol complexity at network s edge Application Layer 2-49

50 DNS: services, structure DNS services hostname to IP address translation host aliasing mail server aliasing load distribution replicated Web servers: many IP addresses correspond to one name why not centralize DNS? single point of failure traffic volume distant centralized database maintenance A: doesn t scale! Application Layer 2-50

51 DNS: a distributed, hierarchical database Root DNS Servers com DNS servers org DNS servers edu DNS servers yahoo.com DNS servers amazon.com DNS servers pbs.org DNS servers poly.edu umass.edu DNS serversdns servers client wants IP for 1 st approx: client queries root server to find com DNS server client queries.com DNS server to get amazon.com DNS server client queries amazon.com DNS server to get IP address for Application Layer 2-51

52 Local DNS name server does not strictly belong to hierarchy each ISP (residential ISP, company, university) has one also called default name server when host makes DNS query, query is sent to its local DNS server has local cache of recent name-to-address translation pairs (but may be out of date!) acts as proxy, forwards query into hierarchy Application Layer 2-52

53 DNS name resolution example root DNS server host at cis.poly.edu wants IP address for gaia.cs.umass.edu TLD DNS server iterated query: contacted server replies with name of server to contact I don t know this name, but ask this server local DNS server dns.poly.edu 1 8 requesting host cis.poly.edu 7 6 authoritative DNS server dns.cs.umass.edu gaia.cs.umass.edu Application Layer 2-53

54 DNS name resolution example root DNS server recursive query: puts burden of name resolution on contacted name server 2 local DNS server dns.poly.edu TLD DNS server 1 8 requesting host cis.poly.edu authoritative DNS server dns.cs.umass.edu gaia.cs.umass.edu Application Layer 2-54

55 DNS: caching, updating records once (any) name server learns mapping, it caches mapping cache entries timeout (disappear) after some time (TTL) TLD servers typically cached in local name servers thus root name servers not often visited cached entries may be out-of-date (best effort name-to-address translation!) if name host changes IP address, may not be known Internet-wide until all TTLs expire update/notify mechanisms proposed IETF standard RFC 2136 Application Layer 2-55

56 DNS records DNS: distributed db storing resource records (RR) RR format: (name, value, type, ttl) type=a name is hostname value is IP address type=ns name is domain (e.g., foo.com) value is hostname of authoritative name server for this domain type=cname name is alias name for some canonical (the real) name is really servereast.backup2.ibm.com value is canonical name type=mx value is name of mailserver associated with name Application Layer 2-56

57 Inserting records into DNS example: new startup Network Utopia register name networkuptopia.com at DNS registrar (e.g., Network Solutions) provide names, IP addresses of authoritative name server (primary and secondary) registrar inserts two RRs into.com TLD server: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, , A) create authoritative server type A record for type MX record for networkutopia.com Application Layer 2-57

58 Chapter 3 outline 3.1 transport-layer services 3.2 multiplexing and demultiplexing 3.3 connectionless transport: UDP 3.4 principles of reliable data transfer 3.5 connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 principles of congestion control 3.7 TCP congestion control Transport Layer 3-58

59 Transport services and protocols provide logical communication between app processes running on different hosts transport protocols run in end systems send side: breaks app messages into segments, passes to network layer rcv side: reassembles segments into messages, passes to app layer more than one transport protocol available to apps Internet: TCP and UDP application transport network data link physical application transport network data link physical Transport Layer 3-59

60 Transport vs. network layer network layer: logical communication between hosts transport layer: logical communication between processes relies on, enhances, network layer services 12 kids in Ann s house sending letters to 12 kids in Bill s house: hosts = houses processes = kids app messages = letters in household analogy: envelopes transport protocol = Ann and Bill who demux to inhouse siblings network-layer protocol = postal service Transport Layer 3-60

61 Internet transport-layer protocols reliable, in-order delivery (TCP) congestion control flow control connection setup unreliable, unordered delivery: UDP no-frills extension of best-effort IP services not available: delay guarantees bandwidth guarantees application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical application transport network data link physical Transport Layer 3-61

62 Multiplexing/demultiplexing multiplexing at sender: handle data from multiple sockets, add transport header (later used for demultiplexing) demultiplexing at receiver: use header info to deliver received segments to correct socket application P3 transport network link application P1 P2 transport network link physical application P4 transport network link socket process physical physical Transport Layer 3-62

63 Connectionless demultiplexing recall: created socket has host-local port #: DatagramSocket mysocket1 = new DatagramSocket(12534); recall: when creating datagram to send into UDP socket, must specify destination IP address destination port # when host receives UDP segment: checks destination port # in segment directs UDP segment to socket with that port # IP datagrams with same dest. port #, but different source IP addresses and/or source port numbers will be directed to same socket at dest Transport Layer 3-63

64 Connection-oriented demux TCP socket identified by 4-tuple: source IP address source port number dest IP address dest port number demux: receiver uses all four values to direct segment to appropriate socket server host may support many simultaneous TCP sockets: each socket identified by its own 4-tuple web servers have different sockets for each connecting client non-persistent HTTP will have different socket for each request Transport Layer 3-64

65 UDP: User Datagram Protocol [RFC 768] no frills, bare bones Internet transport protocol best effort service, UDP segments may be: lost delivered out-of-order to app connectionless: no handshaking between UDP sender, receiver each UDP segment handled independently of others UDP use: streaming multimedia apps (loss tolerant, rate sensitive) DNS SNMP reliable transfer over UDP: add reliability at application layer application-specific error recovery! Transport Layer 3-65

66 UDP: segment header 32 bits source port # dest port # length application data (payload) checksum UDP segment format length, in bytes of UDP segment, including header why is there a UDP? no connection establishment (which can add delay) simple: no connection state at sender, receiver small header size no congestion control: UDP can blast away as fast as desired Transport Layer 3-66

67 UDP checksum Goal: detect errors (e.g., flipped bits) in transmitted segment sender: treat segment contents, including header fields, as sequence of 16-bit integers checksum: addition (one s complement sum) of segment contents sender puts checksum value into UDP 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? More later. Transport Layer 3-67

68 Internet checksum: example example: add two 16-bit integers wraparound sum checksum Note: when adding numbers, a carryout from the most significant bit needs to be added to the result Transport Layer 3-68

69 Principles of reliable data transfer important in application, transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Transport Layer 3-69

70 rdt1.0: reliable transfer over a reliable channel underlying channel perfectly reliable no bit errors no loss of packets separate FSMs for sender, receiver: sender sends data into underlying channel receiver reads data from underlying channel Wait for call from above rdt_send(data) packet = make_pkt(data) udt_send(packet) Wait for call from below rdt_rcv(packet) extract (packet,data) deliver_data(data) sender receiver Transport Layer 3-70

71 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 feedback: control msgs (ACK,NAK) from receiver to sender Transport Layer 3-71

72 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: stop and wait sender sends one packet, then waits for receiver response sender retransmits current pkt if ACK/NAK corrupted sender adds sequence number to each pkt receiver discards (doesn t deliver up) duplicate pkt Transport Layer 3-72

73 rdt2.1: sender, handles garbled ACK/NAKs rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isnak(rcvpkt) ) udt_send(sndpkt) rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) Wait for call 0 from above Wait for ACK or NAK 1 rdt_send(data) Wait for ACK or NAK 0 Wait for call 1 from above rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isnak(rcvpkt) ) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) Transport Layer 3-73

74 rdt2.1: receiver, handles garbled ACK/NAKs rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) Wait for 0 from below Wait for 1 from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) Transport Layer 3-74

75 rdt3.0: channels with errors and loss new assumption: underlying channel can also lose packets (data, 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 seq. # s already handles this receiver must specify seq # of pkt being ACKed requires countdown timer Transport Layer 3-75

76 rdt3.0 sender rdt_rcv(rcvpkt) Wait for call 0from above rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,1) stop_timer timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,0) ) Wait for ACK1 rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer Wait for ACK0 Wait for call 1 from above rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,1) ) timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0) stop_timer rdt_rcv(rcvpkt) Transport Layer 3-76