Transport Layer

1. Transport Layer By Ossi Mokryn, Based also on slides from: the Computer Networking: A Top Down Approach Featuring the Internet by Kurose and Ross

2. Transport Layer • Connectionless and connection oriented communication • Sockets programming • UDP • TCP • Reliable communication • Flow control • Congestion control • Timers

3. 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 logical end-end transport Transport services and protocols

4. 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 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 logical end-end transport Internet transport-layer protocols

5. network layer: logical communication between hosts transport layer: logical communication between processes relies on, enhances, network layer services Household analogy: 12 kids sending letters to 12 kids processes = kids app messages = letters in envelopes hosts = houses transport protocol = Ann and Bill network-layer protocol = postal service Transport vs. network layer

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

7. 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 host uses IP addresses & port numbers to direct segment to appropriate socket How demultiplexing works 32 bits source port # dest port # other header fields application data (message) TCP/UDP segment format

8. Create sockets with port numbers: UDP socket identified by two-tuple: (dest IP address, dest port number) When host receives UDP segment: checks destination port number in segment directs UDP segment to socket with that port number IP datagrams with different source IP addresses and/or source port numbers directed to same socket Connectionless demultiplexing

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

10. Simplest Internet transport protocol Each app. Output produces exactly one UDP segment “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 Why is there a UDP? no connection establishment (which can add delay) simple: no connection state at sender, receiver small segment header no congestion control: UDP can blast away as fast as desired UDP: User Datagram Protocol [RFC 768]

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

