1. TO 3-7-06 p. 1 Spring 2006 EE 5304/EETS 7304 Internet Protocols Tom Oh Dept of Electrical Engineering taehwan@engr.smu.edu Lecture 13 Transport Layer

2. TO 3-7-06 p. 2 Administrative Issues  I will pass out the Test #2 next week.  For in-class students, we will have Test #3(Final) on May 9, 2006, 6:30PM.  I will post Homework 4 on our course website tomorrow.

3. TO 3-7-06 p. 3 Outline (Comer, Ch. 25)  Transport layer functions  General considerations  Types of networks  Transport functions for type A network  Transport functions for type B network  Transport functions for type C network

4. TO 3-7-06 p. 4 Transport Layer (TCP/IP View) Transport Internet IP Network/physic al Application Transport IP Application Host Host-to-host protocol to hide details of network from application

5. TO 3-7-06 p. 5 Transport Layer (cont)  Provides host-to-host communication service to application  Applications do not have to worry about details of network  Can often enhance network services (e.g, TCP/IP)  Ensure error recovery if network layer is unreliable  Ensure end-to-end flow control  Ensure multiplexing and demultiplexing sessions onto same connection  Applications can call on transport layer without having to worry about these things

6. TO 3-7-06 p. 6 Transport Layer (cont) Transport Application Transport Application Host Application may see reliable, flow controlled, multiplexed communication transport-layer service Underlying network may be unreliable

7. TO 3-7-06 p. 7 Transport Layer (cont)  Transport layer can be simpler if network is good  TCP/IP is extreme case  IP layer is intentionally simple as possible - best-effort and unreliable  Transport layer (TCP) is complicated

8. TO 3-7-06 p. 8 Connection-Oriented or Connectionless?  Transport layer offers connection-oriented or connectionless service to application?  Commonly connection-oriented, eg, TCP  Requires connection set-up and disconnect phases  Most appropriate if hosts want reliable, flow controlled, sequential transfer of long stream of data  Network layer can be connection-oriented or connectionless  If connectionless, transport layer must do more work to appear connection-oriented (e.g, TCP)

9. TO 3-7-06 p. 9 Transport Layer (cont) Transport Application Transport Application Host Application sees a virtual connection: packets are delivered in sequential order Underlying network may be connectionless or connection- oriented

10. TO 3-7-06 p. 10 Connection-Oriented? (cont)  Some transport layer protocols are connectionless, eg, UDP  Sometimes connection set-up is unjustified, eg, when data is short/bursty or application does not need reliable delivery  Network layer can be connection-oriented or connectionless (but makes practical sense only for connectionless network)

11. TO 3-7-06 p. 11 Quality of Service Needed by Application?  Application may request a desired or minimum QoS  QoS can be characterized by specific parameters, eg:  Connection establishment delay: time to set up a new connection  Connection blocking probability: chance of failing to set up new connection  Throughput: number of data bytes transferred over time  Transit delay: time from packet transmission to delivery

12. TO 3-7-06 p. 12 QoS (cont)  QoS parameters (cont):  Availability: how often service is unavailable  Reliability: percentage of lost or errored messages that are uncorrected by network  Relative priority: priority of connection compared to other connections  Transport layer QoS may be limited by network QoS  Although unreliable network can be made to appear more reliable, transport layer cannot overcome some limitations of the network (bandwidth, delays)

13. TO 3-7-06 p. 13 OSI Types of Network Service  A: reliable packet delivery, rare signaled network failures (that cause reported but uncorrected connection loss or packet loss)  A-1: sequential delivery, arbitrary packet size  A-2: non-sequential delivery, arbitrary packet size (e.g. datagram)  A-3: non-sequential delivery, maximum packet size  B: reliable delivery, rate of signaled failures can be unacceptable, e.g. X.25  C: unreliable delivery (lost/duplicated packets), e.g, IP

14. TO 3-7-06 p. 14 Type A-1 Network Service  Assumes reliable network, sequential packet delivery, arbitrary packet size  Important transport layer functions:  Connection setup/termination  Multiplexing/demultiplexing  Flow control

15. TO 3-7-06 p. 15 Type A-1 Network: Connection Setup  Set-up verifies dest. host is ready, negotiates optional parameters (TPDU size, window size, QoS), and allows allocation of resources (buffer space)  TPDU = transport protocol data unit (transport layer packet)  Simple 2-way handshake for connection set-up is sufficient

16. TO 3-7-06 p. 16 Type A-1 Network: Connection Setup (cont)  Connection request can be initiated by OPEN command from user → send RFC, wait to receive RFC (connection accepted) or CLOSE (connection refused)  If receive RFC → OPEN state (connection established)  If receive RFC (connection request) in LISTEN state → send RFC to accept, enter OPEN state (connection established)  If receive RFC in IDLE state → notify user of connection request, then send RFC and enter OPEN state if user accepts

