Transport Layer Protocols PDF

** transport-layer protocols Transport services and protocols are implemented in the end systems but not in...

** transport-layer protocols Transport services and protocols are implemented in the end systems but not in Transport vs. network layer services and protocols network routers. § provide logical communication application transport between application processes network mobile network data link household analogy: physical national or global ISP running on different hosts 12 kids in Ann’s house sending lo g § transport protocols actions in end letters to 12 kids in Bill’s house: i ca l en systems: § hosts (also called end systems) = houses d -e sender: breaks application messages into § processes = kids nd local or segments, passes to network layer. This is tra done by (possibly) breaking the application regional ISP § app messages = letters in n sp messages into smaller chunks and adding a envelopes o rt home network content transport-layer header to each chunk to create the transport-layer segment. provider network datacenter § transport protocol = Ann and Bill receiver: reassembles segments into applicationnetwork transport who demux to in-house siblings network messages, passes to application layer data link physical § network-layer protocol = postal § two transport protocols available to enterprise service Internet applications network ** network routers do not examine the fields of the TCP, UDP transport-layer segment encapsulated with the datagram. Transport Layer: 3-2 1 2 Transport vs. network layer services and protocols Transport Layer Actions §network layer: logical household analogy: communication between 12 kids in Ann’s house sending Sender: hosts letters to 12 kids in Bill’s house: application § is passed an application- application app. msg layer message §transport layer: logical § hosts (also called end systems) = houses transport § determines segment TThhtransport app. msg communication between § processes = kids header fields values processes § app messages = letters in network (IP) § creates segment network (IP) envelopes § passes segment to IP link relies on, enhances, network § transport protocol = Ann and Bill link layer services who demux to in-house siblings physical physical ** the postal service provides logical communication § network-layer protocol = postal between the two houses—the postal service moves mail service from house to house, not from person to person. On the other hand, Ann and Bill provide logical communication among the cousins Transport Layer: 3-3 Transport Layer: 3-4 3 4 Transport Layer Actions Two principal Internet transport protocols §TCP: Transmission Control Protocol application transport network mobile network data link reliable, in-order delivery physical national or global ISP Receiver: congestion control (prevents excessive lo g application § receives segment from IP application amount of traffic ) i ca § checks header values flow control l en transport d- e transport app. msg § extracts application-layer connection setup nd message local or §UDP: User Datagram Protocol tra regional ISP network (IP) § demultiplexes message up network (IP) n sp to application via socket unreliable, unordered delivery o rt link link home network content no-frills extension of “best-effort” IP provider physical network Th physical datacenter app. msg §services not available: applicationnetwork transport network delay guarantees data link physical bandwidth guarantees enterprise network ** When designing a network application, the application Transport Layer: 3-5 developer must specify one of these two transport protocols. Transport Layer: 3-6 5 6  Connectionless transport UDP: User Datagram Protocol UDP: User Datagram Protocol § “no frills,” “bare bones” Why is there a UDP? § UDP use: Internet transport protocol § no connection § streaming multimedia apps (loss tolerant, rate sensitive), the lack of establishment (which can congestion control in UDP can result in high loss rates between a UDP § IP “best effort” service, UDP add RTT delay) segments may be: sender and receiver, and the crowding out of TCP sessions. § simple: no connection state lost § DNS (DNS runs over UDP, thereby avoiding TCP’s connection- at sender, receiver establishment delays). delivered out-of-order to app § small header size (only 8 § SNMP (UDP is used to carry network management data). § connectionless: bytes of overhead). § no congestion control § HTTP/3 (in Google’s Chrome browser, uses UDP as its underlying no handshaking between UDP transport protocol and implements reliability in an application-layer sender, receiver § UDP can blast away as fast as protocol on top of UDP). desired! each UDP segment handled § can function in the face of independently of others congestion Transport Layer: 3-7 Transport Layer: 3-8 7 8 UDP: User Datagram Protocol [RFC 768] UDP: Transport Layer Actions SNMP client SNMP server application application transport transport (UDP) (UDP) network (IP) network (IP) link link physical physical Transport Layer: 3-9 Transport Layer: 3-10 9 10 UDP: Transport Layer Actions UDP: Transport Layer Actions SNMP client SNMP server SNMP client SNMP server UDP sender actions: UDP receiver actions: application § is passed an application- application SNMP msg application § receives segment from IP application layer message § checks UDP checksum transport § determines UDP segment UDPhtransport UDP h SNMP msg transport header value transport (UDP) SNMP msg (UDP) (UDP) header fields values (UDP) § extracts application-layer network (IP) § creates UDP segment network (IP) network UDPh SNMP(IP) msg message network (IP) § demultiplexes message up link § passes segment to IP link link to application link physical physical physical physical Transport Layer: 3-11 Transport Layer: 3-12 11 12  UDP segment header Principles of reliable data transfer 32 bits source port # dest port # sending receiving ** With a reliable channel, no transferred process process length checksum application data data data bits are corrupted (flipped from 0 to 1, or transport vice versa) or lost, and all are delivered in reliable channel the order in which they were sent. application length, in bytes of data UDP segment, reliable service abstraction ** It is the responsibility of a reliable data (payload) including header transfer protocol to implement this service abstraction. data to/from Note arrows through reliable data transfer channel is just one way – reliably send from sender to receiver UDP segment format application layer Transport Layer: 3-13 Transport Layer: 3-14 13 14 Principles of reliable data transfer Principles of reliable data transfer sending receiving sending receiving sending receiving process process process process process process application data data application data data application data data transport transport transport reliable channel sender-side of receiver-side sender-side of receiver-side reliable service abstraction reliable data of reliable data Complexity of reliable data reliable data of reliable data transfer protocol transfer protocol transfer protocol transfer protocol transfer protocol will depend transport (strongly) on characteristics of transport ** Communication over unreliable channel is TWO- network network way: sender and receiver will exchange messages unreliable channel unreliable channel (lose, unreliable channel back and forth to IMPLEMENT one-way reliable corrupt, reorder data?) data transfer. reliable service implementation reliable service implementation Transport Layer: 3-15 Transport Layer: 3-16 15 16 Principles of reliable data transfer Principles of reliable data transfer § The key point here is that one side does NOT know what is going on at the sending receiving other side – it’s as if there’s a curtain between them. Everything they process process application data data know about the other can ONLY be learned by sending/receiving transport messages. sender-side of receiver-side Sender, receiver do not know reliable data of reliable data § Sender process wants to make sure a segment got through. But it can just transfer protocol transfer protocol somehow magically look through curtain to see if receiver got it. It will be the “state” of each other, e.g., up to the receiver to let the sender KNOW that it (the receiver) has was a message received? transport correctly received the segment. network § unless communicated via a unreliable channel message § How will the sender and receiver do that – that’s the PROTOCOL. reliable service implementation Transport Layer: 3-17 Transport Layer: 3-18 17 18  Connection-oriented transport TCP TCP segment structure 32 bits § always point-to-point: § cumulative ACKs source port # dest port # segment seq #: counting one sender, one receiver § pipelining: ACK: seq # of next expected sequence number bytes of data into bytestream byte; A bit: this is an ACK (not segments!) § reliable, in-order byte TCP congestion and flow control acknowledgement number set window size length (of TCP header) head not C E U A P R S F receive window flow control: # bytes steam: Internet checksum len used checksum Urg data pointer receiver willing to accept no “message boundaries" § connection-oriented: options (variable length) handshaking (exchange of control C, E: congestion notification § full duplex data: messages) initializes sender, TCP options bi-directional data flow in data sent by same connection. receiver state before data exchange RST, SYN, FIN: connection application management (used for data application into MSS: maximum segment size § flow controlled: connection setup and (variable length) TCP socket sender will not overwhelm receiver teardown ) Transport Layer: 3-19 Transport Layer: 3-20 19 20 TCP sequence numbers, ACKs TCP sequence numbers, ACKs outgoing segment from sender Sequence numbers: source port # dest port # Host A sequence num ber Host B byte stream “number” of acknowledgem ent num ber rwnd first byte in segment’s data checksum urg pointer window size User types‘C’ Acknowledgements: N Seq=42, ACK=79, data = ‘C’ host ACKs receipt seq # of next byte expected of‘C’, echoes back ‘C’ from other side sender sequence number space Seq=79, ACK=43, data = ‘C’ The key thing to note here is that the ACK cumulative ACK sent sent, not- usable not host ACKs receipt number (43) on the B-to-A segment is one ACKed yet ACKed but not usable of echoed ‘C’ more than the sequence number (42) on the Q: how receiver handles out-of- (“in-flight”) yet sent Seq=43, ACK=80 A-toB segment that triggered that ACK order segments? outgoing segment from receiver Similarly, the ACK number (80) on the last A- A: TCP spec doesn’t say, - up source port # dest port # sequence num ber to-B segment is one more than the sequence to implementor acknowledgem ent num ber simple telnet scenario number (79) on the B-to-A segment that A rwnd checksum urg pointer triggered that ACK Transport Layer: 3-21 Transport Layer: 3-22 21 22 TCP round trip time, timeout TCP Sender (simplified) ** TCP uses a timeout/retransmit mechanism to recover from lost segments. event: timeout ** Clearly, the timeout should be larger than the connection’s round-trip time (RTT), that is, event: data received from the time from when a segment is sent until it is acknowledged. application § retransmit segment that caused timeout § create segment with seq # Q: how to estimate RTT? § restart timer Q: how to set TCP timeout § seq # is byte-stream number § SampleRTT:measured time value? of first data byte in segment from segment transmission until event: ACK received § longer than RTT, but RTT varies! ACK receipt § start timer if not already § if ACK acknowledges ignore retransmissions running § too short: premature timeout, previously unACKed segments § SampleRTT will vary, want think of timer as for oldest unnecessary retransmissions unACKed segment update what is known to be estimated RTT “smoother” ACKed § too long: slow reaction to expiration interval: average several recent start timer if there are still segment loss measurements, not just current TimeOutInterval unACKed segments SampleRTT Transport Layer: 3-23 Transport Layer: 3-24 23 24  TCP Receiver: ACK generation [RFC 5681] Event at receiver TCP receiver action arrival of in-order segment with delayed ACK. Wait up to 500ms Rather than immediately ACKnowledig this segment, many TCP expected seq #. All data up to for next segment. If no next segment, implementations will wait for half a second for another in-order expected seq # already ACKed send ACK segment to arrive, and then generate a single cumulative ACK for both arrival of in-order segment with immediately send single cumulative segments – thus decreasing the amount of ACK traffic. The arrival of expected seq #. One other ACK, ACKing both in-order segments this second in-order segment and the cumulative ACK generation that segment has ACK pending covers both segments is the second row in this table. arrival of out-of-order segment immediately send duplicate ACK, higher-than-expect seq. #. indicating seq. # of next expected byte Gap detected arrival of segment that immediate send ACK, provided that partially or completely fills gap segment starts at lower end of gap Transport Layer: 3-25 Transport Layer: 3-26 25 26 TCP: retransmission scenarios TCP: retransmission scenarios Host A Host B Host A Host B Host A Host B SendBase=92 And in this last example, two segments are Seq=92, 8 bytes of data Seq=92, 8 bytes of data Seq=92, 8 bytes of data again transmitted, the first ACK is lost but the Seq=100, 20 bytes of data Seq=100, 20 bytes of data second ACK, a cumulative ACK arrives at the timeout timeout ACK=100 ACK=100 X sender, which then can transmit a third ACK=100 X ACK=120 ACK=120 segment, knowing that the first two have Seq=92, 8 bytes of data Seq=92, 8 arrived, even though the ACK for the first SendBase=100 bytes of data send cumulative Seq=120, 15 bytes of data segment was lost. SendBase=120 ACK for 120 ACK=100 ACK=120 SendBase=120 cumulative ACK covers lost ACK scenario premature timeout for earlier lost ACK Transport Layer: 3-27 Transport Layer: 3-28 27 28 This may help you to understand; TCP fast retransmit TCP flow control https://www.youtube.com/watch?v=E4I6t0mI_is Host A Host B TCP fast retransmit application Q: What happens if network Application removing process if sender receives 3 additional layer delivers data faster than data from TCP socket Seq=92 ACKs for same data (“triple Seq=10 , 8 byte s of da ta application layer removes buffers TCP socket duplicate ACKs”), resend unACKed 0, 20 by tes of data data from socket buffers? receiver buffers segment with smallest seq # X § likely that unACKed segment lost, TCP =100 so don’t wait for timeout A CK ** the hosts on each side of a TCP Network layer code connection set aside a receive buffer for delivering IP datagram =100 timeout A CK the connection. When the TCP payload into TCP =100 connection receives bytes that are socket buffers IP A CK code =100 correct and in sequence, it places the Receipt of three duplicate ACKs A CK data in the receive buffer. indicates 3 segments received Seq=100, 20 bytes of data ** The associated application process after a missing segment – lost will read data from this buffer, but not from sender segment is likely. So retransmit! necessarily at the instant the data receiver protocol stack arrives. Transport Layer: 3-29 Transport Layer: 3-30 29 30  TCP flow control TCP flow control application application Q: What happens if network Application removing process Q: What happens if network Application removing process layer delivers data faster than data from TCP socket layer delivers data faster than data from TCP socket application layer removes buffers application layer removes buffers TCP socket TCP socket data from socket buffers? receiver buffers data from socket buffers? receiver buffers TCP TCP code code Network layer delivering IP datagram receive window flow control: # bytes payload into TCP receiver willing to accept IP IP socket buffers code code ** TCP provides a flow-control service to its applications to eliminate the possibility of the sender overflowing the receiver’s buffer. from sender ** Flow control is thus a speed-matching from sender service—matching the rate at which the receiver protocol stack receiver protocol stack sender is sending against the rate at which the receiving application is reading. Transport Layer: 3-31 Transport Layer: 3-32 31 32 ** TCP provides flow control by having the TCP flow control TCP flow control sender maintain a variable called the receive window. Informally, the receive window is used to give the sender an idea of how much free application buffer space is available at the receiver. Q: What happens if network Application removing process § TCP receiver “advertises” free buffer layer delivers data faster than data from TCP socket space in rwnd field in TCP header to application process application layer removes buffers TCP socket RcvBuffer size set via socket data from socket buffers? receiver buffers options (typical default is 4096 bytes) RcvBuffer buffered data TCP many operating systems autoadjust rwnd flow control code RcvBuffer free buffer space receiver controls sender, so sender won’t overflow IP § sender limits amount of unACKed TCP segment payloads receiver’s buffer by code (“in-flight”) data to received rwnd transmitting too much, too fast TCP receiver-side buffering § guarantees receive buffer will not from sender overflow ** receiver allocates a receive buffer to the connection; receiver protocol stack denote its size by RcvBuffer. ** The receive window, denoted rwnd is set to the Transport Layer: 3-33 amount of spare room in the buffer. Transport Layer: 3-34 33 34 TCP flow control flow control: # bytes receiver willing to accept TCP connection management before exchanging data, sender/receiver “handshake”: § TCP receiver “advertises” free buffer § agree to establish connection (each knowing the other willing to establish connection) space in rwnd field in TCP header § agree on connection parameters (e.g., starting seq #s) receive window RcvBuffer size set via socket options (typical default is 4096 bytes) application application many operating systems autoadjust connection state: ESTAB connection state: ESTAB RcvBuffer connection variables: connection Variables: seq # client-to-server seq # client-to-server § sender limits amount of unACKed server-to-client rcvBuffer size server-to-client rcvBuffer size (“in-flight”) data to received rwnd at server,client at server,client network network § guarantees receive buffer will not TCP segment format overflow ** By keeping the amount of unacknowledged data less than the value of rwnd, sender is assured that it is not overflowing the receive buffer at the receiver. Transport Layer: 3-35 Transport Layer: 3-36 35 36  TCP 3-way handshake Closing a TCP connection Server state serverSocket = socket(AF_INET,SOCK_STREAM) § client, server each close their side of connection Client state serverSocket.bind((‘’,serverPort)) serverSocket.listen(1) send TCP segment with FIN bit = 1 clientSocket = socket(AF_INET, SOCK_STREAM) connectionSocket, addr = serverSocket.accept() LISTEN § respond to received FIN with ACK clientSocket.connect((serverName,serverPort)) LISTEN choose init seq num, x on receiving FIN, ACK can be combined with own FIN 1- The client-side TCP send TCP SYN msg 2- TCP SYN segm ent first sends a special TCP segm ent (SYN) SYNSENT SYNbit=1, Seq=x arrives at the server, server allocates the § simultaneous FIN exchanges can be handled to the server-side TCP choose init seq num, y TCP buffers and contains random ly send TCP SYNACK variables to the chooses an initial msg, acking SYN SYN RCVD connection, and sends sequence num ber x (contains no SYNbit=1, Seq=y a connection-granted application -layer data ACKbit=1; ACKnum=x+1 segm ent (no application-layer data) ) and SYN bit, is set to received SYNACK(x) that contains three 1. ESTAB indicates server is live; im portant pieces of send ACK for SYNACK; inform ation (SYN bit is this segment may contain ACKbit=1, ACKnum=y+1 set to 1, client-to-server data acknowledgm ent field 3- Receive the SYNACK segm ent, allocates received ACK(y) (x+1), and server’s buffers and variables to the connection. Then indicates client is live sends the server last segm ent acknowledges ESTAB initial sequence num ber) to the client the server’s connection-granted segm ent, TCP. SYN bit is set to zero. Transport Layer: 3-37 Transport Layer: 3-38 37 38 Principles of congestion control Approaches towards congestion control Congestion: § informally: “too many sources sending too much data too fast for End-end congestion control: network to handle” § no explicit feedback from § manifestations: network layer. long delays (queueing in router buffers) § congestion inferred from data data ACKs packet loss (buffer overflow at routers) observed loss, delay ACKs § different from flow control! § approach taken by TCP congestion control: too many senders, sending too fast ** the sender enforce congestion by lost packet flow control: one sender indications that might be timeouts or triple duplicate ACKs too fast for one receiver or by the measured RTT Transport Layer: 3-39 Transport Layer: 3-40 39 40 Approaches towards congestion control TCP congestion control: AIMD § approach: senders can increase sending rate until packet loss (congestion) occurs, then decrease sending rate on loss event Network-assisted congestion Additive Increase Multiplicative Decrease control: explicit congestion info increase sending rate by 1 cut sending rate in half at § routers provide direct feedback maximum segment size every each loss event to sending/receiving hosts with RTT until loss detected data data ACKs flows passing through congested ACKs router. TCP sender Sending rate AIMD saw tooth ** TCP’s congestion control consists of linear (additive) § may indicate congestion level or increase in cwnd of 1 MSS per behavior: probing explicitly set sending rate 1- Direct feedback m ay be 2- The second and m ore com m on form RTT and then a halving (multiplicative decrease) of sent from a network router of notification occurs when a router cwnd on a triple duplicate-ACK for bandwidth § TCP ECN, ATM, DECbit protocols to the sender. This form of m arks/updates a field in a packet notification typically takes flowing from sender to receiver to event. the form of a choke packet indicate congestion. Upon receipt of a (essentially saying, “I’m m arked packet, the receiver then congested!”). notifies the sender of the congestion indication. Transport Layer: 3-41 time Transport Layer: 3-42 41 42  TCP AIMD: more TCP congestion control: details Multiplicative decrease detail: sending rate is sender sequence number space cwnd TCP sending behavior: § Cut in half on loss detected by triple duplicate ACK (TCP Reno) § roughly: send cwnd bytes, § Cut to 1 MSS (maximum segment size) when loss detected by wait RTT for ACKS, then timeout (TCP Tahoe) send more bytes last byte available but cwnd Why AIMD? ACKed sent, but not- TCP rate ~ ~ bytes/sec yet ACKed not used RTT § AIMD – a distributed, asynchronous algorithm – has been (“in-flight”) last byte sent shown to: optimize congested flow rates network wide! § TCP sender limits transmission: LastByteSent- LastByteAcked < cwnd have desirable stability properties