Download - Networks - Chapter 3 - Transport Layer 1spp
Transport Layer 3-1
Chapter 3Transport Layer
Computer Networking: A Top Down Approach Featuring the Internet, 3rd edition. Jim Kurose, Keith RossAddison-Wesley, July 2004.
A note on the use of these ppt slides:We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following:
If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!)
If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material.
Thanks and enjoy! JFK/KWR
All material copyright 1996-2004J.F Kurose and K.W. Ross, All Rights Reserved
Transport Layer 3-2
Chapter 3: Transport LayerOur goals:
understand the principles behind the transport layer services:
multiplexing/demultiplexingreliable data transfer
flow controlcongestion control
learn about transport layer protocols in the Internet:
UDP: connectionless transportTCP: connection-oriented transport
TCP congestion control
Transport Layer 3-3
Chapter 3 outline
3.1 Transport-layer services3.2 Multiplexing and demultiplexing3.3 Connectionless transport: UDP3.4 Principles of reliable data transfer
3.5 Connection-oriented transport: TCP
segment structurereliable data transferflow controlconnection management
3.6 Principles of congestion control3.7 TCP congestion control
Transport Layer 3-4
Transport services and protocolsprovide logical communicationbetween application processes running on different hoststransport protocols run in end systems
send side: breaks app messages into segments, adds headers, then passes them to the network layerreceive side: reassembles segments into messages, passes them to the application layer
network routers act only on the network layer fields of the datagrammore than one transport layer protocol available to applications
Internet: TCP and UDP
applicationtransportnetworkdata linkphysical
applicationtransportnetworkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysicalnetwork
data linkphysical
logical end-end transport
Transport Layer 3-5
Transport vs. network layernetwork layer: logical communication between hoststransport layer: logical communication between processes within hosts
relies on and enhances the network layer services
Transport Layer 3-6
Internet transport-layer protocolsreliable, in-order delivery (TCP)
congestion control flow controlconnection setup
unreliable, unordered delivery (UDP)
no-frills extension of “best-effort” IP
services not available: delay guaranteesbandwidth guarantees
both TCP & UDP provide data integrity checking
applicationtransportnetworkdata linkphysical
applicationtransportnetworkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysicalnetwork
data linkphysical
logical end-end transport
Transport Layer 3-7
Chapter 3 outline
3.1 Transport-layer services3.2 Multiplexing and demultiplexing3.3 Connectionless transport: UDP3.4 Principles of reliable data transfer
3.5 Connection-oriented transport: TCP
segment structurereliable data transferflow controlconnection management
3.6 Principles of congestion control3.7 TCP congestion control
Transport Layer 3-8
Multiplexing/demultiplexing
delivering received segments tothe correct socket
Demultiplexing at rcv host:gathering data from multiple sockets, enveloping data with header (later used for demultiplexing)
Multiplexing at send host:
Transport Layer 3-9
How demultiplexing workshost receives IP datagrams
each datagram has source IP address & destination IP addresseach datagram carries 1 transport-layer segmenteach segment has 16-bit source & destination port numbers
host uses IP addresses & port numbers to direct segment to appropriate socket
TCP/UDP segment format
IANA (Internet Assigned Number Authority) Port Number ranges
Transport Layer 3-10
Connectionless demultiplexingCreate sockets with port numbers:
DatagramSocket clientSocket = new DatagramSocket();(typically, client port number is automatically assigned)
DatagramSocket serverSocket = new DatagramSocket(46428);(server port number specifically assigned by developer)
UDP socket identified by two-tuple: (dest IP address, dest port number)When host receives UDP segment:
checks destination port number in segmentdirects UDP segment to socket with that port number
IP datagrams with different source IP addresses and/or source port numbers may be directed to the same destination socketWhy do we need the source port number for?
Transport Layer 3-11
Connectionless demux (cont)DatagramSocket serverSocket = new DatagramSocket(46428);
Transport Layer 3-12
Connection-oriented demuxTCP socket identified by 4-tuple:
source IP addresssource port numberdestination IP addressdestination port number
recall that the TCP socket is a two-ended “pipe”destination 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
Transport Layer 3-13
Connection-oriented demux (cont)
Transport Layer 3-14
Chapter 3 outline
3.1 Transport-layer services3.2 Multiplexing and demultiplexing3.3 Connectionless transport: UDP3.4 Principles of reliable data transfer
3.5 Connection-oriented transport: TCP
segment structurereliable data transferflow controlconnection management
3.6 Principles of congestion control3.7 TCP congestion control
Transport Layer 3-15
UDP: User Datagram Protocol [RFC 768]
“no frills,” “bare bones”Internet transport protocol“best effort” service, UDP segments may be:
lostdelivered out of order to app
connectionless:no handshaking between UDP sender, receivereach UDP segment handled independently of the others
Why is there a UDP?faster: less overhead
no connection establishment, which can add delaysmall segment headerno congestion control: UDP can blast away as fast as desired
simpler: less resource usageno connection state at sender or receiver hostsmore clients per server
finer control by application:what data is sent and whenadd more features as needed
Transport Layer 3-16
UDP: moreoften used for streaming multimedia apps
loss tolerantrate sensitive
other UDP usesDNS: for faster responseSNMP: usually needed when network is stressed out
reliable transfer over UDP: add reliability at app layerapplication-specific error recovery!
problems with UDP:no congestion control
• high UDP packet loss rates• crowding out TCP sessions
source port # dest port #
32 bits
Applicationdata
(message)
UDP segment format
length checksum
Length, inbytes of
UDPsegment,including
header
Transport Layer 3-17
UDP checksum
Sender:treat segment contents as sequence of 16-bit integerschecksum: addition (1’s complement sum) of segment contentssender puts checksum value into UDP checksum field
Receiver:compute checksum of received segmentcheck if computed checksum equals checksum field value:
NO - error detectedYES - no error detected. But maybe errors nonetheless?
• some even number of flipped bits
• synchronous errors (e.g. same bit in two segments)
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
Transport Layer 3-18
Internet Checksum ExampleNote
When adding numbers, a carryout from the most significant bit needs to be added to the result
Example: add two 16-bit integers
1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
wraparound
sumchecksum
Transport Layer 3-19
Why error detection in UDP?
no guarantee that all links in between will provide error checkingbit errors may happen at the router’s buffer rather than during transferend-to-end principle in system design
in case of segment error detected, damaged segment may be either:
discarded, orpassed to the application with warning
Transport Layer 3-20
Chapter 3 outline
3.1 Transport-layer services3.2 Multiplexing and demultiplexing3.3 Connectionless transport: UDP3.4 Principles of reliable data transfer
3.5 Connection-oriented transport: TCP
segment structurereliable data transferflow controlconnection management
3.6 Principles of congestion control3.7 TCP congestion control
Transport Layer 3-21
Principles of Reliable data transferimportant in application, transport, and link layerstop-10 list of important networking topics!
characteristics of the unreliable channel will determine the complexity of the reliable data transfer protocol (rdt)
Transport Layer 3-22
Reliable data transfer: getting started
sendside
receiveside
rdt_send(): called from above, (e.g., by app.). Passed data to
deliver to receiver upper layer
udt_send(): called by rdt,to transfer packet over
unreliable channel to receiver
rdt_rcv(): called when packet arrives on rcv-side of channel
deliver_data(): called by rdt to deliver data to upper
Transport Layer 3-23
Reliable data transfer: getting startedWe’ll:
incrementally develop the sender and receiver sides of the reliable data transfer protocol (rdt)consider only unidirectional data transfer
but control info will flow on both directions!use finite state machines (FSM) to specify the sender and receiver
state1
state2
event causing state transitionactions taken on state transition
state: when in this “state”, the next state is uniquely determined by the next event
eventactions
Transport Layer 3-24
Rdt1.0: reliable transfer over a reliable channel (the trivial case)
the underlying channel is perfectly reliableno bit errorsno loss of packets
separate FSMs for the sender and receiver:sender sends data into underlying channelreceiver read data from underlying channel
Wait for call from above packet = make_pkt(data)
udt_send(packet)
rdt_send(data)extract (packet,data)deliver_data(data)
Wait for call from
below
rdt_rcv(packet)
sender receiver
Transport Layer 3-25
Rdt2.0: channel with bit errorsthe underlying channel may flip some bits in the packet
add a checksum to detect bit errorsthe question is: how to recover from errors?
acknowledgements (ACKs): the receiver explicitly tells the sender that the packet has been received OKnegative acknowledgements (NAKs): the receiver explicitly tells the sender that the packet had errorsthe sender retransmits the packet on the receipt of a NAK
new mechanisms in rdt2.0 (beyond rdt1.0):error detectionreceiver feedback: control msgs (ACK,NAK) receiver senderretransmission of packets in error
reliable data transfer protocols that are based on retransmission are called ARQ (Automatic Repeat reQuest) protocols
Transport Layer 3-26
rdt2.0: FSM specification
Wait for call from above
sndpkt = make_pkt(data, checksum)udt_send(sndpkt)
extract(rcvpkt,data)deliver_data(data)udt_send(ACK)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&isNAK(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
Wait for ACK or
NAK
Wait for call from
belowsender
receiverrdt_send(data)
Λ
Transport Layer 3-27
rdt2.0: operation with no errors
Wait for call from above
snkpkt = make_pkt(data, checksum)udt_send(sndpkt)
extract(rcvpkt,data)deliver_data(data)udt_send(ACK)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&isNAK(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
Wait for ACK or
NAK
Wait for call from
below
rdt_send(data)
Λ
Transport Layer 3-28
rdt2.0: error scenario
Wait for call from above
snkpkt = make_pkt(data, checksum)udt_send(sndpkt)
extract(rcvpkt,data)deliver_data(data)udt_send(ACK)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&isNAK(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
Wait for ACK or
NAK
Wait for call from
below
rdt_send(data)
Λ
Transport Layer 3-29
rdt2.0 has a fatal flaw!What happens if ACK/NAK
is corrupted?the sender doesn’t know what happened at the receiver!if it just retransmits, this may possibly cause packet duplication at the receiver
the problem is that the receiver doesn’t know whether the ACK/NAK has been delivered correctly!is the arriving packet carrying new data or is it a retransmission?
Handling duplicates: sender retransmits the current packet if ACK/NAK is garbledsender adds a sequence numberto each packetreceiver discards (doesn’t deliver up) the duplicate packet
the sender sends one packet, then waits for the receiver’s response
stop and wait
Transport Layer 3-30
rdt2.1: sender, handles garbled ACK/NAKs
Wait for call 0 from
above
sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)
rdt_send(data)
Wait for ACK or NAK 0 udt_send(sndpkt)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )
sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)
rdt_send(data)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)
Wait forcall 1 from
above
Wait for ACK or NAK 1
ΛΛ
If ACK is corrupt or negative, then retransmit
Otherwise, wait for the next call for packet with different sequence number
Transport Layer 3-31
rdt2.1: receiver, handles garbled ACK/NAKs
Wait for 0 from below
sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)
rdt_rcv(rcvpkt) && not corrupt(rcvpkt) &&has_seq0(rcvpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)
extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
Wait for 1 from below
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt)
extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
rdt_rcv(rcvpkt) && not corrupt(rcvpkt) &&has_seq1(rcvpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)
sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)
previous packet is received again (i.e.; the previous ACK/NAK is corrupt). Therefore, resend the ACK
Transport Layer 3-32
rdt2.1: discussion
Sender:a sequence number is added to the packettwo sequence numbers (0,1) will suffice. Why?must check if the received ACK/NAK is corrupted twice as many states
state must “remember”whether the “current”packet has a sequence number of 0 or 1
Receiver:must check if the received packet is a duplicate
the state indicates whether the expected sequence number of the next packet is 0 or 1
note: the receiver does notknow whether its last ACK/NAK was received OK at the sender
Transport Layer 3-33
rdt2.2: a NAK-free protocol
rdt2.2 has the same functionality as rdt2.1 except that it is using only ACKs (i.e.; no NAKs)
instead of sending a NAK, the receiver sends an ACK for the last packet that was received OK
the receiver must explicitly include the sequence number of the packet being ACKed
the duplicate ACK at the sender results in the same action as the NAK (i.e.; retransmit the current packet)
Transport Layer 3-34
rdt2.2: sender, receiver fragments
Wait for call 0 from above
sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)
Wait for ACK
0
sender FSMfragment
Wait for 0 from below
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)
extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK1, chksum)udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) ||
has_seq1(rcvpkt))
udt_send(sndpkt)
receiver FSMfragment
Λ
The last good packet had seq #1. Retransmit
Transport Layer 3-35
rdt3.0: channels with errors and lossNew assumption:
the underlying channel can also lose packets (data or ACKs)
checksum, sequence numbers, ACKs, and retransmissions will be of help, but will not be enough
Approach:the sender waits a “reasonable” amount of time for the ACKretransmits if no ACK is received within this timeif the packet (or ACK) is just delayed (not lost):
the retransmission will be a duplicate, but the use of sequence numbers already handles this issuethe receiver must specify the sequence number of the packet being ACKed
this requires a countdown timer
Transport Layer 3-36
rdt3.0 sendersndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)start_timer
rdt_send(data)
Wait for
ACK0
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,1) )
Wait for call 1 from
above
sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)start_timer
rdt_send(data)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,0) )
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1)
stop_timerstop_timer
udt_send(sndpkt)start_timer
timeout
udt_send(sndpkt)start_timer
timeout
rdt_rcv(rcvpkt)
Wait for call 0 from
above
Wait for
ACK1
Λrdt_rcv(rcvpkt)
ΛΛ
Λ
Duplicate ACK delayed ACK or
premature timer
Transport Layer 3-37
rdt3.0 in action
Transport Layer 3-38
rdt3.0 in action
Transport Layer 3-39
rdt3.0: stop-and-wait operation
last packet bit transmitted, t = L / R
first packet bit transmitted, t = 0
sender receiver
RTTfirst packet bit arriveslast packet bit arrives, send ACK
ACK arrives, send next packet, t = RTT + L / R
U sender =
.00830.008
= 0.00027 L / R RTT + L / R
=
effective transmission time
total timeutilization of the sender
U sender: utilization – fraction of time sender busy sending
Transport Layer 3-40
Performance of rdt3.0
rdt3.0 works, but performance is very badexample: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:
Ttransmit = 8kb/pkt10**9 b/sec = 8 microsec
1KB pkt every 30 msec 267 Kbps throughput over 1 Gbps linkin this case, the network protocol limits the use of the physical resources!
U sender =
.00830.008
= 0.00027 L / R RTT + L / R
=
L (packet length in bits)R (transmission rate, bps) =
Transport Layer 3-41
Pipelined protocolsPipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged
packetsrange of sequence numbers must be increasedbuffering at sender and/or receiver must be added
Two generic forms of pipelined protocols:Go-Back-N (GBN)Selective Repeat (SR)
Transport Layer 3-42
Pipelining: increased utilization
first packet bit transmitted, t = 0
sender receiver
RTT
last bit transmitted, t = L / R
first packet bit arriveslast packet bit arrives, send ACK
ACK arrives, send next packet, t = RTT + L / R
last bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACK
U sender =
.02430.008
= 0.0008 3 * L / R RTT + L / R
=
Increase utilizationby a factor of 3!
Transport Layer 3-43
Go-Back-N (GBN): Sliding Window ProtocolSender:
add a k-bit sequence # in the packet header“sliding window” of up to N, consecutive unacknowledged packets allowed
ACK(n): indicates that all packets up to and including seq # n have been acknowledged – this is called “cumulative ACK”timer for the first un-ACK packet (first in the window)timeout(n): retransmit packet n and all higher seq # packets in the window
Transport Layer 3-44
GBN: sender extended FSM
Wait start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])…udt_send(sndpkt[nextseqnum-1])
timeout
rdt_send(data)
if (nextseqnum < base+N) {sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)udt_send(sndpkt[nextseqnum])if (base == nextseqnum)
start_timernextseqnum++}
elserefuse_data(data)
base = getacknum(rcvpkt)+1If (base == nextseqnum)
stop_timerelse
start_timer
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
base=1nextseqnum=1
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
Λ
Keep track of the oldest un-ACK packet (1st in window). One timer for all.
No more un-ACK packets left
Λ
Transport Layer 3-45
GBN: receiver extended FSMonly send ACK for correctly-received packet with highest in-order seq #
may generate duplicate ACKsneed only remember expectedseqnum
packet are delivered in orderout-of-order packet:
discard (don’t buffer) -> no receiver buffering!re-ACK packet with highest in-order seq #
Wait
udt_send(sndpkt)default
rdt_rcv(rcvpkt)&& notcurrupt(rcvpkt)&& hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(expectedseqnum,ACK,chksum)udt_send(sndpkt)expectedseqnum++
expectedseqnum=0sndpkt =
make_pkt (2k-1,ACK,chksum)
Λ
Transport Layer 3-46
GBN in action (window size = 4)
Transport Layer 3-47
Performance issues of GBN protocolgood out-of-order packets are discarded by the receiver and then retransmitted!!
however, this simplifies the receiver design• no buffering• only keep track of the “expectedseqnum” variable
Performance problems when:window size and bandwidth-delay product are big
• many packets may be in the pipelinea single error causes a retransmission of large number of all previously un-ACK packetsas the packet error probability increases, the pipeline will be more filled
Transport Layer 3-48
Selective Repeat
the receiver individually acknowledges all correctly received packets
buffers packets, as needed, for eventual in-order delivery to the upper layer
the sender only resends the packets for which the ACK has not been received
a sender timer is needed for each unACKed packetsender window
N consecutive seq #’sagain limits seq #’s of sent, unACKed pakets
Transport Layer 3-49
Selective repeat: sender, receiver windows
Transport Layer 3-50
Selective repeat
data from above :if next available seq # is within window, send packet
timeout(n):resend packet n and restart the timer
ACK(n) in [sendbase,sendbase+N-1]:
mark packet n as receivedif n is the smallest unACKedpacket, advance window base to next unACKed seq #
senderpkt n in [rcvbase, rcvbase+N-1]
send ACK(n)if out-of-order, buffer itif in-order, deliver it (also deliver buffered, in-order pkts), advance window to next not-yet-received pkt
pkt n in [rcvbase-N,rcvbase-1]
ACK(n) (why??)otherwise:
ignore (why??)
receiver
Transport Layer 3-51
Selective repeat in action
Transport Layer 3-52
Selective repeat:dilemma
Example: seq #’s: 0, 1, 2, 3window size=3
receiver sees no difference in two scenarios!incorrectly passes duplicate data as new in (a)
Q: what relationship between seq # size and window size?
Transport Layer 3-53
Chapter 3 outline
3.1 Transport-layer services3.2 Multiplexing and demultiplexing3.3 Connectionless transport: UDP3.4 Principles of reliable data transfer
3.5 Connection-oriented transport: TCP
segment structurereliable data transferflow controlconnection management
3.6 Principles of congestion control3.7 TCP congestion control
Transport Layer 3-54
TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581
full duplex data:bi-directional data flow in same connection
connection-oriented:3-way handshaking (exchange of control msgs) initializes sender and receiver states before the data exchange
flow controlled:the sender will not overwhelm the receiver
logical point-to-point:one sender, one receiver
reliable, in-order byte steam:MSS: Maximum Segment Size (max application msg size)MTU: Maximum Trans. Unit (max. data-link frame length)
pipelined:TCP congestion and flow control set the window size
send & receive buffers
socketdoor
TCPsend buffer
TCPreceive buffer
socketdoor
segment
applicationwrites data
applicationreads data
Transport Layer 3-55
TCP segment structure
source port # dest port #
32 bits
applicationdata
(variable length)
sequence numberacknowledgement number
Receive windowUrg data pointerchecksum
FSRPAUheadlen
notused
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)
the # bytes the receiver is willingto accept (used for flow control)
Counting by the # of bytes of data (not segments!)
Internetchecksum
(as in UDP)
Transport Layer 3-56
Numbering Bytes in TCPExample:
File size = 500,000 bytesMMS = 1,000 bytes 500 segmentsFirst byte number = 0 (typically randomly selected)First segment sequence number = 0Second segment sequence number = 1000Last segment sequence number = 499,000
Transport Layer 3-57
TCP seq. #’s and ACKsSeq. #’s:
is the byte stream “number” of first byte in segment’s data
ACKs:the seq # of the next byte expected from the other sidecumulative ACKACK can be Piggybackedon data segment
Q: how does the receiver handle out-of-order segments
A: TCP spec doesn’t specify. It leaves it up to implementer
Transport Layer 3-58
Chapter 3 outline
3.1 Transport-layer services3.2 Multiplexing and demultiplexing3.3 Connectionless transport: UDP3.4 Principles of reliable data transfer
3.5 Connection-oriented transport: TCP
segment structurereliable data transferflow controlconnection management
3.6 Principles of congestion control3.7 TCP congestion control
Transport Layer 3-59
TCP reliable data transfer
TCP creates rdt service on top of IP’s unreliable service
Pipelined segments
Cumulative Ack’s
TCP uses single retransmission timer
Retransmissions are triggered by:
timeout eventsduplicate Ack’s
Initially consider a simplified TCP sender:
ignore duplicate Ack’signore flow control, congestion control
Transport Layer 3-60
TCP sender events:data received from application:
create segment with the next seq #the seq # is the byte-stream number of first data byte in segmentstart the timer if not already running (a timer for the oldest unAck’edsegment)expiration interval:TimeOutInterval
timeout:retransmit the segment that caused the timeoutrestart the timer
Ack recieved:if it Acknowledges previously unAck’edsegments
update what is known to be acknowledgedstart timer if there are outstanding segments
Transport Layer 3-61
TCP sender(simplified)
NextSeqNum = InitialSeqNumSendBase = InitialSeqNum
loop (forever) {switch(event)
event: data received from application above create TCP segment with sequence number NextSeqNumif (timer currently not running)
start timerpass segment to IP NextSeqNum = NextSeqNum + length(data)
event: timer timeoutretransmit not-yet-acknowledged segment with
smallest sequence numberstart timer
event: ACK received, with ACK field value of y if (y > SendBase) {
SendBase = yif (there are currently not-yet-acknowledged segments)
start timer }
} /* end of loop forever */
Comment:• SendBase-1: last cumulatively ack’ed byte
Transport Layer 3-62
TCP: retransmission scenariosHost A
Seq=100, 20 bytes data
ACK=100
timepremature timeout
Host B
Seq=92, 8 bytes data
ACK=120
Seq=92, 8 bytes data
Seq=
92 t
imeo
ut
ACK=120
Host A
Seq=92, 8 bytes data
ACK=100
loss
tim
eout
lost ACK scenario
Host B
X
Seq=92, 8 bytes data
ACK=100
time
SendBase = 100
SendBase = 120
SendBase = 120
Sendbase = 100
Transport Layer 3-63
TCP retransmission scenarios (more)Host A
Seq=92, 8 bytes data
ACK=100
loss
tim
eout
Cumulative ACK scenario
Host B
X
Seq=100, 20 bytes data
ACK=120
time
SendBase = 120
Doubling Timeout Interval:Congestion happens when a router receives too many packets that start filling the queue and causing drop outs or extended delaysTimeout is most likely caused by traffic congestionWhenever a timeout occurs, the timeout interval is doubled (exponentially grows)
Limited form of congestion control
This applies to current segment only.
Transport Layer 3-64
TCP ACK generation [RFC 1122, RFC 2581]
Event at Receiver
Arrival of in-order segment withexpected seq #. All data up toexpected seq # already ACKed
Arrival of in-order segment withexpected seq #. One other segment has ACK pending
Arrival of out-of-order segmenthigher-than-expect seq. # .Gap detected
Arrival of segment that partially or completely fills gap
TCP Receiver action
Delayed ACK. Wait up to 500msfor 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 thatsegment starts at lower end of gap
Transport Layer 3-65
Fast Retransmit
Time-out period is often relatively long:
there is a long delay before resending a lost packet
Detect lost segments via duplicate ACKs.
Sender often sends many segments back-to-backIf a segment is lost, there will likely be many duplicate ACKs.
If the sender receives 3 ACKs for the same data, it supposes that the segment after the ACKed data was lost:
fast retransmit: resend the segment before the timer expires
Transport Layer 3-66
event: ACK received, with ACK field value of y if (y > SendBase) {
SendBase = yif (there are currently not-yet-acknowledged segments)
start timer }
else { increment count of dup ACKs received for yif (count of dup ACKs received for y = 3) {
resend segment with sequence number y}
Fast retransmit algorithm:
a duplicate ACK for already ACKed segment
fast retransmit
Transport Layer 3-67
IS TCP RDT GBN or SR Protocol?cumulative ACK (GBN)single timer for oldest unACK segment (GBN)mostly buffers good but out-of-order segments (SR)Retransmit only one segment (SR)
Result: TCP RDT is an enhanced hybrid of GBN and SR
Transport Layer 3-68
Chapter 3: Summaryprinciples behind transport layer services:
multiplexing, demultiplexingreliable data transferflow controlcongestion control
instantiation and implementation in the Internet
UDPTCP
Next:leaving the network “edge” (application, transport layers)into the network “core”