17. TO 3-7-06 p. 17 Type A-1 Network: Connection Setup (cont)  If both hosts initiate RFC about same time → no confusion  Connection termination works in same way  Initiated by either side, return to IDLE state

18. TO 3-7-06 p. 18 Type 1-A Network: Multiplexing  Multiplexing → multiple applications running on same host can use same transport protocol  Applications are identified by port numbers carried in transport layer packet header  Transport layer can multiplex data from multiple applications (identified by ports) to send via network layer  Can receive data from network layer and demultiplex to appropriate application  Well known ports: TCP 80 = HTTP; UDP 53 = DNS; TCP 25 = SMTP

19. TO 3-7-06 p. 19 Multiplexing (cont) Transport Application Transport Application Host Port 80 Application Port 35 Application Port 26Port 18

20. TO 3-7-06 p. 20 Type 1-A Network: Flow Control  Like data link layer, flow control is to prevent sender host A from overwhelming dest. host B  Dest. host B has options:  Do nothing If receive buffers overflow, data is lost A will time-out and resend → makes congestion worse  Refuse to accept data from network layer Relies on backpressure from flow control in network to slow down A Slow: backpressure may take long time to reach A Coarse control: other connections may be also effected

21. TO 3-7-06 p. 21 Type 1-A Network: Flow Control (cont)  Use sliding window  Need ACKs and sequence numbers for TPDUs  B will withhold ACKs to slow down A (A will not time-out and resend because packet delivery is assumed reliable)  Works well, but may not work well if network is unreliable (A will time-out and resend if ACKs are too slow or lost)  Use credits  Separates ACKs from flow control: can ACK without granting credit & vice versa  Also works well for unreliable networks

22. TO 3-7-06 p. 22 Type A-2 Network Service  Assumes reliable network, non-sequential packet delivery, arbitrary packet size  Non-sequential delivery → TPDU sequence numbers are required for resequencing at dest. host  Already saw sequence numbers are useful for flow control  Transport protocol must keep track of control TPDUs  Possible confusion for flow control

23. TO 3-7-06 p. 23 Type A-2 Network Service (cont)  New credit value might overtake old credit value → sender gets wrong message  Need to sequentially number credit messages to avoid confusion

24. TO 3-7-06 p. 24 Type A-2 Network Service (cont)  Possible confusion in connection set-up  Data packets could arrive before a CONNECTION_ACCEPT Should queue these TPDUs in expectation of a CONNECTION_ACCEPT  Data packets could arrive after a CONNECTION_RELEASE CONNECTION_RELEASE should contain number of last TPDU

25. TO 3-7-06 p. 25 Type A-2 Network Service (cont)

26. TO 3-7-06 p. 26 Type A-3 Network Service  Assumes reliable network, non-sequential packet delivery, limited packet size  Transport service is stream oriented (user data is treated as continuous) or block oriented  If block oriented, blocks are segmented into TPDUs and reassembled  Maybe number the blocks & number TPDUs within each block, but TPDUs have sequence numbers Only need End of Block flag

27. TO 3-7-06 p. 27 Type B Network Service  Assumes reliable network, maybe non-sequential packet delivery, network failures are possible  TPDUs can be lost but reported to transport entities  Transport entity must handle known lost data and/or lost connection

28. TO 3-7-06 p. 28 Type B Network Service (cont)  In connection reset (eg, X.25 RESET), maybe some TPDUs will be lost  Transport entity sends control TPDU to other end to ACK reset condition and gives number of last received TPDU  Wait to send new TPDUs until receive corresponding reset control TPDU from other end  If network connection is lost without reset (eg, X.25 RESTART), new connection must be requested  Transport entity sends control TPDU to other end to identify new network connection

29. TO 3-7-06 p. 29 Type C Network Service  Assumes unreliable network, non-sequential packet delivery, eg, IP  Transport layer functions:  Retransmission  Duplicate detection  Flow control  Connection setup/clear  Crash recovery

30. TO 3-7-06 p. 30 Type C Network - Retransmission Strategy  TPDUs can be lost or errored  Requires ACKs to sender  Sender has timers and timeouts to resend  If timeout too short → unnecessary retransmissions  If timeout too long → slow to respond to lost TPDU  Should be somewhat longer than (variable) roundtrip delay  Fixed timeouts cannot adapt  Adaptive timeout: no known best solutions (although used in TCP)

