Top Banner
Transport Layer 3-1 Chapter 3 Transport Layer Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-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-2004 J.F Kurose and K.W. Ross, All Rights Reserved
68

Networks - Chapter 3 - Transport Layer 1spp

Nov 28, 2014

Download

Documents

Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: 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

Page 2: Networks - Chapter 3 - Transport Layer 1spp

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

Page 3: Networks - Chapter 3 - Transport Layer 1spp

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

Page 4: Networks - Chapter 3 - Transport Layer 1spp

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

Page 5: Networks - Chapter 3 - Transport Layer 1spp

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

Page 6: Networks - Chapter 3 - Transport Layer 1spp

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

Page 7: Networks - Chapter 3 - Transport Layer 1spp

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

Page 8: Networks - Chapter 3 - Transport Layer 1spp

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:

Page 9: Networks - Chapter 3 - Transport Layer 1spp

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

Page 10: Networks - Chapter 3 - Transport Layer 1spp

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?

Page 11: Networks - Chapter 3 - Transport Layer 1spp

Transport Layer 3-11

Connectionless demux (cont)DatagramSocket serverSocket = new DatagramSocket(46428);

Page 12: Networks - Chapter 3 - Transport Layer 1spp

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

Page 13: Networks - Chapter 3 - Transport Layer 1spp

Transport Layer 3-13

Connection-oriented demux (cont)

Page 14: Networks - Chapter 3 - Transport Layer 1spp

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

Page 15: Networks - Chapter 3 - Transport Layer 1spp

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

Page 16: Networks - Chapter 3 - Transport Layer 1spp

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

Page 17: Networks - Chapter 3 - Transport Layer 1spp

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

Page 18: Networks - Chapter 3 - Transport Layer 1spp

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

Page 19: Networks - Chapter 3 - Transport Layer 1spp

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

Page 20: Networks - Chapter 3 - Transport Layer 1spp

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

Page 21: Networks - Chapter 3 - Transport Layer 1spp

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)

Page 22: Networks - Chapter 3 - Transport Layer 1spp

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

Page 23: Networks - Chapter 3 - Transport Layer 1spp

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

Page 24: Networks - Chapter 3 - Transport Layer 1spp

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

Page 25: Networks - Chapter 3 - Transport Layer 1spp

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

Page 26: Networks - Chapter 3 - Transport Layer 1spp

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)

Λ

Page 27: Networks - Chapter 3 - Transport Layer 1spp

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)

Λ

Page 28: Networks - Chapter 3 - Transport Layer 1spp

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)

Λ

Page 29: Networks - Chapter 3 - Transport Layer 1spp

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

Page 30: Networks - Chapter 3 - Transport Layer 1spp

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

Page 31: Networks - Chapter 3 - Transport Layer 1spp

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

Page 32: Networks - Chapter 3 - Transport Layer 1spp

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

Page 33: Networks - Chapter 3 - Transport Layer 1spp

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)

Page 34: Networks - Chapter 3 - Transport Layer 1spp

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

Page 35: Networks - Chapter 3 - Transport Layer 1spp

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

Page 36: Networks - Chapter 3 - Transport Layer 1spp

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

Page 37: Networks - Chapter 3 - Transport Layer 1spp

Transport Layer 3-37

rdt3.0 in action

Page 38: Networks - Chapter 3 - Transport Layer 1spp

Transport Layer 3-38

rdt3.0 in action

Page 39: Networks - Chapter 3 - Transport Layer 1spp

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

Page 40: Networks - Chapter 3 - Transport Layer 1spp

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) =

Page 41: Networks - Chapter 3 - Transport Layer 1spp

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)

Page 42: Networks - Chapter 3 - Transport Layer 1spp

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!

Page 43: Networks - Chapter 3 - Transport Layer 1spp

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

Page 44: Networks - Chapter 3 - Transport Layer 1spp

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

Λ

Page 45: Networks - Chapter 3 - Transport Layer 1spp

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)

Λ

Page 46: Networks - Chapter 3 - Transport Layer 1spp

Transport Layer 3-46

GBN in action (window size = 4)

Page 47: Networks - Chapter 3 - Transport Layer 1spp

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

Page 48: Networks - Chapter 3 - Transport Layer 1spp

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

Page 49: Networks - Chapter 3 - Transport Layer 1spp

Transport Layer 3-49

Selective repeat: sender, receiver windows

Page 50: Networks - Chapter 3 - Transport Layer 1spp

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

Page 51: Networks - Chapter 3 - Transport Layer 1spp

Transport Layer 3-51

Selective repeat in action

Page 52: Networks - Chapter 3 - Transport Layer 1spp

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?

Page 53: Networks - Chapter 3 - Transport Layer 1spp

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

Page 54: Networks - Chapter 3 - Transport Layer 1spp

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

Page 55: Networks - Chapter 3 - Transport Layer 1spp

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)

Page 56: Networks - Chapter 3 - Transport Layer 1spp

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

Page 57: Networks - Chapter 3 - Transport Layer 1spp

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

Page 58: Networks - Chapter 3 - Transport Layer 1spp

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

Page 59: Networks - Chapter 3 - Transport Layer 1spp

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

Page 60: Networks - Chapter 3 - Transport Layer 1spp

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

Page 61: Networks - Chapter 3 - Transport Layer 1spp

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

Page 62: Networks - Chapter 3 - Transport Layer 1spp

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

Page 63: Networks - Chapter 3 - Transport Layer 1spp

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.

Page 64: Networks - Chapter 3 - Transport Layer 1spp

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

Page 65: Networks - Chapter 3 - Transport Layer 1spp

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

Page 66: Networks - Chapter 3 - Transport Layer 1spp

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

Page 67: Networks - Chapter 3 - Transport Layer 1spp

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

Page 68: Networks - Chapter 3 - Transport Layer 1spp

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”