Presentation is loading. Please wait.

Presentation is loading. Please wait.

Transport Layer1 Goals: r understand principles behind transport layer services and protocols: m UDP m TCP Overview: r transport layer services r multiplexing/demultiplexing.

Similar presentations


Presentation on theme: "Transport Layer1 Goals: r understand principles behind transport layer services and protocols: m UDP m TCP Overview: r transport layer services r multiplexing/demultiplexing."— Presentation transcript:

1 Transport Layer1 Goals: r understand principles behind transport layer services and protocols: m UDP m TCP Overview: r transport layer services r multiplexing/demultiplexing r connectionless transport: UDP r connection-oriented transport: TCP m reliable transfer m flow control m connection management

2 Transport Layer2 Transport services and protocols r provide logical communication between app’ processes running on different hosts r transport protocols run in end systems (exception – L4, L7 switches) transport vs network layer services: r network layer: data transfer between end systems r transport layer: data transfer between processes m relies on, enhances, network layer services 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 logical end-end transport

3 Transport Layer3 Transport-layer protocols Internet transport services: r reliable, in-order unicast delivery (TCP) m congestion m flow control m connection setup r unreliable (“best-effort”), unordered unicast or multicast delivery: UDP r services not available: m real-time m bandwidth guarantees m reliable multicast 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 logical end-end transport

4 Transport Layer4 Multiplexing/demultiplexing segment - unit of data exchanged between transport layer entities m aka TPDU: transport protocol data unit Demultiplexing: delivering received segments (TPDUs)to correct app layer processes application transport network M P2 application transport network receiver H t H n segment M application transport network P1 M M M P3 P4 segment header application-layer data

5 Transport Layer5 Multiplexing/demultiplexing multiplexing/demultiplexing: r based on sender, receiver IP addresses & port numbers m source, dest port #s in each segment m “well-known” port numbers for specific applications source port #dest port # 32 bits application data (message) other header fields TCP/UDP segment format gathering data from multiple app processes, enveloping data with header (later used for demultiplexing) Multiplexing:

6 Transport Layer6 Multiplexing/demultiplexing: examples host A server B source port: x dest. port: 23 source port:23 dest. port: x port use: simple telnet app WWW client host A WWW server B WWW client host C Source IP: C Dest IP: B source port: x dest. port: 80 Source IP: C Dest IP: B source port: y dest. port: 80 port use: WWW server Source IP: A Dest IP: B source port: x dest. port: 80

7 Transport Layer7 UDP: User Datagram Protocol [RFC 768] r “no frills”, “bare bones” Internet transport protocol r “best effort” service, UDP segments may be: m lost m delivered out of order to app r connectionless: m no handshaking between UDP sender & receiver m each UDP segment handled independently of others Why is there a UDP? r no connection establishment (which can add delay, less resource required) r simple: no connection state at sender, receiver r small segment header r no congestion control: UDP can blast away as fast as desired

8 Transport Layer8 UDP (cont’d) r often used for streaming multimedia apps m loss tolerant m rate sensitive r other UDP uses m DNS m SNMP r reliable transfer over UDP: add reliability at application layer m application-specific error recovery! source port #dest port # 32 bits Application data (message) UDP segment format length checksum Length in bytes of UDP segment, including header

9 Transport Layer9 UDP checksum Sender: r treat segment contents as sequence of 16-bit integers r checksum: addition (1’s complement sum) of segment contents r sender puts checksum value into UDP checksum field Receiver: r compute checksum of received segment r check if computed checksum equals checksum field value: m NO - error detected m YES - no error detected. Goal: detect “errors” (e.g., flipped bits) in transmitted segment

10 Transport Layer10 TCP: Overview [RFCs: 793, 1122, 1323, 2018, 2581] r full duplex data: m bi-directional data flow in same connection m MSS: maximum segment size r connection-oriented: m handshaking (exchange of control msgs) init’s sender, receiver state before data exchange r flow controlled: m sender will not overwhelm receiver r point-to-point: m one sender, one receiver r reliable, in-order byte steam: m no “message boundaries” r pipelined: m TCP congestion and flow control set window size

11 Transport Layer11 TCP segment structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number rcvr window size ptr urgent data checksum F SR PAU head len not used Options (variable length) URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) # bytes rcvr willing to accept counting by bytes of data (not segments!) Internet checksum (as in UDP)

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

13 Transport Layer13 TCP: reliable data transfer simplified sender, assuming wait for event wait for event event: data received from application above event: timer timeout for segment with seq # y event: ACK received, with ACK # y create, send segment retransmit segment ACK processing one way data transfer no flow, congestion control

