1. 1 Ch. 7 : Internet Transport Protocols

2. Transport Layer Our goals: r understand principles behind transport layer services: m Multiplexing / demultiplexing data streams of several applications m reliable data transfer m flow control m congestion control Chapter 6: r rdt principles Chapter 7: r multiplex/ demultiplex r Internet transport layer protocols: m UDP: connectionless transport m TCP: connection-oriented transport connection setup data transfer flow control congestion control 22

3. Transport vs. network layer r Transport layer uses Network layer services m adds more value to these services Transport LayerNetwork Layer logical communication between processes logical communication between hosts exists only in hosts exists in hosts and in routers ignores network routes data through network Port #s used for routing in destination computer IP addresses used for routing in network 3

4. 4 Multiplexing & Demultiplexing

5. Multiplexing/demultiplexing application transport network link physical P1 application transport network link physical application transport network link physical P2P3P4P1 host 1 host 2 host 3 = process= socket receive segment from L3 deliver each received segment to correct socket Demultiplexing at rcv host: gather data from multiple sockets, envelop data with headers (later used for demultiplexing), pass to L3 Multiplexing at send host: 5

6. How demultiplexing works r host receives IP datagrams m each datagram has source IP address, destination IP address in its header m each datagram carries one transport-layer segment m each segment has source, destination port number in its header r host uses port numbers, and sometimes also IP addresses to direct segment to correct socket m from socket data gets to the relevant application process source port #dest port # 32 bits application data (message) other header fields TCP/UDP segment format L4 header appl. msg L3 hdr other IP header fields source IP addrdest IP addr. 6

7. Connectionless demultiplexing (UDP) r Processes create sockets with port numbers r a UDP socket is identified by a pair of numbers: ( my IP address, my port number ) r Client decides to contact: m a server (  peer IP-address) + m an application (  peer port #) r Client puts those into the UDP packet he sends; they are written as: m dest IP address - i n the IP header of the packet m dest port number - in its UDP header r When server receives a UDP segment: m checks destination port number in segment m directs UDP segment to the socket with that port number (packets from different remote sockets directed to same socket) m the UDP message waits in socket queue and is processed in its turn. m answer message sent to the client UDP socket (listed in Source fields of query packet) 7

8. Client IP:B SP: 53 DP: 5775 S-IP: C D-IP: B SP = Source port number DP= Destination port number S-IP= Source IP Address D-IP=Destination IP Address Connectionless demux (cont) client IP: A P1 server IP: C SP and S-IP provide “return address” P2 client socket: port=9157, IP=A P3 server socket: port=53, IP = C message SP: 9157 DP: 53 S-IP: A D-IP: C IP-Header UDP-Header SP: 53 DP: 9157 S-IP: C D-IP: A SP: 5775 DP: 53 S-IP: B D-IP: C message client socket: port=5775, IP=B message Wait for application Getting Service Reply Getting Service Reply L1 L2 L4 L5 L3 8

9. Connection-oriented demux (TCP) r TCP socket identified by 4-tuple: m local (my) IP address m local (my) port number m remote IP address m remote port number r receiving host uses all four values to direct segment to appropriate socket r Server host may support many simultaneous TCP sockets: m each socket identified by its own 4-tuple r Web servers have a different socket for each connecting client m If you open two browser windows, you generate 2 sockets at each end m non-persistent HTTP will open a different socket for each request 9

10. Connection-oriented demux (cont) Client IP: B client IP: A P1 server IP: C P3 client socket: LP= 9157, L-IP= A RP= 80, R-IP= C P1 LP= Local Port, RP= Remote Port L-IP= Local IP, R-IP= Remote IP P4 server socket: LP= 80, L-IP= C RP= 9157, R-IP= A P6 server socket: LP= 80, L-IP= C RP= 5775, R-IP= B “L”= Local = My “R”= Remote = Peer P2 client socket: LP= 5775, L-IP= B RP= 80, R-IP= C client socket: LP= 9157, L-IP= B RP= 80, R-IP= C P5 server socket: LP= 80, L-IP= C RP= 9157, R-IP= B H3 H4 SP: 9157 DP: 80 S-IP: A D-IP: C packet: message SP: 5775 DP: 80 D-IP: C S-IP: B packet: message SP: 9157 DP: 80 packet: D-IP: C S-IP: B message L1 L2 L4 L5 L3 10

11. 11 UDP Protocol

12. UDP: User Datagram Protocol [RFC 768] r simple transport protocol r “best effort” service, UDP segments may be: m lost m delivered out of order to application with no correction by UDP r UDP will discard bad checksum segments if so configured by application r connectionless: m no handshaking between UDP sender, receiver m each UDP segment handled independently of others Why is there a UDP? r no connection establishment m saves delay r no congestion control: m better delay & BW r simple: r small segment header r typical usage: realtime appl. m loss tolerant m rate sensitive r other uses (why?): m DNS m SNMP 12

13. UDP segment structure source port # dest port # 32 bits application data (variable length) length Total length of segment (bytes) Checksum computed over: the whole segment part of IP header: – both IP addresses – protocol field – total IP packet length checksum Checksum usage: computed at destination to detect errors in case of error, UDP will discard the segment, or 13

14. 14 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: m NO - error detected m YES - no error detected. Goal: detect “errors” (e.g., flipped bits) in transmitted segment

15. 15 TCP Protocol

16. 16 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 r full duplex data: m bi-directional data flow in same connection m MSS: maximum segment size r connection-oriented: m handshaking (exchange of control msgs) init’s sender, receiver state before data exchange r flow controlled: m sender will not overwhelm receiver r point-to-point: m one sender, one receiver m between sockets r reliable, in-order byte steam: m no “message boundaries” r pipelined: m TCP congestion and flow control set window size r send & receive buffers

17. 17 TCP segment structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number rcvr window size ptr urgent data checksum F SR PAU head len not used Options (variable length) URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) # bytes rcvr willing to accept counting by bytes of data (not segments!) Internet checksum (as in UDP) hdr length in 32 bit words

