CN Unit II - Transport Layer

Views:
 
Category: Entertainment
     
 

Presentation Description

Transport services, Connection management, UDP, TCP, Socket Programming(TCP & UDP),TCP Flow control, TCP Congestion Control

Comments

Presentation Transcript

Unit II: Transport Layer : 

Unit II: Transport Layer Reference: Kurose, Ross “Computer Networking-a top down approach featuring the internet” Slides prepared by: Mr. Vaibhav Dabhade For TE Computer Engineering

Outline : 

Outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control

Transport services and protocols : 

Transport services and protocols provide logical communication between app processes running on different hosts transport protocols run in end systems send side: breaks app messages into segments, passes to network layer rcv side: reassembles segments into messages, passes to app layer more than one transport protocol available to apps Internet: TCP and UDP

Transport vs. Network layer : 

Transport vs. Network layer network layer: logical communication between hosts transport layer: logical communication between processes relies on, enhances, network layer services Household analogy: 12 kids sending letters to 12 kids processes = kids app messages = letters in envelopes hosts = houses transport protocol = Ann and Bill network-layer protocol = postal service

Internet transport-layer protocols : 

Internet transport-layer protocols reliable, in-order delivery (TCP) congestion control flow control connection setup unreliable, unordered delivery: UDP no-frills extension of “best-effort” IP

Outline : 

Outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control

Multiplexing/demultiplexing : 

Multiplexing/demultiplexing application transport network link physical P1 application transport network link physical application transport network link physical P2 P3 P4 P1 host 1 host 2 host 3 = process = socket delivering received segments to correct socket gathering data from multiple sockets, enveloping data with header (later used for demultiplexing)

How demultiplexing works : 

How demultiplexing works host receives IP datagrams each datagram has source IP address, destination IP address each datagram carries 1 transport-layer segment each segment has source, destination port number host uses IP addresses & port numbers to direct segment to appropriate socket source port # dest port # 32 bits Application data (message) other header fields TCP/UDP segment format

Connectionless demultiplexing : 

Connectionless demultiplexing Create sockets with port numbers: DatagramSocket mySocket1 = new DatagramSocket(12534); DatagramSocket mySocket2 = new DatagramSocket(12535); UDP socket identified by two-tuple: (dest IP address, dest port number) When host receives UDP segment: checks destination port number in segment directs UDP segment to socket with that port number IP datagrams with different source IP addresses and/or source port numbers directed to same socket

Connectionless demux (cont) : 

Connectionless demux (cont) DatagramSocket serverSocket = new DatagramSocket(6428); SP provides “return address”

Connection-oriented demux : 

Connection-oriented demux TCP socket identified by 4-tuple: source IP address source port number dest IP address dest port number recv host uses all four values to direct segment to appropriate socket Server host may support many simultaneous TCP sockets: each socket identified by its own 4-tuple Web servers have different sockets for each connecting client non-persistent HTTP will have different socket for each request

Connection-oriented demux (cont) : 

Connection-oriented demux (cont) Client IP:B server IP: C SP: 9157 DP: 80 D-IP:C S-IP: A D-IP:C S-IP: B D-IP:C S-IP: B

Connection-oriented demux: Threaded Web Server : 

Connection-oriented demux: Threaded Web Server Client IP:B server IP: C SP: 9157 DP: 80 P4 D-IP:C S-IP: A D-IP:C S-IP: B D-IP:C S-IP: B

Outline : 

Outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control

UDP: User Datagram Protocol [RFC 768] : 

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

UDP: more : 

UDP: more often used for streaming multimedia apps loss tolerant rate sensitive other UDP uses DNS reliable transfer over UDP: add reliability at application layer 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

UDP checksum : 

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

Outline : 

Outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control

Principles of Reliable data transfer : 

Principles of Reliable data transfer characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)

Principles of Reliable data transfer : 

Principles of Reliable data transfer characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)

Principles of Reliable data transfer : 

Principles of Reliable data transfer characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)

Outline : 

Outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control

Outline : 

Outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control

TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 : 

TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 full duplex data: bi-directional data flow in same connection MSS: maximum segment size connection-oriented: handshaking (exchange of control msgs) init’s sender, receiver state before data exchange flow controlled: sender will not overwhelm receiver point-to-point: one sender, one receiver pipelined: TCP congestion and flow control set window size send & receive buffers

TCP segment structure : 

TCP segment structure 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)

TCP seq. #’s and ACKs : 

TCP seq. #’s and ACKs Seq. #’s: byte stream “number” of first byte in segment’s data ACKs: seq # of next byte expected from other side cumulative ACK Q: how receiver handles out-of-order segments 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’ simple telnet scenario

TCP Round Trip Time and Timeout : 