31. TO 3-7-06 p. 31 Type C Network - Duplicate Detection  No confusion for lost TPDUs that are retransmitted  But if ACK lost, receiver might get duplicate TPDUs  If a duplicate TPDU arrives before connection close,  Receiver assumes ACK was lost & it ACKs duplicate  Sender should not be confused by multiple ACKs for same TPDU  Range of sequence numbers should be large enough not to repeat (wrap around) during connection

32. TO 3-7-06 p. 32 Type C Network - Duplicate Detection (cont)  If a duplicate TPDU arrives after connection close,  TPDU from old connection could arrive during new connection and be mistaken for new TPDU  Could use continuous sequence numbers, transport connection ID,...  RFCs contain initial sequence number

33. TO 3-7-06 p. 33 Type C Network - Duplicate Detection (cont)

34. TO 3-7-06 p. 34 Type C Network - Flow Control  Credits work well  Eg, (ACK N, CREDIT M) acks all TPDUs up to N and grants credit for TPDUs N+1 through N+M  If ACK is lost, future ACKs will resync. protocol  Sender will timeout and resend, and generate new ACK  But (ACK N, CREDIT 0) can close window, if next (ACK N, CREDIT M) is lost → deadlock  Window timer is reset with each ACK  If timeout, entity must send ACK even if duplicates earlier ACK

35. TO 3-7-06 p. 35 Type C Network - Flow Control (cont)

36. TO 3-7-06 p. 36 Type C Network - Connection Setup  RFCs (request or confirm) can be lost or delayed in normal 2-way handshake  Use retransmit-RFC timer → receiver may get duplicate RFCs (if CONNECTION_CONFIRM lost)  1. ignore duplicate if connection already set up  2. confusing if arrives after connection clear Mistaken for new request, real new request is discarded

37. TO 3-7-06 p. 37 Type C Network - Connection Setup (cont)

38. TO 3-7-06 p. 38 Type C Network - Connection Setup (cont)  If CONNECTION_REQUEST is delayed, sender may get duplicate RFCs  Ignore duplicate if connection already up  3-way handshake: ACK both the RFC and sequence number  Old RFC causes a reset (rejection) at sender  Old CONNECTION_CONFIRMED is discarded

39. TO 3-7-06 p. 39 Type C Network - Connection Setup (cont)

40. TO 3-7-06 p. 40 Spring 2006 EE 5304/EETS 7304 Internet Protocols Tom Oh Dept of Electrical Engineering taehwan@engr.smu.edu Lecture 13 UDP

41. TO 3-7-06 p. 41 Outline  UDP (comer, Ch. 24)  UDP header (Comer, Ch. 24)

42. TO 3-7-06 p. 42 UDP (User Datagram Protocol)  Provides unreliable datagram service with less overhead than TCP  Application has full responsibility for handling datagrams that are lost, duplicated, or out of order  UDP adds multiplexing on top of IP  Different applications on same host are identified by port numbers  An application is identified uniquely by

43. TO 3-7-06 p. 43 UDP (cont) Transport Application Transport Application Host UDP port 80 Application UDP port 25 Application UDP port 26 UDP port 18 Unreliable connectionless service

44. TO 3-7-06 p. 44 UDP 8-byte Header Source port (16 bits): optional; allows replies to sender Destination port (16 bits): identifies application at destination host Message length (16 bits): bytes of data + 8 for UDP header

45. TO 3-7-06 p. 45 UDP Header (cont)  Checksum (2 bytes) = error detection over a pseudoheader + UDP datagram Pseudoheader UDP datagram

46. TO 3-7-06 p. 46 UDP Header (cont)  Pseudoheader = 12 bytes constructed from IP header  Source and dest. IP addresses (4 bytes each)  Protocol (1 byte) = 17 for UDP  UDP length (2 bytes) = length of UDP datagram (excluding pseudoheader)

47. TO 3-7-06 p. 47 UDP Header (cont)  IP address is used in checksum to verify correct destination  Does this checksum violate the layering principle?  Yes - because UDP uses info from IP layer below it (IP packet header fields)

48. TO 3-7-06 p. 48 Spring 2006 EE 5304/EETS 7304 Internet Protocols Tom Oh Dept of Electrical Engineering taehwan@engr.smu.edu Lecture 13 TCP - Part 1

49. TO 3-7-06 p. 49 Outline (Comer, Ch. 25)  TCP  TCP header  TCP retransmissions  TCP duplicate detection  TCP connection set-up and close

50. TO 3-7-06 p. 50 TCP (Transmission Control Protocol)  TCP is predominant transport layer protocol to add end-to-end reliability above IP  Designed for reliable sequential byte stream delivery with no duplicates, no loss  Views application data as continuous byte stream, breaks into segments of 64-Kbyte max. length  Keeps track of each byte with a sequence number  Segments are prefixed with TCP header and encapsulated into IP packets

