CS 372 introduction to computer networks Tuesday

CS 372 – introduction to computer networks* Tuesday July 6 Announcements: r Lab 2 is due today * Based in part on slides by Bechir Hamdaoui and Paul D. Paulson. Acknowledgement: slides drawn heavily from Kurose & Ross Chapter 3, slide: 1

Chapter 2: Recap By now, you should know: r application architectures v client-server v P 2 P r application service requirements: v reliability, bandwidth, delay r Transport service model v connection-oriented, reliable: TCP v unreliable, datagrams: UDP Important concepts: r centralized vs. decentralized r stateless vs. stateful r reliable vs. unreliable msg transfer Chapter 3, slide: 2

Chapter 3: Transport Layer Our goals: r understand principles behind transport layer services: multiplexing/demu ltiplexing v reliable data transfer v flow control v congestion control v r learn about transport layer protocols in the Internet: UDP: connectionless transport v TCP: connectionoriented transport v TCP congestion control v Chapter 3, slide: 3

Chapter 3 outline r 1 Transport-layer services r 2 Multiplexing and demultiplexing r 3 Connectionless transport: UDP r 4 Principles of reliable data transfer r 5 Connection-oriented transport: TCP v v segment structure reliable data transfer flow control connection management r 6 Principles of congestion control r 7 TCP congestion control Chapter 3, slide: 4

Transport services and protocols r provide logical communication al ic g lo d en d- en po s an tr rt between app processes running on different hosts r transport protocols run in end systems v send side: breaks app messages into segments, passes to network layer v rcv side: reassembles segments into messages, passes to app layer r more than one transport protocol available to apps v Internet: TCP and UDP application transport network data link physical Chapter 3, slide: 5

Transport vs. network layer r network layer: logical communication between hosts r transport layer: logical communication between processes Household case: r 12 kids (East coast house) sending letters to 12 kids (West coast house) r Ann is responsible for the house at East coast r Bill is responsible for the house at West coast r Postal service is responsible for between houses Household analogy: r kids = processes r letters = messages r houses = hosts r home address = IP address r kid names = port numbers r Ann and Bill = transport protocol r postal service = networklayer protocol Chapter 3, slide: 6

Internet transport-layer protocols r reliable, in-order delivery (TCP) v no-frills extension of “best-effort” IP r services not available: v delay guarantees v bandwidth guarantees network data link physical t or delivery: UDP network data link physical network sp an tr r unreliable, unordered network data link physical nd -e nd v network data link physical e al v congestion control flow control connection setup c gi lo v application transport network data link physical Chapter 3, slide: 7

Chapter 3 outline r 1 Transport-layer services r 2 Multiplexing and demultiplexing r 3 Connectionless transport: UDP r 4 Principles of reliable data transfer r 5 Connection-oriented transport: TCP v v segment structure reliable data transfer flow control connection management r 6 Principles of congestion control r 7 TCP congestion control Chapter 3, slide: 8

Multiplexing/demultiplexing Multiplexing at send host: gathering data from multiple sockets, enveloping data with header (later used for demultiplexing) Demultiplexing at rcv host: delivering received segments to correct socket = socket application transport network link = process P 3 P 1 application transport network P 2 P 4 application transport network link physical host 1 physical host 2 physical host 3 Chapter 3, slide: 9

How demultiplexing works r host receives IP datagrams each datagram has source IP address, destination IP address v each datagram carries 1 transport-layer segment v each segment has source, destination port number r host uses IP addresses & port numbers to direct segment to appropriate socket v 32 bits source port # dest port # other header fields application data (message) TCP/UDP segment format Chapter 3, slide: 10

Connectionless demultiplexing r UDP socket identified by two-tuple: (dest IP address, dest port number) r When host receives UDP segment: v v checks destination port number in segment directs UDP segment to socket with that port number r IP datagrams with different source IP addresses and/or source port numbers directed to same socket r Demultiplexing in UDP is based on destination only! Chapter 3, slide: 11

