Transport Layer 3-2 Chapter 3: Transport Layer our goals:
understand principles behind transport layer services:
multiplexing, demultiplexing reliable data transfer flow control
congestion control learn about Internet transport layer protocols:
UDP: connectionless transport TCP: connection-oriented reliable
transport TCP congestion control
Slide 3
Transport Layer 3-3 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
Slide 4
Transport Layer 3-4 Transport services and protocols provide
logical (instead of physical!) 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 application transport network data link physical
logical end-end transport application transport network data link
physical
Slide 5
Transport Layer 3-5 Transport vs. network layer network layer:
logical communication between hosts transport layer: logical
communication between processes relies on & enhances network
layer services 12 kids in Anns house sending letters to 12 kids in
Bills house: hosts = houses processes = kids app messages = letters
in envelopes transport protocol = Ann and Bill collect
from/distribute to in-house siblings each week => give to/get
from postal service mail carrier network-layer protocol = postal
service household analogy:
Slide 6
Transport Layer 3-6 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
Slide 7
Transport Layer 3-7 Multiplexing/demultiplexing process socket
use header info to deliver received segments to correct socket
(Bill receives batch of mails from carrier and delivers to his
brothers and sister) demultiplexing at receiver: handle data from
multiple sockets, add transport header (later used for
demultiplexing) multiplexing at sender: transport application
physical link network P2P1 transport application physical link
network P4 transport application physical link network P3
Slide 8
Transport Layer 3-8 How demultiplexing works host receives IP
datagrams each datagram has source IP address, destination IP
address each datagram carries one 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 (payload) other header
fields TCP/UDP segment format Remark: we call packets of the
network layer DATAGRAMS and packets of the transport layer are
called SEGMENTS
Slide 9
Transport Layer 3-9 Connectionless demultiplexing when host
receives UDP segment: checks destination port # in segment directs
UDP segment to socket with that port # recall: when creating
datagram to send into UDP socket, one must specify destination IP
address destination port # port number is typically assigned autom.
in client app IP datagrams with same dest. port # and same
destination IP address, but different source IP addresses and/or
source port numbers will be directed to same socket at
destination
Slide 10
Transport Layer 3-10 Connectionless demux: example P1: port
number 6428 transport application physical link network P3
transport application physical link network P1 transport
application physical link network P4 P4: port number 5775 P3: port
number 9157 UDP segm source port: 9157 dest port: 6428 UDP segm
source port: 6428 dest port: 9157 UDP segm source port: 6428 dest
port: 5775 UDP segm source port: 5775 dest port: 6428
Slide 11
Transport Layer 3-11 Connection-oriented demux TCP socket
identified by 4-tuple: source IP address source port number dest IP
address dest port number demux: receiver 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
Slide 12
Transport Layer 3-12 Connection-oriented demux: example
transport application physical link network P1 transport
application physical link P4 transport application physical link
network P2 TCP segm source IP,port: A,9157 dest IP, port: B,80 TCP
segm source IP,port: B,80 dest IP,port: A,9157 host: IP address A
host: IP address C network P6 P5 P3 TCP segm source IP,port: C,5775
dest IP,port: B,80 TCP segm source IP,port: C,9157 dest IP,port:
B,80 three segments, all destined to IP address: B, dest port: 80
are demultiplexed to different sockets (different source IP/source
port number!); one process per connection socket server: IP address
B
Slide 13
Transport Layer 3-13 Connection-oriented demux: example
transport application physical link network P1 transport
application physical link transport application physical link
network P2 TCP segm source IP,port: A,9157 dest IP, port: B,80 TCP
segm source IP,port: B,80 dest IP,port: A,9157 host: IP address A
host: IP address C network P3 TCP segm source IP,port: C,5775 dest
IP,port: B,80 TCP segm source IP,port: C,9157 dest IP,port: B,80
three segments, all destined to IP address: B, dest port: 80 are
demultiplexed to different sockets (different source IP/source port
number!); one THREAD per connection socket server: IP address B P4
threaded server
Slide 14
Transport Layer 3-14 Connection-oriented demux: example
transport application physical link network P1 transport
application physical link transport application physical link
network P2 TCP segm source IP,port: A,9157 dest IP, port: B,80 TCP
segm source IP,port: B,80 dest IP,port: A,9157 host: IP address A
host: IP address C network P3 TCP segm source IP,port: C,5775 dest
IP,port: B,80 TCP segm source IP,port: C,9157 dest IP,port: B,80
Note: during persisent HTTP, same server socket it used during
non-persistent HTTP, new TCP connection (=> new socket) for
every request/response server: IP address B P4 threaded server
Slide 15
Transport Layer 3-15 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
Slide 16
Transport Layer 3-16 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 UDP use: streaming
multimedia (loss tolerant, rate sensitive) DNS Internet phone
real-time video conferencing reliable transfer over UDP: add
reliability at application layer application-specific error
recovery!
Slide 17
Transport Layer 3-17 UDP: segment header source port #dest port
# 4 x 16 bits = 4 x 2 bytes application data (payload) UDP segment
format length checksum length: in bytes of UDP segment, including
header; max. 16 bits => length of data field
Transport Layer 3-18 UDP checksum sender: add IP pseudo header
(transport layer must inform network layer about destination =>
certain information known); later real IP header is generated treat
segment contents, including header fields, as sequence of 16-bit
integers checksum: addition of segment contents and ones complement
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 => pass damaged
segment to app with warning or discard it YES - no error detected.
But maybe errors nonetheless? More later . Goal: detect errors
(e.g., flipped bits) in transmitted segment
Slide 19
Transport Layer 3-19 Internet checksum: example example: add
two 16-bit integers 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 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 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 wraparound
sum checksum Note: when adding numbers, a carryout from the most
significant bit needs to be added to the result RFC 768
Slide 20
Transport Layer 3-20 Internet checksum Why do we have to add
the carry from the most significant bit? 4-Bit example: we want to
add -5 and -3 in 1s complement arithmetic +5 is 0101 => -5 is
1010 +3 is 0011 => -3 is 1100 1010 + 1100 = (ignoring the carry)
0110 (which is -9) = (with carry) 0111 (which is -8)
Slide 21
Transport Layer 3-21 Internet checksum Why is the checksum
calculated like this? Use notation [a,b] for 16-bit integer a 2 8
+b, where a and b are bytes checksum computation corresponds to
[A,B] +' [C,D] +'... +' [Y,Z] where +' is1's complement addition 1s
complement addition has nice properties: - associative property: (
[A,B] +' [C,D] +'... +' [J,0] ) +' ( [0,K] +'... +' [Y,Z] ) -
commutative property: ( [0,K] +'... +' [Y,Z] ) + ( [A,B] +' [C,D]
+'... +' [J,0] ) - byte order independence: [B,A] +' [D,C] +'... +'
[Z,Y] - allows parallel summation (efficient implementation: see
RFC 1071)
Slide 22
Transport Layer 3-22 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
Slide 23
Transport Layer 3-23 Reliable data transfer protocols send side
receive side rdt_send(): called from above, (e.g., by app.). Passes
data to deliver to receiver at 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
(receive function of the abstract rdt protocol) deliver_data():
called by rdt to deliver data to upper imagine the following
(abstract) data transfer protocol: some abstract upper layer
Slide 24
Transport Layer 3-24 well: incrementally develop sender and
receiver sides of 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
behavior of sender and receiver state 1 state 2 event causing state
transition actions taken on state transition state: when in this
state next state uniquely determined by next event event actions
Reliable data transfer: getting started
Slide 25
Transport Layer 3-25 rdt1.0: reliable transfer over a reliable
channel underlying channel perfectly reliable no bit errors no loss
of packets separate FSMs for sender and receiver: sender sends data
into underlying channel receiver reads 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
Slide 26
Transport Layer 3-26 underlying channel may flip bits in packet
checksum to detect bit errors the question: how to recover from
errors: acknowledgements (ACKs): receiver explicitly tells sender
that pkt received OK negative acknowledgements (NAKs): receiver
explicitly tells sender that pkt had errors sender retransmits pkt
on receipt of NAK new mechanisms in rdt2.0 (beyond rdt1.0 ): error
detection receiver feedback: control msgs (ACK,NAK) rcvr-
>sender rdt2.0: channel with bit errors How do humans recover
from errors during conversation?
Slide 27
Transport Layer 3-27 underlying channel may flip bits in packet
checksum to detect bit errors the question: how to recover from
errors: acknowledgements (ACKs): receiver explicitly tells sender
that pkt received OK negative acknowledgements (NAKs): receiver
explicitly tells sender that pkt had errors sender retransmits pkt
on receipt of NAK new mechanisms in rdt2.0 (beyond rdt1.0 ): error
detection feedback: control msgs (ACK,NAK) from receiver to sender
rdt2.0: channel with bit errors
Slide 28
Transport Layer 3-28 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 below sender
receiver rdt_send(data) stop and wait sender sends one packet, then
waits for receiver response
Slide 29
Transport Layer 3-29 rdt2.0 has a fatal flaw! what happens if
ACK/NAK corrupted? sender doesnt know what happened at receiver!
cant just retransmit: possible duplicate handling duplicates:
sender retransmits current pkt if ACK/NAK corrupted sender adds
sequence number to each pkt receiver discards (doesnt deliver up)
duplicate pkt
Slide 30
Transport Layer 3-30 rdt2.1: sender handles corrupted 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 for call 1 from above Wait for ACK or NAK 1
sequence numbers 0 and 1
Transport Layer 3-32 rdt2.1: discussion sender: seq # added to
pkt two seq. #s (0,1) will suffice since receiver can distinguish
detect retransmission must check if received ACK/NAK corrupted
twice as many states state must remember whether expected ACK is
for seq # of 0 or 1 receiver: must check if received packet is
duplicate state indicates whether 0 or 1 is expected pkt seq #
note: receiver can not know if its last ACK/NAK received OK at
sender
Slide 33
Transport Layer 3-33 rdt2.2: a NAK-free protocol same
functionality as rdt2.1, using ACKs only instead of NAK, receiver
sends ACK for last packet received OK (=> may ACK same paket
several times) receiver must explicitly include seq # of packet
being ACKed duplicate ACK at sender results in same action as NAK:
retransmit current packet
Slide 34
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 FSM fragment rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data)
deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt)
Wait for 0 from below rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
|| has_seq1(rcvpkt)) udt_send(sndpkt) receiver FSM fragment
Slide 35
Transport Layer 3-35 rdt3.0: channels with errors and loss new
assumption: underlying channel can also lose packets (data, ACKs)
checksum, seq. #, ACKs, retransmissions will be of help but not
enough approach: sender waits reasonable amount of time for ACK
retransmits if no ACK received in this time if pkt (or ACK) just
delayed (not lost): retransmission will be duplicate, but seq. #s
already handles this receiver must specify seq # of pkt being ACKed
requires countdown timer
Slide 36
Transport Layer 3-36 rdt3.0 sender sndpkt = 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_timer udt_send(sndpkt) start_timer timeout
udt_send(sndpkt) start_timer timeout rdt_rcv(rcvpkt) Wait for call
0from above Wait for ACK1 rdt_rcv(rcvpkt) receiver FSM is homework
(do it at home and compare your solution to our solution during the
tutorial)
Transport Layer 3-39 Performance of rdt3.0 rdt3.0 is correct,
but performance is slow e.g.: 1 Gbps link (10 9 bits/sec), from US
west to east coast 15 ms prop. delay (RRT=30 ms=30/1000 sec), 8000
bit packet: Calculate U sender : utilization fraction of time
sender busy sending D trans = L R 8000 bits 10 9 bits/sec ==.008
ms
Slide 40
Transport Layer 3-40 rdt3.0: stop-and-wait operation first
packet bit transmitted, t = 0 senderreceiver RTT last packet bit
transmitted, t = L / R first packet bit arrives last packet bit
arrives, send ACK ACK arrives, send next packet, t = RTT + L / R
assume no transmission delay for ACK percentage of time the server
is busy (with transmitting)
Slide 41
Transport Layer 3-41 Performance of rdt3.0 rdt3.0 is correct,
but performance is slow e.g.: 1 Gbps link (10 9 bits/sec), from US
west to east coast 15 ms prop. delay (RRT=30 ms=30/1000 sec), 8000
bit packet: U sender : utilization fraction of time sender busy
sending throughput = utilization x net bitrate = 270 000 bits/sec
34kB/sec throughput over 1 Gbps link receiver has very slow
download rate from that server! D trans = L R 8000 bits 10 9
bits/sec ==.008 ms
Slide 42
Transport Layer 3-42 Pipelined protocols pipelining: sender
allows multiple, yet-to-be- acknowledged packets range of sequence
numbers must be increased buffering at sender and/or receiver two
generic forms of pipelined protocols: go-Back-N, selective
repeat
Slide 43
Transport Layer 3-43 Pipelining: increased utilization first
packet bit transmitted, t = 0 senderreceiver RTT last bit
transmitted, t = L / R first packet bit arrives last packet bit
arrives, send ACK ACK arrives, send next packet, t = RTT + L / R
last bit of 2 nd packet arrives, send ACK last bit of 3 rd packet
arrives, send ACK 3-packet pipelining increases utilization by a
factor of 3! maximal 3 unacknowledged packets in pipeline
Slide 44
Transport Layer 3-44 Pipelined protocols: overview Go-back-N:
sender can have up to N unack ed packets in pipeline receiver only
sends cumulative ack doesnt ack packet if theres a gap sender has
timer for oldest unacked packet when timer expires, retransmit all
unacked packets Selective Repeat: sender can have up to N unacked
packets in pipeline rcvr sends individual ack for each packet
sender maintains timer for each unacked packet when timer expires,
retransmit only that unacked packet
Slide 45
Transport Layer 3-45 Go-Back-N protocol: sender k-bit seq # in
packet header window of up to N, consecutive unacked packets
allowed ACK(n): ACKs all pkts up to, including seq # n - cumulative
ACK may receive duplicate ACKs (see receiver) monitor timer for
oldest in-flight pkt timeout(n): retransmit packet n and all higher
seq # pkts in window
Slide 46
Transport Layer 3-46 GBN: sender extended FSM (slide is
repaired) Wait restart_timer(base) udt_send(sndpkt[base])
restart_timer(base+1) udt_send(sndpkt[base+1])
restart_timer(nextseqnum-1) udt_send(sndpkt[nextseqnum-1])
Timeout(base) rdt_send(data) if (nextseqnum < base+N) {
sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)
udt_send(sndpkt[nextseqnum]) start_timer(nextseqnum) nextseqnum++ }
else refuse_data(data) base = getacknum(rcvpkt)+1 (drop all timers
with # < base) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
base=1 nextseqnum=1 rdt_rcv(rcvpkt) && corrupt(rcvpkt)
Transport Layer 3-48 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=1 sndpkt =
make_pkt(0,ACK,chksum) GBN: receiver extended FSM initialize:
counter for expected sequence number make initial packet ready for
sending but use seqnum 0 in case that 1 st packet is corrupt or has
wrong number
Slide 49
Transport Layer 3-49 Wait udt_send(sndpkt) default
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) &&
hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data)
deliver_data(data) sndpkt = make_pkt(expectedseqnum,ACK,chksum)
udt_send(sndpkt) expectedseqnum++ expectedseqnum=1 sndpkt =
make_pkt(0,ACK,chksum) GBN: receiver extended FSM if packet arrives
that is not corrupt and has the expected seq number: - extract and
deliver data to layer above -send ack -increase seq number
Slide 50
Transport Layer 3-50 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=1 sndpkt =
make_pkt(0,ACK,chksum) GBN: receiver extended FSM if packet arrives
that is corrupt or has the wrong seq number: resend ack for last
correctly received packet
Slide 51
Transport Layer 3-51 ACK-only: always send ACK for
correctly-received pkt with highest in-order seq # may generate
duplicate ACKs (e.g. if there is a gap) need only remember
expectedseqnum out-of-order pkt: discard (dont 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=1 sndpkt = make_pkt(0,ACK,chksum)
GBN: receiver extended FSM
Transport Layer 3-55 Selective repeat improves GBN by not
retransmitting a large number of packets receiver individually
acknowledges all correctly received packets receiver buffers
packets, as needed, for eventual in- order delivery to upper layer
sender only resends packets for which ACK not received sender has
timer for each unACKed packet (since only a single packet will be
retransmitted on timeout) sender window N consecutive seq #s limits
seq #s of sent, unACKed packets
Slide 56
Transport Layer 3-56 Selective repeat: sender, receiver windows
windows are not synchronized!!
Slide 57
Transport Layer 3-57 Selective repeat data from above: if next
available seq # in window, then send packet timeout(n): resend
packet n, restart timer of packet n ACK(n) in
[sendbase,sendbase+N-1]: mark packet n as received if n smallest
unACKed packet, then advance window base to next unACKed seq #
sender packet n in [rcvbase, rcvbase+N-1] send ACK(n) out-of-order:
buffer in-order: deliver (also deliver buffered, in-order pkts),
advance window to next not-yet-received pkt packet n in
[rcvbase-N,rcvbase-1] ACK(n) since previous ack got lost
receiver
Transport Layer 3-59 Selective repeat: short range of seqnum
example: seq #s: 0, 1, 2, 3 window size=3 receiver window (after
receipt) sender window (after receipt) 0 1 2 3 0 1 2 pkt0 pkt1 pkt2
0 1 2 3 0 1 2 pkt0 timeout retransmit pkt0 0 1 2 3 0 1 2 X X X will
accept packet with seq number 0 (b) oops! 0 1 2 3 0 1 2 pkt0 pkt1
pkt2 0 1 2 3 0 1 2 pkt0 0 1 2 3 0 1 2 X will accept packet with seq
number 0 0 1 2 3 0 1 2 pkt3 (a) no problem receiver cant see sender
side. receiver behavior identical in both cases! somethings (very)
wrong! receiver does not know whether pkt0 is retransmitted or not
duplicate data accepted as new in (b)? Q: what relationship between
seq # range and window size to avoid problem in (b)?
Slide 60
Transport Layer 3-60 Packet Reordering assume now that packets
my be reordered during transmission (since we do not have a single
channel but a network of links) receiver may get packets with
seqnum n where n is neither in senders nor in receivers window
(e.g. delayed ACK => retransmission => windows move further)
duplicate or new data????? sender must be sure that when reusing
seqnum n, a packet with this number is no longer on the way to
receiver Solution: assume that packet cannot live in network longer
than maximum amount of time (e.g. 3 min for TCP)
Slide 61
Transport Layer 3-61 Summary of Reliable Data Transfer
MechanismUse, Comments ChecksumUsed to detect bit errors in
transmitted packet. TimerUsed to retransmit if packet or ACK was
lost (or delayed). Sequence number Sequential numbering of packet
flow. Use gaps to detect lost packets, use duplicate numbers to
detect duplicate packets. Acknow- ledgment Receiver confirms
correctly received packets; contains sequence number; may be
cumulative or individual. (Negative ack- nowledgment) Receiver
tells sender that packet has not been received. Window, pipelining
Sending of packets only in restricted range => increases
utilization of sender compared to stop-and-wait.
Slide 62
Transport Layer 3-62 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
Slide 63
Transport Layer 3-63 TCP: Overview RFCs: 793,1122,1323, 2018,
2581 full duplex data: bi-directional data flow in same connection
MSS: maximum segment size (max amount of data placed in segment);
usually about 1460 B since Ethernet frames typically have 1500
Bytes (TCP/IP header: 40 B) connection-oriented: handshaking
(exchange of control msgs) inits sender, receiver state before data
exchange point-to-point: one sender, one receiver reliable
mechanisms for message loss/ corrupted msgs pipelined: TCP
congestion and flow control set window size flow controlled: sender
will not overwhelm receiver
Slide 64
Transport Layer 3-64 TCP segment structure source port # dest
port # 32 bits application data (variable length) sequence number
acknowledgement number receive window Urg data pointer checksum F
SR PAU head len not used options (variable length) used for (de-
)multiplexing data to/from upper-layer applications
Slide 65
Transport Layer 3-65 TCP segment structure source port # dest
port # 32 bits application data (variable length) sequence number
acknowledgement number receive window Urg data pointer checksum F
SR PAU head len not used options (variable length) error
detection
Slide 66
Transport Layer 3-66 TCP segment structure source port # dest
port # 32 bits application data (variable length) sequence number
acknowledgement number receive window Urg data pointer checksum F
SR PAU head len not used options (variable length) counting by
bytes of data (not segments!); used for implementing a reliable
data transfer service; more details later
Slide 67
Transport Layer 3-67 TCP segment structure source port # dest
port # 32 bits application data (variable length) sequence number
acknowledgement number receive window Urg data pointer checksum F
SR PAU head len not used options (variable length) used for flow
control; indicates number of bytes that receiver is willing to
accept (more details later)
Slide 68
Transport Layer 3-68 TCP segment structure source port # dest
port # 32 bits = 4 bytes application data (variable length)
sequence number acknowledgement number receive window Urg data
pointer checksum F SR PAU head len not used options (variable
length) TCP header length (4 bits); because of options field length
can be greater than 20 bytes 5 rows
Slide 69
Transport Layer 3-69 TCP segment structure source port # dest
port # 32 bits application data (variable length) sequence number
acknowledgement number receive window Urg data pointer checksum F
SR PAU head len not used options (variable length) flag fields (6
bits): A = ACK field acknowledgement number is valid (this msg is
an ACK; used for reliable data transfer!)
Slide 70
Transport Layer 3-70 TCP segment structure source port # dest
port # 32 bits application data (variable length) sequence number
acknowledgement number receive window Urg data pointer checksum F
SR PAU head len not used options (variable length) flag fields (6
bits): R = RST S = SYN F = FIN used for connection setup and
teardown (more details later)
Slide 71
Transport Layer 3-71 TCP segment structure source port # dest
port # 32 bits application data (variable length) sequence number
acknowledgement number receive window Urg data pointer checksum F
SR PAU head len not used options (variable length) flag fields (6
bits): P = PSH field TCP push function for cases where data needs
to be sent immediately (no buffering! sender TCP does not wait for
more data) Examples: - Telnet: want each keystroke to be sent
immed. -HTTP GET request: client has no further data to add and
request should be sent to web daemon immediately (do not wait until
segment filled) -packet containing last bytes of requested file
(for now sender has no further data to transmit)
Slide 72
Transport Layer 3-72 TCP segment structure source port # dest
port # 32 bits application data (variable length) sequence number
acknowledgement number receive window Urg data pointer checksum F
SR PAU head len not used options (variable length) flag fields (6
bits): U = URG field segment contains data that sending site marked
as urgent => urgent data pointer (16 bit) points to last byte of
urgent part in segment (isnt employed much; usually in comb. with
PSH) receiver TCP forwards the urgent data to the process with an
indication that the data is marked as urgent by the sender
Slide 73
Transport Layer 3-73 TCP segment structure source port # dest
port # 32 bits application data (variable length) sequence number
acknowledgement number receive window Urg data pointer 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)
Slide 74
Transport Layer 3-74 TCP seq. numbers, ACKs sequence numbers:
byte stream number of first byte in segments data acknowledgements:
seq # of next byte expected from other side cumulative ACK (=>
acks bytes up to first missing byte in stream) TCP spec doesnt say
how to handle out-of-order segments, - up to implementor (in
practise: receiver buffers and waits for missing bytes to fill
gaps) source port # dest port # sequence number acknowledgement
number checksum rwnd urg pointer incoming segment to sender A sent
ACKed sent, not- yet ACKed (in-flight) usable but not yet sent not
usable window size N sender sequence number space source port #
dest port # sequence number acknowledgement number checksum rwnd
urg pointer outgoing segment from sender
Slide 75
Transport Layer 3-75 TCP seq. numbers, ACKs Example 1: Host A
has received bytes numbered 0-535 from Host B Host A waits for 536
-... puts 536 in ACK number field when it sends next segment to B
Example 2: Host A has received bytes numbered 0-535 from Host B AND
bytes 900-1000 (has not yet received 536 899) Host A waits for 536
- 899 puts 536 in ACK number field when it sends next segment to
B
Slide 76
Transport Layer 3-76 Telnet example User types C host ACKs
receipt of echoed C host ACKs receipt of C, echoes back C each
character typed by user (at client host A) is sent to sever (host
B) and back to be displayed at Telnets user screen (echo back)
=> user sees what has already been processed on remote site Host
B Host A Seq=42, ACK=79, data = C Seq=79, ACK=43, data = C Seq=43,
ACK=80 seqnum at A starts at 42 (waiting for byte 79) seqnum at B
starts at 79 (waiting for byte 42)
Slide 77
Transport Layer 3-77 Telnet example User types C host ACKs
receipt of echoed C host ACKs receipt of C, echoes back C each
character typed by user (at client host A) is sent to sever (host
B) and back to be displayed at Telnets user screen (echo back)
=> user sees what has already been processed on remote site Host
B Host A Seq=42, ACK=79, data = C Seq=79, ACK=43, data = C Seq=43,
ACK=80 seqnum at A starts at 42 (waiting for byte 79) seqnum at B
starts at 79 (waiting for byte 42) because data is 1 byte (header
is not counted)
Slide 78
Transport Layer 3-78 Telnet example User types C host ACKs
receipt of echoed C host ACKs receipt of C, echoes back C each
character typed by user (at client host A) is sent to sever (host
B) and back to be displayed at Telnets user screen (echo back)
=> user sees what has already been processed on remote site Host
B Host A Seq=42, ACK=79, data = C Seq=79, ACK=43, data = C Seq=43,
ACK=80 seqnum at A starts at 42 (waiting for byte 79) seqnum at B
starts at 79 (waiting for byte 42) send data and ack together (ack
is piggybacked)
Slide 79
Transport Layer 3-79 Telnet example User types C host ACKs
receipt of echoed C host ACKs receipt of C, echoes back C each
character typed by user (at client host A) is sent to sever (host
B) and back to be displayed at Telnets user screen (echo back)
=> user sees what has already been processed on remote site Host
B Host A Seq=42, ACK=79, data = C Seq=79, ACK=43, data = C Seq=43,
ACK=80 seqnum at A starts at 42 (waiting for byte 79) seqnum at B
starts at 79 (waiting for byte 42)
Slide 80
Transport Layer 3-80 HTTP example SYN bit = 1 to establish
connection (more details later) => increase sequence number by
one even though no bytes are sent. Note: we use relative seq num
here. When connection is established a random initial number is
chosen.
Slide 81
Transport Layer 3-81 TCP round trip time, timeout Q: how to set
TCP timeout value? longer than connections round- trip time (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 (it is ambiguous whether
the reply was for the first instance of the packet or a later
instance) SampleRTT will vary => use average average several
recent measurements, not just current SampleRTT TCP uses a
timeout/retransmission mechanism (as rdt protocol considered
earlier)
Slide 82
Transport Layer 3-82 EstimatedRTT = (1- )*EstimatedRTT +
*SampleRTT exponential weighted moving average influence of past
sample decreases exponentially fast (why?) typical value: = 0.125
TCP round trip time, timeout RTT (milliseconds) RTT:
gaia.cs.umass.edu to fantasia.eurecom.fr sampleRTT EstimatedRTT
time (seconds)
Slide 83
Transport Layer 3-83 EstimatedRTT = (1- )*EstimatedRTT +
*SampleRTT exponential weighted moving average influence of past
sample decreases exponentially fast (why?) typical value: = 0.125
TCP round trip time, timeout RTT (milliseconds) RTT:
gaia.cs.umass.edu to fantasia.eurecom.fr sampleRTT EstimatedRTT
time (seconds) close to 1 => weighted average immune to changes
that last a short time (e.g., a single segment that encounters long
delay) close to 0 => weighted average respond to changes in
delay very quickly
Slide 84
Transport Layer 3-84 timeout interval: EstimatedRTT plus safety
margin large variation in EstimatedRTT -> larger safety margin
estimate SampleRTT deviation from EstimatedRTT: DevRTT = (1-
)*DevRTT + *|SampleRTT-EstimatedRTT| TCP round trip time, timeout
(typically, = 0.25) TimeoutInterval = EstimatedRTT + 4*DevRTT
estimated RTT safety margin RFC 2988
Slide 85
Transport Layer 3-85 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
Slide 86
Transport Layer 3-86 TCP reliable data transfer TCP creates rdt
service on top of IPs unreliable service pipelined segments
cumulative acks single retransmission timer (not one for each segm)
retransmissions triggered by: timeout events duplicate acks lets
initially consider simplified TCP sender: data transfer in one
direction only ignore duplicate acks ignore flow control,
congestion control assume that data from above is less than
MSS
Slide 87
Transport Layer 3-87 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 ack acknowledges previously unacked segments update what
is known to be ACKed (slide window to the right) (re)start timer if
there are still unacked segments
Slide 88
Transport Layer 3-88 TCP sender (simplified) wait for event
NextSeqNum = InitialSeqNum SendBase = InitialSeqNum create segment,
seq. #: NextSeqNum pass segment to IP (i.e., send) NextSeqNum =
NextSeqNum + length(data) if (timer currently not running) start
timer data received from application above retransmit not-yet-acked
segment with smallest seq. # start timer timeout if (y >
SendBase) { SendBase = y /* SendBase1: last cumulatively ACKed byte
*/ if (there are currently not-yet-acked segments) start timer }
ACK received, with ACK field value y RFC 2988, page 3 hope that gap
is just a single segment
Slide 89
Transport Layer 3-89 TCP sender (simplified) wait for event
NextSeqNum = InitialSeqNum SendBase = InitialSeqNum create segment,
seq. #: NextSeqNum pass segment to IP (i.e., send) NextSeqNum =
NextSeqNum + length(data) if (timer currently not running) start
timer data received from application above retransmit not-yet-acked
segment with smallest seq. # start timer timeout if (y >
SendBase) { SendBase = y /* SendBase1: last cumulatively ACKed byte
*/ if (there are currently not-yet-acked segments) start timer }
ACK received, with ACK field value y RFC 2988, page 4
Slide 90
Transport Layer 3-90 TCP: retransmission scenarios lost ACK
scenario Host B Host A Seq=92, 8 bytes of data ACK=100 Seq=92, 8
bytes of data X timeout ACK=100 premature timeout Host B Host A
Seq=92, 8 bytes of data ACK=100 Seq=92, 8 bytes of data timeout
ACK=120 Seq=100, 20 bytes of data ACK=120 SendBase=100 SendBase=120
SendBase=92 since nextseqnum at A is 100
Slide 91
Transport Layer 3-91 TCP: retransmission scenarios X cumulative
ACK Host B Host A Seq=92, 8 bytes of data ACK=100 Seq=120, 15 bytes
of data timeout Seq=100, 20 bytes of data ACK=120
Slide 92
Transport Layer 3-92 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 receiver is allowed to delay 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 duplicate ACK: an ACK that has been sent before maybe
cumulative ACK possible => increases performance
Slide 93
Transport Layer 3-93 TCP fast retransmit time-out period often
relatively long: long delay before resending lost packet if segment
is lost, there will likely be many duplicate ACKs. if sender
receives 3 ACKs for same data (triple duplicate ACKs), immediately
resend unacked segment with smallest seq # likely that unacked
segment lost, so dont wait for timer to expire TCP fast
retransmit
Slide 94
Transport Layer 3-94 X fast retransmit after sender receipt of
triple duplicate ACK Host B Host A Seq=92, 8 bytes of data ACK=100
timeout ACK=100 TCP fast retransmit Seq=100, 20 bytes of data
Slide 95
Transport Layer 3-95 TCP sender (simplified) wait for event
NextSeqNum = InitialSeqNum SendBase = InitialSeqNum create segment,
seq. #: NextSeqNum pass segment to IP (i.e., send) NextSeqNum =
NextSeqNum + length(data) if (timer currently not running) start
timer data received from application above retransmit not-yet-acked
segment with smallest seq. # start timer timeout if (y >
SendBase) { SendBase = y if (there are currently not-yet-acked
segments) start timer } else { /* duplicate ACK received */
increment number of dupl. ACKs received for y if (number of dupl.
ACKs received for y==3) resend segment with seq. number y } ACK
received, with ACK field value y
Slide 96
Transport Layer 3-96 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
Slide 97
Transport Layer 3-97 TCP flow control receiver controls sender
such that sender wont overflow receivers buffer by transmitting too
much, too fast sender maintains variable called receive window
(rwnd) gives sender an idea of how much buffer space is available
at receiver since TCP is full-duplex, both sides have receive
window variable LastByteRead: number of last byte read by app (on
rcv site) LastByteRcvd: number of last byte in received data stream
rwnd = RcvBuffer [LastByteRcvd - LastByteRead] currently being
buffered on receiver site
Slide 98
Transport Layer 3-98 TCP flow control buffered data free buffer
space rwnd RcvBuffer TCP segment payloads to application process
receiver advertises free buffer space by including rwnd value in
TCP header of receiver-to-sender segments RcvBuffer size set via
socket options (typical default is 4096 bytes) sender limits amount
of unacked (in-flight) data to receivers rwnd value sender
guarantees that receive buffer will not overflow: receiver-side
buffering LastByteSent LastByteAcked rwnd applet:
http://media.pearsoncmg.com/aw/aw_kurose_network_4/applets/flow/FlowControl.htm
Slide 99
Transport Layer 3-99 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
Slide 100
Transport Layer 3-100 Connection Management before exchanging
data, sender/receiver do three-way handshake: => agree to
establish connection (each knowing the other willing to establish
connection) and synchronize seq. numbers Step 1: client send
special TCP segment with SYN flag =1 and initial seq. num.
(client_isn) in seq. num. field Step 2: SYN segm. arrives at server
=> sever allocates TCP buffers and variables and sends SYNACK
segment with (a)SYN and ACK flag =1 (b)ack number field is equal to
client_isn+1 (c)puts own initial seq. num. (server_isn) in seq.
num. field Step 3: Client receives SYNACK segm., allocates buffers
& vars, and sends ACK with ack num (server_isn+1) (which may
already contain app data)
Slide 101
Transport Layer 3-101 TCP 3-way handshake SYNbit=1, Seq=x
choose init seq num, x send TCP SYN msg ESTAB SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1 choose init seq num, y send TCP SYNACK msg,
acking SYN ACKbit=1, ACKnum=y+1 received SYNACK(x) indicates server
is live; send ACK for SYNACK; this segment may contain
client-to-server data received ACK(y) indicates client is live
SYNSENT ESTAB SYN RCVD client state LISTEN server state LISTEN
Slide 102
Transport Layer 3-102 TCP: closing a connection client or
server can start closing of connection host A sends TCP segment
with FIN bit = 1 host B responds to received FIN with ACK host B
also sends FIN (on receiving FIN, ACK can be combined with own FIN)
host A receives FIN and sends final ACK host A waits certain time
in case that last ACK got lost and FIN is resent (=> A will ack
again)
Slide 103
Transport Layer 3-103 FIN_WAIT_2 CLOSE_WAIT FINbit=1, seq=y
ACKbit=1; ACKnum=y+1 ACKbit=1; ACKnum=x+1 wait for server close can
still send data can no longer send data LAST_ACK CLOSED TIMED_WAIT
timed wait (usually 30 sec, 1 min or 2 min) CLOSED TCP: closing a
connection FIN_WAIT_1 FINbit=1, seq=x can no longer send but can
receive data clientSocket.close() client state server state
ESTAB
Slide 104
Transport Layer 3-104 Possible TCP states of client CLOSED
SYN_SENT ESTAB FIN_WAIT_1 FIN_WAIT_2 TIME _WAIT send SYN receive
SYNACK send ACK send FIN receive ACK (send nothing) receive FIN
send ACK wait X seconds
Slide 105
Transport Layer 3-105 Possible TCP states of server CLOSED
LISTEN SYN_RCVD ESTAB CLOSE_WAIT LAST_ACK create listen socket
receive SYN send SYNACK receive ACK (send nothing) receive FIN send
ACK send FIN receive ACK (send nothing) serverPort = 12000
serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind((,serverPort)) serverSocket.listen(1)
Slide 106
Transport Layer 3-106 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
Slide 107
Transport Layer 3-107 congestion: informally: too many sources
sending too much data too fast for network to handle different from
flow control! problems related to congestion: lost packets (buffer
overflow at routers) long delays (queueing in router buffers)
important problem in data networks! Principles of congestion
control
Slide 108
Transport Layer 3-108 Causes/costs of congestion: scenario 1
two senders, two receivers one router, infinite buffers output link
capacity: R no retransmission maximum per-connection throughput:
R/2 unlimited shared output link buffer Host A original data: in
Host B throughput: out R/2 out in R/2 packet delay in large delays
as arrival rate, in, approaches capacity
Slide 109
Transport Layer 3-109 one router, finite buffer sender
retransmission of timed-out packet application-layer sends at rate
in transport-layer includes retransmissions : in in finite shared
output link buffers Host A in : original data Host B out ' in :
original data, plus retransmitted data Causes/costs of congestion:
scenario 2
Slide 110
Transport Layer 3-110 idealization: perfect knowledge sender
sends only when router buffers available (=> no retransmissions)
finite shared output link buffers in : original data out ' in :
original data, plus retransmitted data copy free buffer space! R/2
out in ' in Causes/costs of congestion: scenario 2 Host B A
Slide 111
Transport Layer 3-111 in : original data out ' in : original
data, plus retransmitted data copy no buffer space! Idealization:
known loss packets can be lost, dropped at router due to full
buffers sender only resends if packet known to be lost Causes/costs
of congestion: scenario 2 A Host B
Slide 112
Transport Layer 3-112 in : original data out ' in : original
data, plus retransmitted data free buffer space! Causes/costs of
congestion: scenario 2 Idealization: known loss packets can be
lost, dropped at router due to full buffers sender only resends if
packet known to be lost R/2 in out when sending at R/2, some
packets are retransmissions but asymptotic goodput is still R/2
(only original data leaves router) A Host B
Slide 113
Transport Layer 3-113 A in out ' in copy free buffer space!
timeout R/2 in out when sending at R/2, some packets are
retransmissions including duplicates that are delivered! Host B
Realistic: duplicates packets can be lost, dropped at router due to
full buffers sender times out prematurely, sending two copies, both
of which are delivered Causes/costs of congestion: scenario 2
Slide 114
Transport Layer 3-114 R/2 out when sending at R/2, some packets
are retransmissions including duplicates that are delivered! costs
of congestion: more work (retrans) for given goodput unneeded
retransmissions: link carries multiple copies of pkt decreasing
goodput R/2 in Causes/costs of congestion: scenario 2 Realistic:
duplicates packets can be lost, dropped at router due to full
buffers sender times out prematurely, sending two copies, both of
which are delivered
Slide 115
Transport Layer 3-115 four senders multihop paths
timeout/retransmit R: capa. of router links Q: what happens as in
and in increase in A-C connection ? finite shared output link
buffers Host A out Causes/costs of congestion: scenario 3 Host B
Host C Host D in : original data ' in : original data, plus
retransmitted data A: as red in increases, all arriving blue pkts
at upper queue are dropped, blue throughput 0 blue in-rate at upper
router is at most R blue packets get lost
Slide 116
Transport Layer 3-116 Causes/costs of congestion: scenario 3
R/2 out in buffer overflows rare for small in throughput increases
as long as in is not too large (buffer overflows still rare, more
original data arrives)
Slide 117
Transport Layer 3-117 another cost of congestion: when packets
are dropped, any upstream transmission capacity (left router!) used
for that packet was wasted! Causes/costs of congestion: scenario 3
R/2 out in in large for all connections: consider D-B conn. at
upper router => most blue packets lost
Slide 118
Transport Layer 3-118 Approaches towards congestion control two
broad 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 for
sender to send at
Slide 119
Transport Layer 3-119 Case study: ATM ABR congestion control
Some remarks about ATM networks: Asynchronous Transfer Mode (ATM)
(also called cell relay) originally designed to carry both voice
and data traffic over WANs only used in some backbone networks of
providers (mostly because of its high costs compared to e.g.
Ethernet) Price of 100Mbps Enet NIC: < $10 Price of 155Mbps ATM
NIC: > $500 fixed-sized packets called cells (Internet has
variable sized packets) In order to interconnect with the TCP/IP
world, an ATM gateway is used that converts TCP/IP and Ethernet
frames into ATM cells and then converts them back once they have
reached their destination network.
Slide 120
Transport Layer 3-120 Case study: ATM ABR congestion control
Some remarks about ATM networks: establish virtual-circuit (VC)
between two endpoints before data exchange => all cells (of a
fixed connection) take same path via certain routers (here called
switches) data is delivered in correct order switches can track
state of VC => know average transmission rate of sender switches
can signal sender to reduce rate in case of congestion =>
network-assisted congestion control
Slide 121
Transport Layer 3-121 Case study: ATM ABR congestion control RM
(resource management) cells: sent by sender, interspersed with data
cells (default: every 32 data cells) travel along the data path to
the destination and sent back 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
(probably modified by receiver and switches) ABR: available bit
rate: transmisson rate is adjusted by sender based on returned RM
cells if senders path underloaded: sender should use available
bandwidth if senders path congested: sender throttled to minimum
guaranteed rate
Slide 122
Transport Layer 3-122 Case study: ATM ABR congestion control
two-byte ER (explicit rate) field in RM cell congested switch may
lower ER value in cell senders send rate thus max supportable rate
on path Explicit Forward Congestion Indication (EFCI) bit in data
cells: set to 1 in congested switch if data cell preceding RM cell
has EFCI set, receiver sets CI bit in returned RM cell RM celldata
cell
Slide 123
Transport Layer 3-123 Case study: ATM ABR congestion control
source of illustration: http://arxiv.org/abs/cs/9809100v1 older
switch -> does not support RM cells
Slide 124
Transport Layer 3-124 Case study: ATM ABR congestion control
detailed ABR flow control mechanism is complex and ATM switches
allow for many different configurations => ABR is not very
prevalent today nice overview article: ABR Service on ATM Networks:
What is ? by R. Jain (1995) http://arxiv.org/html/cs/9809100
Slide 125
Transport Layer 3-125 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
Slide 126
Transport Layer 3-126 TCP congestion control algorithm:
approach: use congestion window variable cwnd choose sending rate
accordingly goal: LastByteSent LastByteAcked min{cwnd, rwnd} what
sender knows receive window (free buffer space at receiver) lets
assume for simplicity that rwnd is large and sender has always data
to send => last byte ACKed sent, not- yet ACKed (in-flight) last
byte sent cwnd sender sequence number space
Slide 127
Transport Layer 3-127 TCP Congestion Control: details cwnd is
dynamic, function of perceived network congestion cwnd indirectly
limits sending rate TCP sending rate: roughly: send cwnd bytes,
wait RTT for ACKs, then send more bytes last byte ACKed sent, not-
yet ACKed (in-flight) last byte sent cwnd sender sequence number
space rate ~ ~ cwnd RTT bytes/sec idea: sender tries to find
maximal rate at which no losses occur = bandwidth probing
Slide 128
Transport Layer 3-128 TCP congestion control: approach: sender
increases window size (=> transmission rate) probing for usable
bandwidth, until loss occurs additive increase: increase cwnd by 1
MSS for every received ACK until loss detected corresponds to
doubling of cwnd every RTT since each segment is of size 1 MSS (or
less) and # of received ACKs is old-cwnd-value loss detection:
timeout event or three duplicate ACKS
Slide 129
Transport Layer 3-129 TCP Slow Start (not really slow) when
connection begins, increase rate until first loss event: initially
cwnd = 1 MSS double cwnd every RTT done by incrementing cwnd for
every ACK received summary: initial rate is slow but ramps up
exponentially fast slow start ends when congestion avoidance mode
starts (later) of when loss occurs Host A one segment RTT Host B
time two segments four segments
Slide 130
Transport Layer 3-130 TCP: detecting, reacting to loss loss
indicated by timeout: before resetting cwnd store slow start
threshold: ssthresh:= cwnd/2 cwnd set to 1 MSS; window then grows
exponentially (as in slow start) until threshold ssthres, then
enter congestion avoidance mode, where cwnd increased by 1 MSS
every RRT (linear growth) loss indicated by 3 duplicate ACKs: dup
ACKs indicate network capable of delivering some segments cwnd is
cut in half window then grows linearly Earlier TCP versions: always
set cwnd to 1 (timeout or 3 duplicate acks)
Slide 131
TCP: switching from slow start to congestion avoidance
Transport Layer 3-131 Q: when should the exponential increase (slow
start) switch to linear? A: when cwnd gets to 1/2 of its value
before timeout. Implementation: variable ssthresh on loss event,
ssthresh is set to 1/2 of cwnd just before loss event
Slide 132
TCP: additive increase, multiplicative decrease (AIMD)
algorithm Transport Layer 3-132 (Ignoring slow start and timeouts.)
- we have additive increase in congestion avoidance mode: - we have
multiplicative decrease in case of 3 duplicate ACKs (after RTT
time): after RTT time: cwnd = cwnd + 1 MSS (linear growth) cwnd =
0.5 * cwnd
Slide 133
Transport Layer 3-133 TCP Tahoe: early version of TCP; cut
cong. window to 1 MSS in both cases (timeout AND triple dupl. ACK)
TCP Reno: newer version; uses fast recovery (increase cwnd by 1 MSS
for every duplicate ACK) Congestion Window: Reno vs Tahoe Tahoe and
Reno curve is identical actually, it should start at 6+3=9!
Transport Layer 3-135 Summary: TCP Congestion Control slow
start timeout ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0
retransmit missing segment cwnd = cwnd+MSS dupACKcount = 0 transmit
new segment(s), as allowed new ACK dupACKcount++ duplicate ACK cwnd
= 1 MSS ssthresh = 64 KB dupACKcount = 0 increase cwnd by 1 MSS for
every ACK if cwnd/MSS segements are sent in time interval [0,RTT]
then cwnd is twice as large after receiving cwnd/MSS ACKs Example:
1 MSS = 1460 Bytes cwnd = 14,600 Bytes, then 10 segments are being
sent within at RTT
Slide 136
Transport Layer 3-136 Summary: TCP Congestion Control cwnd >
ssthresh slow start timeout ssthresh = cwnd/2 cwnd = 1 MSS
dupACKcount = 0 retransmit missing segment cwnd = cwnd+MSS
dupACKcount = 0 transmit new segment(s), as allowed new ACK
dupACKcount++ duplicate ACK cwnd = 1 MSS ssthresh = 64 KB
dupACKcount = 0 congestion avoidance cwnd = cwnd + MSS (MSS/cwnd)
dupACKcount = 0 transmit new segment(s), as allowed new ACK.
dupACKcount++ duplicate ACK timeout ssthresh = cwnd/2 cwnd = 1 MSS
dupACKcount = 0 retransmit missing segment increase cwnd by 1 MSS
for every RTT receiving cwnd/MSS ACKs per RTT means we add cwnd/MSS
times the factor MSS*(MSS/cwnd) add 1 MSS per RTT example: cwnd/MSS
= 10 segments
Slide 137
Transport Layer 3-137 Summary: TCP Congestion Control timeout
ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0 retransmit missing
segment cwnd > ssthresh congestion avoidance cwnd = cwnd + MSS
(MSS/cwnd) dupACKcount = 0 transmit new segment(s), as allowed new
ACK. dupACKcount++ duplicate ACK ssthresh= cwnd/2 cwnd = ssthresh +
3 retransmit missing segment dupACKcount == 3 slow start timeout
ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0 retransmit missing
segment cwnd = cwnd+MSS dupACKcount = 0 transmit new segment(s), as
allowed new ACK dupACKcount++ duplicate ACK cwnd = 1 MSS ssthresh =
64 KB dupACKcount = 0 set cwnd to cwnd/2 since it was too high try
to find optimal value for cwnd
Slide 138
Transport Layer 3-138 Summary: TCP Congestion Control timeout
ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0 retransmit missing
segment cwnd > ssthresh congestion avoidance cwnd = cwnd + MSS
(MSS/cwnd) dupACKcount = 0 transmit new segment(s), as allowed new
ACK. dupACKcount++ duplicate ACK fast recovery cwnd = cwnd + MSS
transmit new segment(s), as allowed duplicate ACK ssthresh= cwnd/2
cwnd = ssthresh + 3 retransmit missing segment dupACKcount == 3
cwnd = ssthresh dupACKcount = 0 New ACK slow start timeout ssthresh
= cwnd/2 cwnd = 1 MSS dupACKcount = 0 retransmit missing segment
cwnd = cwnd+MSS dupACKcount = 0 transmit new segment(s), as allowed
new ACK dupACKcount++ duplicate ACK cwnd = 1 MSS ssthresh = 64 KB
dupACKcount = 0 - increase cwnd on every dupl. ACK (note that dupl.
ACK means that certain packets get through) - wont have many dupl.
ACK since we retransmit missing packet - additionally we can
transmit further segments (cwnd increases quickly) - see RFC
2581
Transport Layer 3-140 TCP throughput saw tooth behavior (if
slow start is ignored) compute avg. TCP throughput as function of
window size and RTT using some simplifying assumptions ignore slow
start, assume always data to send fixed window size W (measured in
bytes) when loss occurs transmission rate ranges from 0.5W/RTT to
W/RTT avg. window size (# in-flight bytes) is W W W/2 avg TCP
throughput = 3 4 W RTT Bytes/sec
Transport Layer 3-142 High-Speed TCP Connections What fraction
of packets could be lost so that we still have a throughput of
10Gbps? throughput in terms of segment loss probability, L : to
achieve 10 Gbps throughput, need a loss rate of L 2 10 -10 very
small loss rate (one loss every 5 billion segm) new versions of TCP
for high-speed (RFC 3649) TCP throughput = 1.22. MSS RTT L homework
Remark: one cannot simply increase the MSS since this will lead to
a lot of IP fragmentation (=> less efficient and in case of
fragment loss whole segment is lost) default is 536 B => plus 40
B header gives MTU for IP networks local networks use larger MSS
(e.g. 1500 Bytes for Ethernet) modern LANs can use Jumbo frames
(MTU up to 9000 B)
Slide 143
Transport Layer 3-143 fairness goal: if K TCP sessions share
same bottleneck link of bandwidth R, each should have average rate
of R/K TCP connection 1 bottleneck router capacity R TCP Fairness
TCP connection 2
Slide 144
Transport Layer 3-144 Why TCP is fair (Intuition) two competing
sessions (same MSS, RTT, no other traffic): below full utilization,
increase cwnd by 1 MSS per RTT in congestion avoidance mode (ignore
slow start phase) both detect losses during increase => halve
their windows R R equal bandwidth share Connection 1 throughput
Connection 2 throughput congestion avoidance: additive increase
loss: decrease window by factor of 2 congestion avoidance: additive
increase loss: decrease window by factor of 2 full bandwidth
utilization => realized bandwidth converges to equal bandwidth
share!
Slide 145
Transport Layer 3-145 Fairness (more) Fairness and UDP
multimedia apps often do not use TCP do not want rate throttled by
congestion control instead use UDP: send audio/video at constant
rate, tolerate packet loss => crowd out TCP traffic need for
congestion control for UDP Fairness, parallel TCP connections
application can open multiple parallel connections between two
hosts => larger fraction of bandwidth at congested link (e.g.
multiple tabs in browser) unfair! e.g., link of rate R with 9
existing connections: new app asks for 1 TCP, gets rate R/10 new
app asks for 11 TCPs, gets 11* R/20
Slide 146
Transport Layer 3-146 Chapter 3: summary principles behind
transport layer services: multiplexing, demultiplexing reliable
data transfer flow control congestion control their instantiation,
implementation in the Internet UDP TCP Remark: TCP is actually more
complex than what we have described (variety of patches, fixes
improvements) next: leaving the network edge (application,
transport layers) into the network core
