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

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

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

4. Chapter 3, slide: 4 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  segment structure  reliable data transfer  flow control  connection management r 6 Principles of congestion control r 7 TCP congestion control

5. Chapter 3, slide: 5 Transport services and protocols r provide logical communication between app processes running on different hosts r 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 r more than one transport protocol available to apps  Internet: TCP and UDP application transport network data link physical application transport network data link physical logical end-end transport

6. Chapter 3, slide: 6 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 = network- layer protocol

7. Chapter 3, slide: 7 Internet transport-layer protocols r reliable, in-order delivery (TCP)  congestion control  flow control  connection setup r unreliable, unordered delivery: UDP  no-frills extension of “best-effort” IP r 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 application transport network data link physical logical end-end transport

8. Chapter 3, slide: 8 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  segment structure  reliable data transfer  flow control  connection management r 6 Principles of congestion control r 7 TCP congestion control

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

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

11. Chapter 3, slide: 11 Connectionless demultiplexing r UDP socket identified by two-tuple: ( dest IP address, dest port number) r When host receives UDP segment:  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!

12. Chapter 3, slide: 12 Connectionless demux (cont) DatagramSocket serverSocket = new DatagramSocket(6428); Client IP:B P2 client IP: A P1 P3 server IP: C SP: 6428 DP: 9157 SP: 9157 DP: 6428 SP: 6428 DP: 5775 SP: 5775 DP: 6428 SP provides “return address”

13. Chapter 3, slide: 13 Connection-oriented demux r TCP socket identified by 4-tuple:  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:  each socket identified by its own 4-tuple r Web servers have different sockets for each connecting client  non-persistent HTTP will have different socket for each request

14. Chapter 3, slide: 14 Connection-oriented demux (cont) Client IP:B P1 client IP: A P1P2P4 server IP: C SP: 9157 DP: 80 SP: 9157 DP: 80 P5P6P3 D-IP:C S-IP: A D-IP:C S-IP: B SP: 5775 DP: 80 D-IP:C S-IP: B

15. Chapter 3, slide: 15 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  segment structure  reliable data transfer  flow control  connection management r 6 Principles of congestion control r 7 TCP congestion control

16. Chapter 3, slide: 16 UDP: User Datagram Protocol [RFC 768] r “best effort” service, UDP segments may be:  lost  delivered out of order to app r connectionless:  no handshaking between UDP sender, receiver  each UDP segment handled independently of others 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

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

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

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

20. Selecting logical port numbers r Communicating computers must agree on a port number  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.

21. Some "well-known" logical port numbers PortNameDescription 7echoEcho input back to sender 11systatSystem statistics 13daytimeTime of day (ASCII) 17quoteQuote of the day 20,21ftpFile Transfer Protocol 22sshSecure Shell remote login 23telnetTelnet 37timeSystem time (seconds since 1970) 53domainDomain Name Service (DNS) 80web, httpWorld Wide Web (HTTP) 123ntpNetwork Time Protocol (NTP) 161snmpSimple Network Management Protocol (SNMP)

22. Chapter 3, slide: 22 Review questions Question 1: r Host C has UDP socket with port number 6789 r Both Hosts A & B send UDP segment with destination Port 6789 1. Would both be directed to same socket at Host C? 2. If so, how would Host C know that these 2 are originated from two different hosts? Answer: 1. Yes 2. 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)

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

24. Chapter 3, slide: 24 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  segment structure  reliable data transfer  flow control  connection management r 6 Principles of congestion control r 7 TCP congestion control

25. 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)

26. 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)

27. Chapter 3, slide: 27 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)

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

29. Chapter 3, slide: 29 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  but control info will flow on both directions! r use finite state machines (FSM) to specify sender, receiver state 1 state 2 event causing state transition actions taken on state transition state: when in this “state” next state uniquely determined by next event event actions

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

31. Chapter 3, slide: 31 rdt2.0: channel with bit errors r underlying channel may flip bits in packet  Receiver can detect bit errors (e.g., use checksum)  But still no packet loss r questions: (1) how to know and (2) what to do when packet is erroneous:  acknowledgements: positive ack (ACK): receiver tells sender that pkt received OK negative ack (NAK): receiver tells sender that pkt had erros  retransmission: 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  assume ACK/NAK are error free

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

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

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