51. TO 3-7-06 p. 51 TCP (cont) TCP data TCP header IP header Sending application Data Data Data TCP header TCP segment Receiving application Data Data Data TCP header TCP segment IP packet

52. TO 3-7-06 p. 52 TCP (cont)  Provides connection-oriented service between applications on different hosts  An application is identified to TCP by port address  Application is completely identified by 16-bit port address & 32-bit IP address  TCP connection is between two endpoints, source and destination

53. TO 3-7-06 p. 53 TCP (cont) Transport Application Transport Application Host TCP port 80 Application TCP port 25 Application TCP port 26 TCP port 18 Reliable connection-oriented service with no duplicate, lost, misordered, or errored bytes

54. TO 3-7-06 p. 54 TCP (cont)  TCP assumes IP - a type C network - so has all of most complicated functions of transport protocol  Error control detects missing, errored, non- sequential, and duplicate packets  Uses sequence numbers and piggybacked ACKs, adaptive retransmissions  Flow control using credits  Connection control: 3-way handshake  Also, TCP assumes responsibility for congestion avoidance because IP has no congestion control

55. TO 3-7-06 p. 55 TCP Header Source port (16 bits): optional; allows replies to sender Destination port (16 bits): identifies application at destination host

56. TO 3-7-06 p. 56 TCP Header Checksum (16 bits): error detection over pseudoheader + TCP segment

57. TO 3-7-06 p. 57 TCP Header (cont)  Pseudoheader is constructed from IP packet header including IP source/destination addresses, protocol field (=6 for TCP), length of TCP segment  Ensures that IP addresses are correct  Like UDP, this violates layering principle of OSI model

58. TO 3-7-06 p. 58 TCP Header Sequence number (32 bits): number of first data byte, except if SYN=1; data bytes are numbered sequentially, to reconstruct sender’s byte stream

59. TO 3-7-06 p. 59 TCP Header (cont) Sending application Byte n+1Byte n Data Data TCP header Number of first byte = sequence number Receiving application Data Byte n+2Byte n+1Byte n Byte n+2 Sequence number tells where this segment belongs in reconstructed byte stream

60. TO 3-7-06 p. 60 TCP Header Acknowledgement (32 bits): piggybacked ACK tells sender the next byte that is expected; ACKs are cumulative and refers to end of contiguous received data; additional received data, if not contiguous, triggers a duplicate ACK

61. TO 3-7-06 p. 61 TCP Header (cont) Sending application Data Segment A SEQ = 400 Receiver’s buffer Byte 399 Data Data Segment B SEQ = 600 Segment C SEQ = 800 Data Segment B received first ACK 400 bytes

62. TO 3-7-06 p. 62 TCP Header (cont) Sending application Data Segment A SEQ = 400 Receiver’s buffer Byte 399 Data Data Segment B SEQ = 600 Segment C SEQ = 800 Data Segment C received second ACK 400 duplicate bytes

63. TO 3-7-06 p. 63 TCP Header (cont) Sending application Data Segment A SEQ = 400 Receiver’s buffer Byte 999 Data Data Segment B SEQ = 600 Segment C SEQ = 800 Data Segment A received third ACK 1000 bytes

64. TO 3-7-06 p. 64 TCP Header (cont) Header length (4 bits): in units of 4 bytes; header is 20 bytes (value = 5) + options (if any) Reserved (6 bits): all zeros

65. TO 3-7-06 p. 65 TCP Header (cont) Flags (6 bits): URG: tells if Urgent pointer is used ACK: tells if Acknowledgement field is used PUSH: forces immediate transmission at sender RST: tells receiver to abort and reset connection SYN: segments for 3-way handshake to set up connection FIN: segments for 3-way handshake to terminate connection

66. TO 3-7-06 p. 66 TCP Header (cont) URG flag: tells if Urgent pointer is used Urgent pointer (16 bits): used if URG=1

67. TO 3-7-06 p. 67 TCP Header (cont)  Urgent pointer (2 bytes): points to number of first byte after urgent data in segment  If URG flag =1, data up to urgent pointer is urgent data to be processed immediately; rest of data is regular (not urgent)  Allows "out of band" data (to be processed immediately, out of sequence) Data TCP header Urgent pointer Urgent data Regular data

68. TO 3-7-06 p. 68 TCP Header (cont)  Push function:  Normally, TCP accumulates data from sender before transmitting a segment  If sender issues a “push”, TCP will send the ready data, even if segment will be short (e.g., 1 byte of data)

69. TO 3-7-06 p. 69 TCP Header (cont) Window (16 bits): piggybacked credit advertised by receiver; for flow control of sender