TCP Round Trip Time and Timeout Q: how to set TCP timeout value? longer than RTT but RTT varies too short: premature timeout unnecessary retransmissions too long: slow reaction to segment loss Q: how to estimate RTT? SampleRTT: measured time from segment transmission until ACK receipt ignore retransmissions SampleRTT will vary, want estimated RTT “smoother” average several recent measurements, not just current SampleRTT

TCP Round Trip Time and Timeout : 

TCP Round Trip Time and Timeout EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT Exponential weighted moving average influence of past sample decreases exponentially fast typical value:  = 0.125

Example RTT estimation: : 

Example RTT estimation:

TCP Round Trip Time and Timeout : 

TCP Round Trip Time and Timeout Setting the timeout EstimtedRTT plus “safety margin” large variation in EstimatedRTT -> larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT: TimeoutInterval = EstimatedRTT + 4*DevRTT DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT| (typically,  = 0.25) Then set timeout interval:

Chapter 3 outline : 

Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control

TCP reliable data transfer : 

TCP reliable data transfer TCP creates rdt service on top of IP’s unreliable service Pipelined segments Cumulative acks TCP uses single retransmission timer Retransmissions are triggered by: timeout events duplicate acks Initially consider simplified TCP sender: ignore duplicate acks ignore flow control, congestion control

TCP sender events: : 

TCP sender events: data rcvd from app: Create segment with seq # seq # is byte-stream number of first data byte in segment start timer if not already running (think of timer as for oldest unacked segment) expiration interval: TimeOutInterval timeout: retransmit segment that caused timeout restart timer Ack rcvd: If acknowledges previously unacked segments update what is known to be acked start timer if there are outstanding segments

TCP sender(simplified) : 

TCP sender(simplified) NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } } /* end of loop forever */

TCP: retransmission scenarios : 

TCP: retransmission scenarios Host A Seq=100, 20 bytes data ACK=100 premature timeout Host B Seq=92, 8 bytes data ACK=120 Seq=92, 8 bytes data ACK=120 Seq=92 timeout SendBase = 100 SendBase = 120 SendBase = 120 Sendbase = 100

TCP retransmission scenarios (more) : 

TCP retransmission scenarios (more) SendBase = 120

TCP ACK generation [RFC 1122, RFC 2581] : 

TCP ACK generation [RFC 1122, RFC 2581] Event at Receiver Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed Arrival of in-order segment with expected seq #. One other segment has ACK pending Arrival of out-of-order segment 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, ACKing both in-order segments Immediately send duplicate ACK, indicating seq. # of next expected byte Immediate send ACK, provided that segment starts at lower end of gap

Fast Retransmission : 

Fast Retransmission Time-out period often relatively long: long delay before resending lost packet Detect lost segments via duplicate ACKs. Sender often sends many segments back-to-back If segment is lost, there will likely be many duplicate ACKs. If sender receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost: fast retransmit: resend segment before timer expires

Slide 39: 

Figure 3.37 Resending a segment after triple duplicate ACK

Fast retransmit algorithm: : 

Fast retransmit algorithm: event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y } a duplicate ACK for already ACKed segment fast retransmit

Chapter 3 outline : 

Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control

TCP Flow Control : 

TCP Flow Control receive side of TCP connection has a receive buffer: speed-matching service: matching the send rate to the receiving app’s drain rate app process may be slow at reading from buffer

TCP Flow control: how it works : 

TCP Flow control: how it works (Suppose TCP receiver discards out-of-order segments) spare room in buffer = RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead] Rcvr advertises spare room by including value of RcvWindow in segments Sender limits unACKed data to RcvWindow guarantees receive buffer doesn’t overflow

Chapter 3 outline : 

Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control

TCP Connection Management : 

TCP Connection Management Recall: TCP sender, receiver establish “connection” before exchanging data segments initialize TCP variables: seq. #s buffers, flow control info (e.g. RcvWindow) client: connection initiator Socket clientSocket = new Socket("hostname","port number"); server: contacted by client Socket connectionSocket = welcomeSocket.accept(); Three way handshake: Step 1: client host sends TCP SYN segment to server specifies initial seq # no data Step 2: server host receives SYN, replies with SYNACK segment server allocates buffers specifies server initial seq. # Step 3: client receives SYNACK, replies with ACK segment, which may contain data

TCP Connection Management : 

TCP Connection Management Client Host Server Host Connection request (SYN=1, seq = client_isn) ack (SYN=0, seq= client_isn + 1, ack =server_isn + 1) Time Time Connection granted (SYN=1, seq= server_isn , ack = client_isn + 1) Figure: Three way handshaking

TCP Connection Management (cont.) : 

TCP Connection Management (cont.) Closing a connection: client closes socket: clientSocket.close(); Step 1: client end system sends TCP FIN control segment to server Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN.

TCP Connection Management (cont.) : 