12. Sender: treat segment contents as sequence of 16-bit integers checksum: addition (1’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 …. UDP checksum Goal: detect “errors” (e.g., flipped bits) in transmitted segment

13. Internet Checksum Example • Note • When adding numbers, a carryout from the most significant bit needs to be added to the result • Example: add two 16-bit integers 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

14. Sockets Programming over UDP – use socket slides now.

15. Transmission Control Protocol Principles of reliable communication TCP basic notations, 3 way handshake TCP flow control, congestion control

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

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

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

19. Reliable Data Transfer: Stream stream jargon Application Layer A stream is a sequence of characters that flow into or out of a process. An input stream is attached to some input source for the process, eg, keyboard or socket. An output stream is attached to an output source, eg, monitor or socket.

20. event state 1 state 2 actions Reliable Communication Terminology of a State Machine event causing state transition actions taken on state transition

21. stop and wait Reliable communication First Model: sender sends, receiver receives. • Is this enough? • When will it work? • When will it not work? Sender sends one packet, then waits for receiver response

22. State 1 state 2 Reliable Communication Stop and Wait – Sender side Wait for data Data available Wait for ack Send Data In State 1 Sender can send data In State 2 Sender can receive acknowledge packets Received Ack • Discussion: • Why to send back an ack msg? • What happens if data is available at state 2?

23. underlying channel may flip bits in packet checksum to detect bit errors underlying channel can also lose packets the question: how to recover from errors: acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK timeout: sender retransmits pkt if doesn’t receive ack within timeout new mechanisms in: error detection receiver feedback: control msg (ACK) rcvr->sender sender control: timer to understand if to send again. channel with bit errors and losses

24. State 1 state 2.a state 2.b Reliable Communication Stop and Wait with errors/losses - sender Wait for data Data available Wait for ack packet or time out Send Data In State 1 Receiver waits for data Ack received Process ack Send Data timeout • Discussion: • What does the sender need to do for the retransmission?

25. What happens if ACK corrupted/lost? sender doesn’t know what happened at receiver! can’t just retransmit: possible duplicate Handling duplicates: sender retransmits current pkt if ACK garbled or didn’t arrive sender adds sequence number to each pkt receiver discards (doesn’t deliver up) duplicate pkt receiver must specify seq # of pkt being ACKed This version has a fatal flaw!

26. Sender: seq # added to pkt two seq. #’s (0,1) will suffice. Why? must check if received ACK corrupted twice as many states state must “remember” whether “current” pkt has 0 or 1 seq. # Receiver: must check if received packet is duplicate state indicates whether 0 or 1 is expected pkt seq # receiver sends ACK for last pkt received OK receiver must explicitly include seq # of pkt being ACKed note: receiver can not know if its last ACK received OK at sender discussion

27. Stop & wait in action

28. Stop & wait in action

29. Stop & wait works, but performance stinks ex: 1 Gbps link, 15 ms prop. delay, 8000 bit packet: Performance of stop & wait • U sender: utilization – fraction of time sender busy sending • 1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link • network protocol limits use of physical resources!

30. stop-and-wait operation sender receiver first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R first packet bit arrives RTT last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R

31. Pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pkts range of sequence numbers must be increased buffering at sender and/or receiver Two generic forms of pipelined protocols: go-Back-N, selective repeat Pipelined protocols

32. Pipelining: increased utilization sender receiver first packet bit transmitted, t = 0 last bit transmitted, t = L / R first packet bit arrives RTT last packet bit arrives, send ACK last bit of 2nd packet arrives, send ACK last bit of 3rd packet arrives, send ACK ACK arrives, send next packet, t = RTT + L / R Increase utilization by a factor of 3!

33. Pipelining Protocol Go-back-N: big picture: • Sender can have up to N unacked packets in pipeline • Rcvr only sends cumulative acks • Doesn’t ack packet if there’s a gap • Sender has timer for oldest unacked packet • If timer expires, retransmit all unacked packets

34. Sender: k-bit seq # in pkt header “window” of up to N, consecutive unack’edpkts allowed Go-Back-N • ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” • may receive duplicate ACKs (see receiver) • timer for each in-flight pkt • timeout(n): retransmit pkt n and all higher seq # pkts in window Transport Layer

35. Go Back N Receiver: • ACK-only: always send ACK for correctly-received pkt with highest in-orderseq # • may generate duplicate ACKs • need only remember expectedseqnum • out-of-order pkt: • discard (don’t buffer) -> no receiver buffering! • Re-ACK pkt with highest in-order seq #

36. GBN inaction Transport Layer

37. Enhanced GBN protocol Segment structure reliable data transfer and data transfer issues flow control connection management TCP congestion control Transport Control Protocol

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

39. 32 bits source port # dest port # sequence number acknowledgement number head len not used Receive window U A P R S F checksum Urg data pnter Options (variable length) application data (variable length) TCP segment structure URG: urgent data (generally not used) counting by bytes of data (not segments!) ACK: ACK # valid PSH: push data now (generally not used) # bytes rcvr willing to accept RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP)

40. TCP creates reliable service on top of IP’s unreliable service Pipelined segments Cumulative acks TCP uses single retransmission timer The sequence number for a segment is the first byte-stream # of the first byte in the segment. TCP reliable data transfer

41. data rcvd from app: Create segment with seq # start timer if not already running (think of timer as for oldest unacked segment) expiration interval: TimeOutInterval timeout: retransmit segment that caused timeout restart timer Ack rcvd: If acknowledges previously unacked segments update what is known to be acked start timer if there are outstanding segments TCP sender events:

42. Seq. #’s: byte stream “number” of first byte in segment’s data ACKs: seq # of next byte expected from other side cumulative ACK Q: how receiver handles out-of-order segments A: TCP spec doesn’t say, - up to implementor time TCP seq. #’s and ACKs Host B Host A User types ‘C’ Seq=42, ACK=79, data = ‘C’ host ACKs receipt of ‘C’ Seq=79, ACK=43 host receivesACK

43. Host A Host B Seq=92, 8 bytes data ACK=100 Seq=92 timeout timeout X loss Seq=92, 8 bytes data ACK=100 time time lost ACK scenario TCP: retransmission scenarios Host A Host B Seq=92, 8 bytes data Seq=100, 20 bytes data ACK=100 ACK=120 Seq=92, 8 bytes data Sendbase = 100 SendBase = 120 ACK=120 Seq=92 timeout SendBase = 100 SendBase = 120 premature timeout

44. Host A Host B Seq=92, 8 bytes data ACK=100 Seq=100, 20 bytes data timeout X loss ACK=120 time Cumulative ACK scenario TCP retransmission scenarios (more) SendBase = 120

45. Overhead for each packet: 40 bytes (20 TCP header + 20 IP header) to a total of 160 bytes for sending and receiving ‘C’. If the receiver waits a while, it can piggyback the data packet Delayed ack: Wait up to 500ms for next segment. If no next segment, send ACK. Should sender use delayed acks too?[Stevens figure 19.3] time Interactive data flow Host B Host A User types ‘C’ Seq=42, ACK=79, data = ‘C’ host ACKs receipt of ‘C’, Seq=79, ACK=43 Host echoes back ‘C’ Seq=79, ACK=43, data = ‘C’ host ACKs receipt of echoed ‘C’ Seq=43, ACK=80 simple telnet scenario

46. Nagle Algorithm[RFC 896] Nagle’s alg: • Quantifying overhead: how much control bytes per data bytes? with piggyback 2/120-> only 1.6% of the bits sent are data. • LANs usually not congested so it might be okay. • Small packets, termed tinygrams over congested WAN – bad news. • New data can’t be sent until outstanding data is acked. • Small amounts of data are collected and sent in a single segment when ack arrives. • Self clocking: the faster the ack comes back, the faster data is sent. Slow links cause fewer segments to be sent. • [Stevens 19.4]

47. TCP ACK generation[RFC 1122, RFC 2581] TCP Receiver action Delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK Immediately send single cumulative ACK, ACKing both in-order segments Immediately send duplicate ACK, indicating seq. # of next expected byte Immediate send ACK, provided that segment starts at lower end of gap Event at Receiver Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed Arrival of in-order segment with expected seq #. One other segment has ACK pending Arrival of out-of-order segment higher-than-expect seq. # . Gap detected Arrival of segment that partially or completely fills gap

48. Time-out period often relatively long: long delay before resending lost packet Detect lost segments via duplicate ACKs. Sender often sends many segments back-to-back If segment is lost, there will likely be many duplicate ACKs. If sender receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost: fast retransmit:resend segment before timer expires Fast Retransmit

49. Host A Host B X timeout resend 2nd segment time Figure 3.37 Resending a segment after triple duplicate ACK

50. Fast retransmit algorithm: event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y } a duplicate ACK for already ACKed segment fast retransmit