Connectionless demux (cont) Datagram. Socket server. Socket = new Datagram. Socket(6428); P 2 SP: 6428 DP: 9157 SP: 6428 DP: 5775 SP: 9157 client IP: A P 1 P 3 DP: 6428 server IP: C SP: 5775 DP: 6428 Client IP: B SP provides “return address” Chapter 3, slide: 12

Connection-oriented demux r TCP socket identified by 4 -tuple: v v source IP address source port number dest IP address dest port number r recv host uses all four values to direct segment to appropriate socket r Server host may support many simultaneous TCP sockets: v each socket identified by its own 4 -tuple r Web servers have different sockets for each connecting client v non-persistent HTTP will have different socket for each request Chapter 3, slide: 13

Connection-oriented demux (cont) P 1 P 4 P 5 P 2 P 6 P 1 P 3 SP: 5775 DP: 80 S-IP: B D-IP: C client IP: A SP: 9157 DP: 80 S-IP: A D-IP: C SP: 9157 server IP: C DP: 80 S-IP: B D-IP: C Client IP: B Chapter 3, slide: 14

Chapter 3 outline r 1 Transport-layer services r 2 Multiplexing and demultiplexing r 3 Connectionless transport: UDP r 4 Principles of reliable data transfer r 5 Connection-oriented transport: TCP v v segment structure reliable data transfer flow control connection management r 6 Principles of congestion control r 7 TCP congestion control Chapter 3, slide: 15

UDP: User Datagram Protocol r “best effort” service, UDP segments may be: v lost v delivered out of order to app r connectionless: v no handshaking between UDP sender, receiver v each UDP segment handled independently of others [RFC 768] Why is there a UDP? r less delay: no connection establishment (which can add delay) r simple: no connection state at sender, receiver r less traffic: small segment header r no congestion control: UDP can blast away as fast as desired Chapter 3, slide: 16

UDP: more r often used for streaming multimedia apps v loss tolerant v rate sensitive Length, in bytes of UDP segment, including header r other UDP uses v DNS v SNMP r reliable transfer over UDP: add reliability at application layer v application-specific error recovery! 32 bits source port # dest port # length checksum Application data (message) UDP segment format Chapter 3, slide: 17

UDP checksum Goal: detect “errors” (e. g. , flipped bits) in transmitted segment Sender: Receiver: r treat segment contents as r compute checksum of sequence of 16 -bit integers r checksum: addition (1’s complement sum) of segment contents r sender puts checksum value into UDP checksum field received segment r check if computed checksum equals checksum field value: v NO - error detected v YES - no error detected. But maybe errors nonetheless? More later …. Chapter 3, slide: 18

Internet Checksum Example r Note v When adding numbers, a carryout from the most significant bit needs to be added to the result r Example: add two 16 -bit integers 1 1 0 0 1 1 1 0 1 0 1 wraparound 1 1 0 1 1 sum 1 1 0 1 1 0 0 checksum 1 0 0 0 0 1 1 Chapter 3, slide: 19

Selecting logical port numbers r Communicating computers must agree on a port number v v Server opens selected port and waits for incoming messages Client selects local port and sends message to selected server port r Many common services use reserved (well-known) port numbers r Other services use dynamically assigned port numbers r Valid range is [0. . 65535] , but don’t use “well-known” port numbers for special apps.

Some "well-known" logical port numbers Port Name Description 7 echo Echo input back to sender 11 systat System statistics 13 daytime Time of day (ASCII) 17 quote Quote of the day 20, 21 ftp File Transfer Protocol 22 ssh Secure Shell remote login 23 telnet Telnet 37 time System time (seconds since 1970) 53 domain Domain Name Service (DNS) 80 web, http World Wide Web (HTTP) 123 ntp Network Time Protocol (NTP) 161 snmp Simple Network Management Protocol (SNMP)

Review questions Question 1: r r 1. 2. Host C has UDP socket with port number 6789 Both Hosts A & B send UDP segment with destination Port 6789 Would both be directed to same socket at Host C? If so, how would Host C know that these 2 are originated from two different hosts? Answer: 1. 2. Yes IP addresses Question 2: r Same scenario but with TCP instead of UDP Answer: r No! There is a separate TCP socket for each 4 -uplet (IP src, IP dst, src Port, dst Port) Chapter 3, slide: 22