18. TCP sequence # (SN) and ACK (AN) SN: m byte stream “number” of first byte in segment’s data AN: m SN of next byte expected from other side m cumulative ACK Qn: how receiver handles out-of-order segments? m puts them in receive buffer but does not acknowledge them Host A Host B time SN=42, AN=79, 100 data bytes SN=79, AN=142, 50 data bytes SN=142, AN=129, no data host A sends 100 data bytes host ACKs receipt of data, sends no data WHY? host B ACKs 100 bytes and sends 50 data bytes simple data transfer scenario (some time after conn. setup) 18

19. 19 Connection Management: Objective r Agree on initial sequence numbers m a sender should not reuse a seq# before it is sure that all packets with the seq# are purged from the network the network guarantees that a packet too old will be purged from the network: network bounds the life time of each packet m To avoid waiting for seq #s to disappear, start new session with a seq# far away from previous needs connection setup so that the sender tells the receiver initial seq# r Agree on other initial parameters

20. TCP Connection Management Setup: establish connection between the hosts before exchanging data segments r called: 3 way handshake r initialize TCP variables: m seq. #s  buffers, flow control info (e.g. RcvWindow ) r client : connection initiator m opens socket and cmds OS to connect it to server r server : contacted by client m has waiting socket m accepts connection m generates working socket Teardown: end of connection (we skip the details) Three way handshake: Step 1: client host sends TCP SYN segment to server m specifies initial seq # m no data Step 2: server host receives SYN, replies with SYNACK segment (also no data) m allocates buffers m specifies server initial SN & window size Step 3: client receives SYNACK, replies with ACK segment, which may contain data 20

21. TCP Three-Way Handshake (TWH) A Send Buffer Receive Buffer Send Buffer Receive Buffer SYN, SN = X SYNACK, SN = Y, AN = X+1 ACK, SN = X+1, AN = Y+1 X+1 Y+1 B 21

22. 22 Connection Close r Objective of closure handshake: m each side can release resource and remove state about the connection Close the socket client I am done. Are you done too? server I am done too. Goodbye! initial close : close release resource? release resource release resource