14 Transport Layer14 TCP: reliable data transfer 00 sendbase = initial_sequence number 01 nextseqnum = initial_sequence number 02 03 loop (forever) { 04 switch(event) 05 event: data received from application above 06 create TCP segment with sequence number nextseqnum 07 start timer for segment nextseqnum 08 pass segment to IP 09 nextseqnum = nextseqnum + length(data) 10 event: timer timeout for segment with sequence number y 11 retransmit segment with sequence number y 12 compute new timeout interval for segment y 13 restart timer for sequence number y 14 event: ACK received, with ACK field value of y 15 if (y > sendbase) { /* cumulative ACK of all data up to y */ 16 cancel all timers for segments with sequence numbers < y 17 sendbase = y 18 } 19 else { /* a duplicate ACK for already ACKed segment */ 20 increment number of duplicate ACKs received for y 21 if (number of duplicate ACKS received for y == 3) { 22 /* TCP fast retransmit */ 23 resend segment with sequence number y 24 restart timer for segment y 25 } 26 } /* end of loop forever */ Simplified TCP sender

15 Transport Layer15 TCP ACK generation [RFC 1122, RFC 2581] Event in-order segment arrival, no gaps, everything else already ACKed in-order segment arrival, no gaps, one delayed ACK pending out-of-order segment arrival higher-than-expect seq. # gap detected arrival of segment that partially or completely fills gap TCP Receiver action delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK immediately send single cumulative ACK send duplicate ACK, indicating seq. # of next expected byte immediate ACK if segment starts at lower end of gap

16 Transport Layer16 TCP: retransmission scenarios Host A Seq=92, 8 bytes data ACK=100 loss timeout time lost ACK scenario Host B X Seq=92, 8 bytes data ACK=100 Host A Seq=100, 20 bytes data ACK=100 Seq=92 timeout time premature timeout, cumulative ACKs Host B Seq=92, 8 bytes data ACK=120 Seq=92, 8 bytes data Seq=100 timeout ACK=120

17 Transport Layer17 TCP Flow Control receiver: explicitly informs sender of (dynamically changing) amount of free buffer space  RcvWindow size field in TCP segment sender: amount of transmitted, unACKed data less than most recently-receiver RcvWindow size sender will not overrun receiver’s buffers by transmitting too much, too fast flow control receiver buffering

18 Transport Layer18 TCP Round Trip Time and Timeout Q: how to set TCP timeout value? r longer than RTT m note: RTT will vary r too short: premature timeout m unnecessary retransmissions r too long: slow reaction to segment loss Q: how to estimate RTT?  SampleRTT : measured time from segment transmission until ACK receipt m ignore retransmissions, cumulatively ACKed segments  SampleRTT will vary, for “smoother” estimated RTT  use several recent measurements, not just current SampleRTT

19 Transport Layer19 TCP Round Trip Time and Timeout EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT r Exponential weighted moving average r influence of given sample decreases exponentially fast r typical value of x: 0.1 Setting the timeout r RTT plus “safety margin”  large variation in EstimatedRTT -> larger safety margin Timeout = EstimatedRTT + 4*Deviation Deviation = (1-x)*Deviation + x*abs(SampleRTT-EstimatedRTT)

20 Transport Layer20 TCP Connection Management Recall: TCP sender, receiver establish a “connection” before exchanging data segments r initialize TCP variables: m seq. #s  buffers, flow control info (e.g., RcvWindow ) r client: connection initiator r server: contacted by client

21 Transport Layer21 TCP Connection Management (cont’d) Opening a connection (3- way handshake): Step 1: client end system sends TCP SYN control segment to server Step 2: server end system receives SYN, replies with SYN-ACK m allocates buffers m ACKs received SYN Step 3: client rcvs SYN-ACK m connection is now set up m client starts the “real work” client SYN server SYN-ACK ACK open listen established

22 Transport Layer22 TCP Connection Management (cont’d) Closing a connection: Step 1: client end system sends TCP FIN control segment to server Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN. client FIN server ACK FIN close closed timed wait closed

23 Transport Layer23 TCP Connection Management (cont’d) Step 3: client receives FIN, replies with ACK. m Enters “timed wait” - will respond with ACK to received FINs Step 4: server, receives ACK. Connection closed. client FIN server ACK FIN close closed timed wait closed

24 Transport Layer24 TCP Connection Management (cont’d) TCP client FSM TCP server FSM

25 Transport Layer25 Summary r transport layer services r multiplexing/demultiplexing r connectionless transport: UDP r connection-oriented transport: TCP


Download ppt "Transport Layer1 Goals: r understand principles behind transport layer services and protocols: m UDP m TCP Overview: r transport layer services r multiplexing/demultiplexing."

Similar presentations


Ads by Google