CS 372 – introduction to computer networks* Wednesday July 7 Announcements: r Quiz on Friday, covers chapter 2 * Based in part on slides by Bechir Hamdaoui and Paul D. Paulson. Acknowledgement: slides drawn heavily from Kurose & Ross Chapter 3, slide: 23

Chapter 3 outline r 1 Transport-layer services r 2 Multiplexing and demultiplexing r 3 Connectionless transport: UDP r 4 Principles of reliable data transfer r 5 Connection-oriented transport: TCP v v segment structure reliable data transfer flow control connection management r 6 Principles of congestion control r 7 TCP congestion control Chapter 3, slide: 24

Principles of Reliable data transfer r important in app. , transport, link layers r top-10 list of important networking topics! r characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Chapter 3, slide: 25

Principles of Reliable data transfer r important in app. , transport, link layers r top-10 list of important networking topics! r characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Chapter 3, slide: 26

Principles of Reliable data transfer r important in app. , transport, link layers r top-10 list of important networking topics! r characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Chapter 3, slide: 27

Reliable data transfer: getting started rdt_send(): called from above, (e. g. , by app. ). Passed data to deliver to receiver upper layer send side udt_send(): called by rdt, to transfer packet over unreliable channel to receiver deliver_data(): called by rdt to deliver data to upper receive side rdt_rcv(): called when packet arrives on rcv-side of channel Chapter 3, slide: 28

Reliable data transfer: getting started We will: r incrementally develop sender, receiver sides of reliable data transfer protocol (rdt) r consider only unidirectional data transfer v but control info will flow on both directions! r use finite state machines (FSM) to specify sender, receiver state: when in this “state” next state uniquely determined by next event state 1 event causing state transition actions taken on state transition event actions state 2 Chapter 3, slide: 29

rdt 1. 0: reliable transfer over a reliable channel r underlying channel perfectly reliable v no bit errors v no loss of packets r separate FSMs for sender, receiver: v sender sends data into underlying channel v receiver read data from underlying channel Wait for call from above rdt_send(data) packet = make_pkt(data) udt_send(packet) sender Wait for call from below rdt_rcv(packet) extract (packet, data) deliver_data(data) receiver Chapter 3, slide: 30

rdt 2. 0: channel with bit errors r underlying channel may flip bits in packet v Receiver can detect bit errors (e. g. , use checksum) v But still no packet loss r questions: (1) how to know and (2) what to do when packet is erroneous: v acknowledgements: • positive ack (ACK): receiver tells sender that pkt received OK • negative ack (NAK): receiver tells sender that pkt had erros v retransmission: sender retransmits pkt on receipt of NAK r new mechanisms in rdt 2. 0 (beyond rdt 1. 0): v v v error detection receiver feedback: control msgs (ACK, NAK) rcvr->sender assume ACK/NAK are error free Chapter 3, slide: 31

rdt 2. 0: FSM specification rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && is. NAK(rcvpkt) Wait for call from ACK or udt_send(sndpkt) above NAK rdt_rcv(rcvpkt) && is. ACK(rcvpkt) L sender Note: L means “transition to next state” receiver rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt, data) deliver_data(data) udt_send(ACK) Chapter 3, slide: 32

rdt 2. 0: operation with no errors rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && is. NAK(rcvpkt) Wait for call from ACK or udt_send(sndpkt) above NAK rdt_rcv(rcvpkt) && is. ACK(rcvpkt) L sender receiver rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt, data) deliver_data(data) udt_send(ACK) Chapter 3, slide: 33

rdt 2. 0: error scenario rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && is. NAK(rcvpkt) Wait for call from ACK or udt_send(sndpkt) above NAK rdt_rcv(rcvpkt) && is. ACK(rcvpkt) L rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt, data) deliver_data(data) udt_send(ACK) Chapter 3, slide: 34