TO p. 1 Spring 2006 EE 5304/EETS 7304 Internet Protocols Tom Oh Dept of Electrical Engineering Lecture 13 Transport Layer

TO 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.

TO 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

TO 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

TO 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

TO 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

TO 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

TO 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)

TO 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

TO 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)

TO 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

TO 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)

TO 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

TO 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

TO 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

TO 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

TO 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

TO 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

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

TO 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

TO 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

TO 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

TO 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

TO 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

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

TO 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

TO 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

TO 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

TO 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

TO 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)

TO 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

TO 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

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

TO 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

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

TO 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

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

TO 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

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

TO p. 40 Spring 2006 EE 5304/EETS 7304 Internet Protocols Tom Oh Dept of Electrical Engineering Lecture 13 UDP

TO p. 41 Outline  UDP (comer, Ch. 24)  UDP header (Comer, Ch. 24)

TO 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

TO 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

TO 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

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

TO 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)

TO 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)

TO p. 48 Spring 2006 EE 5304/EETS 7304 Internet Protocols Tom Oh Dept of Electrical Engineering Lecture 13 TCP - Part 1

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

TO 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

TO 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

TO 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

TO 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

TO 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

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

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

TO 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

TO 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

TO 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

TO 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

TO 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

TO 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

TO 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

TO 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

TO 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

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

TO 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

TO 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)

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