TCP Connection Management (cont.) Step 3: client receives FIN, replies with ACK. Enters “timed wait” - will respond with ACK to received FINs Step 4: server, receives ACK. Connection closed. Note: with small modification, can handle simultaneous FINs. client FIN server ACK ACK FIN closing closing closed timed wait closed

TCP Connection Management (cont) : 

TCP Connection Management (cont) TCP client lifecycle TCP server lifecycle

Chapter 3 outline : 

Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control

Principles of Congestion Control : 

Principles of Congestion Control Congestion: informally: “too many sources sending too much data too fast for network to handle” different from flow control! manifestations: lost packets (buffer overflow at routers) long delays (queueing in router buffers)

Causes/costs of congestion: scenario 1 : 

Causes/costs of congestion: scenario 1 two senders, two receivers one router, infinite buffers no retransmission large delays when congested maximum achievable throughput

Causes/costs of congestion: scenario 2 : 

Causes/costs of congestion: scenario 2 one router, finite buffers sender retransmission of lost packet finite shared output link buffers Host A lin : original data Host B lout l'in : original data, plus retransmitted data

Causes/costs of congestion: scenario 2 : 

Causes/costs of congestion: scenario 2 always: (goodput) “perfect” retransmission only when loss: retransmission of delayed (not lost) packet makes larger (than perfect case) for same “costs” of congestion: more work (retrans) for given “goodput” unneeded retransmissions: link carries multiple copies of pkt

Causes/costs of congestion: scenario 3 : 

Causes/costs of congestion: scenario 3 four senders multihop paths timeout/retransmit Q: what happens as and increase ? finite shared output link buffers lin : original data lout l'in : original data, plus retransmitted data Host D Host C

Causes/costs of congestion: scenario 3 : 

Causes/costs of congestion: scenario 3 Another “cost” of congestion: when packet dropped, any “upstream transmission capacity used for that packet was wasted! lout

Approaches towards congestion control : 

Approaches towards congestion control End-end congestion control: no explicit feedback from network congestion inferred from end-system observed loss, delay approach taken by TCP Network-assisted congestion control: routers provide feedback to end systems single bit indicating congestion explicit rate sender should send at Two broad approaches towards congestion control:

Case study: ATM ABR congestion control : 

Case study: ATM ABR congestion control ABR: available bit rate: “elastic service” if sender’s path “underloaded”: sender should use available bandwidth if sender’s path congested: sender throttled to minimum guaranteed rate RM (resource management) cells: sent by sender, interspersed with data cells bits in RM cell set by switches (“network-assisted”) NI bit: no increase in rate (mild congestion) CI bit: congestion indication RM cells returned to sender by receiver, with bits intact

Case study: ATM ABR congestion control : 

Case study: ATM ABR congestion control EFCI bit in data cells: set to 1 in congested switch if data cell preceding RM cell has EFCI set, sender sets CI bit in returned RM cell Two-byte ER (explicit rate) field in RM cell congested switch may lower ER value in cell sender’ send rate thus maximum supportable rate on path

Chapter 3 outline : 

Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control

TCP congestion control: additive increase, multiplicative decrease : 

TCP congestion control: additive increase, multiplicative decrease Approach: increase transmission rate (window size), probing for usable bandwidth, until loss occurs additive increase: increase CongWin by 1 MSS every RTT until loss detected multiplicative decrease: cut CongWin in half after loss time Saw tooth behavior: probing for bandwidth

TCP Congestion Control: details : 

TCP Congestion Control: details sender limits transmission: LastByteSent-LastByteAcked  CongWin Roughly, CongWin is dynamic, function of perceived network congestion How does sender perceive congestion? loss event = timeout or 3 duplicate acks TCP sender reduces rate (CongWin) after loss event three mechanisms: AIMD slow start conservative after timeout events

TCP Slow Start : 

TCP Slow Start When connection begins, CongWin = 1 MSS Example: MSS = 500 bytes & RTT = 200 msec initial rate = 20 kbps available bandwidth may be >> MSS/RTT desirable to quickly ramp up to respectable rate When connection begins, increase rate exponentially fast until first loss event

TCP Slow Start (more) : 

TCP Slow Start (more) When connection begins, increase rate exponentially until first loss event: double CongWin every RTT done by incrementing CongWin for every ACK received Summary: initial rate is slow but ramps up exponentially fast Host A one segment RTT Host B two segments four segments

Refinement: inferring loss : 

Refinement: inferring loss After 3 dup ACKs: CongWin is cut in half window then grows linearly But after timeout event: CongWin instead set to 1 MSS; window then grows exponentially to a threshold, then grows linearly 3 dup ACKs indicates network capable of delivering some segments timeout indicates a “more alarming” congestion scenario Philosophy:

Summary: TCP Congestion Control : 

Summary: TCP Congestion Control When CongWin is below Threshold, sender in slow-start phase, window grows exponentially. When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly. When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold. When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS.

TCP sender congestion control : 

TCP sender congestion control

authorStream Live Help