Please enable JavaScript.
Coggle requires JavaScript to display documents.
NWC201 - 3 - Transport Layer (Connection-Oriented Transport: TCP (The TCP…
NWC201 - 3 - Transport Layer
Transport-Layer Services
Introduction
How it work?
send side: breaks app messages into segments, passes to network layer
receive side: reassembles segments into messages, passes to app layer
transport protocol available to apps
UDP - Unreliable
no-frills extension of “best-effort” IP
TCP - Reliable
flow control
connection setup
congestion control
Services not available
Delay guarantees
Bandwidth guarantees
provide logical communication between app processes running on different hosts
transport protocols run in end systems
Transport-Layer VS Network-Layer
Transport Layer
logical communication between processes
relies on, enhances, network layer services
Network Layer
logical communication between hosts
TCP congestion control
Approach
additive increase
increase cwnd by 1 MSS every RTT until loss detected
multiplicative decrease
cut cwnd in half after loss
sender increases transmission rate (window size), probing for usable bandwidth, until loss occurs
Details
cwnd is dynamic, function of perceived network congestion
TCP sending rate:
roughly: send cwnd bytes, wait RTT for ACKS, then send more bytes
Sender limit transmission
LastByteSend - LastByteACKed < CWND
Multiplexing and demultiplexing
Multiplexing - Ghép kênh
add transport header (later used for demultiplexing)
handle data from multiple sockets
Demultiplexing - Tách kênh
use header infomation to deliver received segments to correct socket
How it work
Host Receive IP datagrams
Each datagram carry out one Transport-Layer segment
Each segment has source and destination port number
Each datagram has IP source address and IP destination address.
Host use IP addresses and Port Numbers to direct segment to appropriate socket.
Connectionless Transport: UDP
Why we need UDP
simple: no connection state at sender, receiver
small header size
no connection establishment (which can add delay)
no congestion control: UDP can blast away as fast as desired
Connectionless
each UDP segment handled independently of others
no handshaking between UDP sender, receiver
UDP is used for
DNS
SNMP - Network Management
streaming multimedia apps (loss tolerant, rate sensitive)
UDP segments may be
lost
delivered out-of-order to app
Connection-Oriented Transport: TCP
TCP Segment Structure
Round Trip Time Estimation and Timeout
Timeout Interval
TimeoutInterval = EstimatedRTT + 4*DevRTT
Estimate Round Trip Time
EstimatedRTT = 0.875 • EstimatedRTT + 0.125 • SampleRTT
DevRTT - safety magin
DevRTT = 0.75 • DevRTT + 0.25 • | SampleRTT – EstimatedRTT |
Sequence number
byte stream “number” of first byte in segment’s data
Acknowledge Number
seq # of next byte expected from other side
cumulative ACK
The TCP connection
Point-to-Point
one sender, one receiver
Connection-Oriented
Three Way Handshake
Full-Duplex Service
bi-directional data flow in same connection
MSS: maximum segment size
Flow controlled
sender will not overwhelm receiver
Pipeline
TCP congestion and flow control set window size
Reliable, in-order by stream
Reliable Data Transfer
retransmissions triggered by:
Duplicate acks
Timeout events
TCP creates rdt service on top of IP’s unreliable service
cumulative acks
single retransmission timer
pipelined segments
Flow Control
receiver controls sender, so sender won’t overflow receiver’s buffer by transmitting too much, too fast
receiver “advertises” free buffer space by including rwnd value in TCP header of receiver-to-sender segments
sender limits amount of unacked (“in-flight”) data to receiver’s rwnd value
guarantees receive buffer will not overflow
TCP Connection Management
Two ways handshake
Three ways handshake
Step 2.
Second, the
acknowledgment field
of the TCP segment header is set to client_isn+1
First, the SYN bit is set to 1.
the server
chooses its own initial sequence number (server_isn) and puts this value in the sequence number field of the TCP segment header.
Step 3.
The SYN bit is set to zero, since the
connection is established
putting the value server_isn+1 in the acknowledgment
field
Step 1.
the SYN bit, is set to 1
chooses an initial sequence number (client_isn) and puts
this number in the
sequence number field
The client-side TCP first sends a special TCP segment to the server-side TCP
before exchanging data, sender/receiver “handshake”:
agree to establish connection (each knowing the other willing to establish connection)
agree on connection parameters
Close A Connection
respond to received FIN with ACK
simultaneous FIN exchanges can be handled
client, server each close their side of connection
Principles of congestion control
Congestion
different from flow control!
manifestations:
lost packets (buffer overflow at routers)
long delays (queueing in router buffers)
informally: “too many sources sending too much data too fast for network to handle”
a top-10 problem!
Approachs
End-End Congestion Control
congestion inferred from end-system observed loss, delay
approach taken by TCP
no explicit feedback from network
Network-Assited Congestion Control
single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM)
explicit rate for sender to send at
routers provide feedback to end systems
Principle of reliable data transfer
rdt
rdt2.0
can handle bit error
ACK
NAK
rdt 2.1
Handle ACK/NAK signal corrupt
Sequence number
rdt 3.0
Can handle when loss ACK signal
use Timer
Can handle when loss packet, packet cannot arrive at receiver
rdt 1.0
no loss packed or bit error
perfect udt protocol
rdt 2.2
is like rdt 2.1
remove NAK signal
receiver Send ACK and last ok sequence number
Pipeline
Go-back-N
sender can have up to N unacked packets in pipeline
receiver only sends cumulative ack
sender has timer for oldest unacked packet
when timer expires, retransmit all unacked packets
Selective Repeat
sender maintains timer for each unacked packet
when timer expires, retransmit only that unacked packet
rcvr sends individual ack for each packet
sender can have up to N unack’ed packets in pipeline