Data and Computer Communications Eighth Edition by William Stallings Lecture slides by Lawrie Brown Chapter 20 – Transport Protocols
TCP L4, Connection-oriented, Reliable TCP: L4, Connection-oriented, Reliable End-to-End, Port # Connection setup Connection setup/termination Flow/Error/Congestion Control Credit-based Persist Timer 2-way handshake 3-way 3-way RTT ReTx Timer (RTT) Exp. RTO Backoff Karn’s Algorithm Window Management
Transport Protocols The foregoing observations should make us reconsider the widely held view that birds live only in the present. In fact, birds are aware of more than immediately present stimuli; they remember the past and anticipate the future. — The Minds of Birds, Alexander Skutch
Transport Protocols end-to-end data transfer service shield upper layers from network details reliable, connection oriented has greater complexity has greater complexity eg. TCP eg. TCP best effort, connectionless datagram datagram eg. UDP eg. UDP
Connection Oriented Transport Protocols provides establishment, maintenance & termination of a logical connection most common service used for a wide variety of applications is reliable but complex first discuss evolution from reliable to unreliable network services
Reliable Sequencing Network Service assume virtually 100% reliable delivery by network service of arbitrary length messages eg. reliable packet switched network with X.25 eg. reliable packet switched network with X.25 eg. frame relay with LAPF control protocol eg. frame relay with LAPF control protocol eg. IEEE with connection oriented LLC service eg. IEEE with connection oriented LLC service transport service is a simple, end to end protocol between two systems on same network issues are: addressing, multiplexing, flow control, connection establishment and termination
Addressing establish identity of other transport entity by: user identification (host, port) user identification (host, port) a socket in TCPa socket in TCP transport entity identification (on host) transport entity identification (on host) specify transport protocol (TCP, UDP)specify transport protocol (TCP, UDP) host address of attached network device host address of attached network device in an internet, a global internet addressin an internet, a global internet address network number network number transport layer passes host to network layer
Finding Addresses know address ahead of time well known addresses eg. common servers like FTP, SMTP etc eg. common servers like FTP, SMTP etc name server does directory lookup does directory lookup sending request to well known address which spawns new process to handle it
Multiplexing of upper layers (downward multiplexing) so multiple users employ same transport protocol so multiple users employ same transport protocol user identified by port number or service access point user identified by port number or service access point may also multiplex with respect to network services used (upward multiplexing) eg. multiplexing a single virtual X.25 circuit to a number of transport service user eg. multiplexing a single virtual X.25 circuit to a number of transport service user
Flow Control issues: longer transmission delay between transport entities compared with actual transmission time delays communication of flow control info longer transmission delay between transport entities compared with actual transmission time delays communication of flow control info variable transmission delay so difficult to use timeouts variable transmission delay so difficult to use timeouts want TS flow control because: receiving user can not keep up receiving user can not keep up receiving transport entity can not keep up receiving transport entity can not keep up which can result in buffer overflowing managing flow difficult because of gap between sender and receiver
Coping with Flow Control Requirements do nothing segments that overflow are discarded segments that overflow are discarded sender fail to get ACK and will retransmit sender fail to get ACK and will retransmit refuse further segments triggers network flow control but clumsy triggers network flow control but clumsy use fixed sliding window protocol works well on reliable network works well on reliable network does not work well on unreliable network does not work well on unreliable network use credit scheme
Credit Scheme decouples flow control from ACK each octet has sequence number each transport segment has seq number (SN), ack number (AN) and window size (W) in header sends seq number of first octet in segment ACK includes (AN=i, W=j) which means all octets through SN=i-1 acknowledged, want i next all octets through SN=i-1 acknowledged, want i next permission to send additional window of W=j octets permission to send additional window of W=j octets
Credit Allocation
Sending and Receiving Perspectives
Establishment and Termination need connection establishment and termination procedures to allow: each end to know the other exists each end to know the other exists negotiation of optional parameters negotiation of optional parameters triggers allocation of transport entity resources triggers allocation of transport entity resources
Connection State Diagram
Connection Establishment
Connection Termination either or both sides by mutual agreement graceful or abrupt termination if graceful, initiator must: send FIN to other end, requesting termination send FIN to other end, requesting termination place connection in FIN WAIT state place connection in FIN WAIT state when FIN received, inform user and close connection when FIN received, inform user and close connection other end must: when receives FIN must inform TS user and place connection in CLOSE WAIT state when receives FIN must inform TS user and place connection in CLOSE WAIT state when TS user issues CLOSE primitive, send FIN & close connection when TS user issues CLOSE primitive, send FIN & close connection
Unreliable Network Service more difficult case for transport protocol since segments may get lost segments may get lost segments may arrive out of order segments may arrive out of order examples include IP internet, frame relay using LAPF, IEEE with unacknowledge connectionless LLC IP internet, frame relay using LAPF, IEEE with unacknowledge connectionless LLC issues: ordered delivery, retransmission strategy, duplication detection, flow control, connection establishment & termination, crash recovery ordered delivery, retransmission strategy, duplication detection, flow control, connection establishment & termination, crash recovery
Ordered Delivery segments may arrive out of order hence number segments sequentially TCP numbers each octet sequentially and segments are numbered by the first octet number in the segment
Retransmission Strategy retransmission of segment needed because segment damaged in transit segment damaged in transit segment fails to arrive segment fails to arrive transmitter does not know of failure receiver must acknowledge successful receipt can use cumulative acknowledgement for efficiency can use cumulative acknowledgement for efficiency sender times out waiting for ACK triggers re-transmission
Timer Value fixed timer based on understanding of network behavior based on understanding of network behavior can not adapt to changing network conditions can not adapt to changing network conditions too small leads to unnecessary re-transmissions too small leads to unnecessary re-transmissions too large and response to lost segments is slow too large and response to lost segments is slow should be a bit longer than round trip time should be a bit longer than round trip time adaptive scheme may not ACK immediately may not ACK immediately can not distinguish between ACK of original segment and re-transmitted segment can not distinguish between ACK of original segment and re-transmitted segment conditions may change suddenly conditions may change suddenly
Duplication Detection if ACK lost, segment duplicated & re-transmitted receiver must recognize duplicates if duplicate received prior to closing connection receiver assumes ACK lost and ACKs duplicate receiver assumes ACK lost and ACKs duplicate sender must not get confused with multiple ACKs sender must not get confused with multiple ACKs need a sequence number space large enough to not cycle within maximum life of segment need a sequence number space large enough to not cycle within maximum life of segment
Incorrect Duplicate Detection
Flow Control credit allocation quite robust with unreliable net can ack data & grant credit can ack data & grant credit or just one or other or just one or other lost ACK recovers on next received lost ACK recovers on next received have problem if AN=i, W=0 closing window then send AN=i, W=j to reopen, but this is lost then send AN=i, W=j to reopen, but this is lost sender thinks window closed, receiver thinks it open sender thinks window closed, receiver thinks it open solution is to use persist timer if timer expires, send something could be re-transmission of previous segment could be re-transmission of previous segment
Connection Establishment two way handshake A send SYN, B replies with SYN A send SYN, B replies with SYN lost SYN handled by re-transmission lost SYN handled by re-transmission ignore duplicate SYNs once connected ignore duplicate SYNs once connected lost or delayed data segments can cause connection problems eg. segment from old connection eg. segment from old connection
Two Way Handshake: Obsolete Data Segment Solution: start each new connection with a different seq. no. that is far removed from the last seq. no. of the most recent connection.
Two Way Handshake: Obsolete SYN Segment Solution: to acknowledge explicitly the other’s SYN and seq. number Three way handshake
Three Way Handshake: State Diagram
Three Way Handshake: Examples
Connection Termination like connection need 3-way handshake misordered segments could cause: entity in CLOSE WAIT state sends last data segment, followed by FIN entity in CLOSE WAIT state sends last data segment, followed by FIN FIN arrives before last data segment FIN arrives before last data segment receiver accepts FIN, closes connection, loses data receiver accepts FIN, closes connection, loses data need to associate sequence number with FIN receiver waits for all segments before FIN sequence number
Connection Termination Graceful Close also have problems with loss of segments and obsolete segments need graceful close which will: send FIN i and receive AN i+1 (close S -> R) receive FIN j and send AN j+1 (close S <- R) wait twice maximum expected segment lifetime
Failure Recovery after restart all state info is lost may have half open connection as side that did not crash still thinks it is connected as side that did not crash still thinks it is connected close connection using keepalive timer wait for ACK for (time out) * (number of retries) wait for ACK for (time out) * (number of retries) when expired, close connection and inform user when expired, close connection and inform user send RST i in response to any i segment arriving user must decide whether to reconnect have problems with lost or duplicate data have problems with lost or duplicate data
TCP Transmission Control Protocol (RFC 793) connection oriented, reliable communication over reliable and unreliable (inter)networks two ways of labeling data: data stream push user requires transmission of all data up to push flag user requires transmission of all data up to push flag receiver will deliver in same manner receiver will deliver in same manner avoids waiting for full buffers avoids waiting for full buffers urgent data signal indicates urgent data is upcoming in stream indicates urgent data is upcoming in stream user decides how to handle it user decides how to handle it
TCP Services a complex set of primitives: incl. passive & active open, active open with data, send, allocate, close, abort, status incl. passive & active open, active open with data, send, allocate, close, abort, status passive open indicates will accept connections passive open indicates will accept connections active open with data sends data with open active open with data sends data with open and parameters: incl. source port, destination port & address, timeout, security, data, data length, PUSH & URGENT flags, send & receive windows, connection state, amount awaiting ACK incl. source port, destination port & address, timeout, security, data, data length, PUSH & URGENT flags, send & receive windows, connection state, amount awaiting ACK
TCP Header
TCP and IP not all parameters used by TCP are in its header TCP passes some parameters down to IP precedence precedence normal delay/low delay normal delay/low delay normal throughput/high throughput normal throughput/high throughput normal reliability/high reliability normal reliability/high reliability security security min overhead for each PDU is 40 octets
TCP Mechanisms Connection Establishment three way handshake SYN, SYN-ACK, ACK SYN, SYN-ACK, ACK connection determined by source and destination sockets (host, port) can only have a single connection between any unique pairs of ports but one port can connect to multiple different destinations (different ports)
TCP Mechanisms Data Transfer data transfer a logical stream of octets octets numbered modulo 2 32 flow control uses credit allocation of number of octets data buffered at transmitter and receiver sent when transport entity ready sent when transport entity ready unless PUSH flag used to force send unless PUSH flag used to force send can flag data as URGENT, sent immediately if receive data not for current connection, RST flag is set on next segment to reset connection
TCP Mechanisms Connection Termination graceful close TCP user issues CLOSE primitive TCP user issues CLOSE primitive transport entity sets FIN flag on last segment sent with last of data transport entity sets FIN flag on last segment sent with last of data abrupt termination by ABORT primitive entity abandons all attempts to send or receive data entity abandons all attempts to send or receive data RST segment transmitted to other end RST segment transmitted to other end
TCP Implementation Options TCP standard precisely specifies protocol have some implementation policy options: send send deliver deliver accept accept retransmit retransmit acknowledge acknowledge implementations may choose alternative options which may impact performance
Send Policy if no push or close TCP entity transmits at its own convenience in credit allocation data buffered in transmit buffer may construct segment per batch of data from user quick response but higher overheads quick response but higher overheads may wait for certain amount of data slower response but lower overheads slower response but lower overheads
Deliver Policy in absence of push, can deliver data at own convenience may deliver from each segment received higher O/S overheads but more responsive higher O/S overheads but more responsive may buffer data from multiple segments less O/S overheads but slower less O/S overheads but slower
Accept Policy segments may arrive out of order in order only accept segments in order only accept segments in order discard out of order segments discard out of order segments simple implementation, but burdens network simple implementation, but burdens network in windows accept all segments within receive window accept all segments within receive window reduce transmissions reduce transmissions more complex implementation with buffering more complex implementation with buffering
Retransmit Policy TCP has a queue of segments transmitted but not acknowledged will retransmit if not ACKed in given time first only - single timer, send one segment only when timer expires, efficient, has delays first only - single timer, send one segment only when timer expires, efficient, has delays batch - single timer, send all segments when timer expires, has unnecessary transmissions batch - single timer, send all segments when timer expires, has unnecessary transmissions individual - timer for each segment, complex individual - timer for each segment, complex effectiveness depends in part on receiver’s accept policy
Acknowledgement Policy immediate send empty ACK for each accepted segment send empty ACK for each accepted segment simple at cost of extra transmissions simple at cost of extra transmissions cumulative piggyback ACK on suitable outbound data segments unless persist timer expires piggyback ACK on suitable outbound data segments unless persist timer expires when send empty ACK when send empty ACK more complex but efficient more complex but efficient
Congestion Control flow control also used for congestion control recognize increased transit times & dropped packets recognize increased transit times & dropped packets react by reducing flow of data react by reducing flow of data RFC’s 1122 & 2581 detail extensions Tahoe, Reno & NewReno implementations Tahoe, Reno & NewReno implementations two categories of extensions: retransmission timer management retransmission timer management window management window management
Retransmission Timer Management static timer likely too long or too short estimate round trip delay by observing pattern of delay for recent segments set time to value a bit greater than estimate simple average over a number of segments exponential average using time series (RFC793) RTT Variance Estimation (Jacobson’s algorithm)
Retransmission Timer (cont) Simple Average RTT(i): round-trip time observed for the i th transmitted segment RTT(i): round-trip time observed for the i th transmitted segment ARTT(K): average round-trip time for the first K segments ARTT(K): average round-trip time for the first K segments or
Retransmission Timer (cont) Exponential Average SRTT: smoothed round-trip time estimate SRTT: smoothed round-trip time estimate RTO: retransmission timer RTO: retransmission timer RFC793: : 0.8 ~ 0.9, : 1.3 ~ 2.0 Example values: : 0.8 ~ 0.9, : 1.3 ~ 2.0
RTT Variance Estimation AERR(K): sample mean deviation measured at time K
RTT Variance Estimation (cont) Jacobson’s Algorithm g = 1/8 = 0.125, h = ¼ = 0.25, f = 2g = 1/8 = 0.125, h = ¼ = 0.25, f = 2
Use of Exponential Averaging
Jacobson’s RTO Calculation
Exponential RTO Backoff timeout probably due to congestion dropped packet or long round trip time dropped packet or long round trip time hence maintaining RTO is not good idea better to increase RTO each time a segment is re-transmitted RTO = q*RTO RTO = q*RTO commonly q=2 (binary exponential backoff) commonly q=2 (binary exponential backoff) as in ethernet CSMA/CD as in ethernet CSMA/CD
Karn’s Algorithm if segment is re-transmitted, ACK may be for: first copy of the segment (longer RTT than expected) first copy of the segment (longer RTT than expected) second copy second copy no way to tell don’t measure RTT for re-transmitted segments calculate backoff when re-transmission occurs use backoff RTO until ACK arrives for segment that has not been re-transmitted
Window Management slow start larger windows cause problem on connection created larger windows cause problem on connection created at start limit TCP to 1 segment at start limit TCP to 1 segment increase when data ACK, exponential growth increase when data ACK, exponential growth dynamic windows sizing on congestion when a timeout occurs perhaps due to congestion when a timeout occurs perhaps due to congestion set slow start threshold to half current congestion window set slow start threshold to half current congestion window set window to 1 and slow start until threshold set window to 1 and slow start until threshold beyond threshold, increase window by 1 for each RTT beyond threshold, increase window by 1 for each RTT
Window Management
Fast Retransmit Fast Recovery retransmit timer rather longer than RTT if segment lost TCP slow to retransmit fast retransmit if receive 4 ACKs for same segment then immediately retransmit since likely lost if receive 4 ACKs for same segment then immediately retransmit since likely lost fast recovery lost segment means some congestion lost segment means some congestion halve window then increase linearly halve window then increase linearly avoids slow-start avoids slow-start
TCP Congestion Control Fast retransmit (Receiver) Fast Recovery (Sender cwnd)
Implementation of TCP Congestion Control Measures
Flow Ctrl vs. Congestion Ctrl Why Flow Control?Why Congestion Control? Prevent Receiver Buffer Overflow Receiver-based window size (rwnd) Network-based window size (cwnd) Try Not To Cause Congestion Sender’s window = Min (cwnd, rwnd)
User Datagram Protocol (UDP) connectionless service for application level procedures specified in RFC 768 unreliable unreliable delivery & duplication control not guaranteed delivery & duplication control not guaranteed reduced overhead least common denominator service uses: inward data collection inward data collection outward data dissemination outward data dissemination request-response request-response real time application real time application
UDP Header
Summary connection-oriented network and transport mechanisms and services TCP services, mechanisms, policies TCP congestion control UDP
期末考加分題 10% = 3% + 4% + 3% 只針對「計算機網路」這門課程: 有關老師的教學,你覺得哪一些是好的 方式,為什麼? 就你的觀察,老師的教學過程中有哪一 些是不合適這門課的,為什麼? 請提供其他可以改進教學的建議。