Você está na página 1de 21

Chapter 3

Transport Layer
Computer Networking: A
Top Down Approach
4th edition.
Jim Kurose, Keith Ross
Addison-Wesley, July
2007.

Principles of Reliable Data


Transfer

Important in application, transport, link layers


Top-10 list of important networking topics!

Reliable Data Transfer: Getting


Started
rdt_send(): called from
above, (e.g., by app.). Passed
data to
deliver to receiver upper layer

send
side

udt_send(): called by rdt


protocol, to transfer packet
over
unreliable channel to
receiver

deliver_data(): called by
rdt to deliver data to upper
layer

receive
side

rdt_rcv(): called when packet


arrives on rcv-side of channel

Rdt1.0: Reliable Data Transfer over a


Perfectly Reliable Channel
Underlying channel perfectly reliable
no bit errors
no loss of packets

Separate FSMs for sender, receiver:


sender sends data into underlying channel
receiver read data from underlying channel

The initial state of the FSM is indicated by the


dashed line
Wait for
call from
above

rdt_send(data)
packet
=make_pkt(data)
udt_send(packet)

Sender

Wait for
call from
below

rdt_rcv(packet)
extract
(packet,data)
deliver_data(data)

Receiver

Note:Perfectly reliable channel no need for

Rdt2.0: Channel with Bit Errors


Three capabilities are required in ARQ to handle the
presence of bit errors.
Error Detection:
Needed to allow the receiver to detect bit errors
Checksum field in the header
Receiver Feed Back
Receiver provided explicit feedback
ACK
NAK
Retransmission
A packet that is received in error will be
retransmitted
New mechanisms in rdt2.0 (beyond rdt1.0):
Error detection
Receiver feedback: Control msgs (ACK,NAK) Rcvr->Sender

Rdt2.0: FSM
Specification

rdt_send(data)

snkpkt = make_pkt(data,
checksum)
udt_send(sndpkt)rdt_rcv(rcvpkt)
&&
Wait for
Wait for
isNAK(rcvpkt)
call from
ACK or
udt_send(sndpk
above
NAK
t)
rdt_rcv(rcvpkt) &&
isACK(rcvpkt)

sender

receiver
rdt_rcv(rcvpkt)
&&
corrupt(rcvpkt)
udt_send(NAK)
Wait for
call from
below

rdt_rcv(rcvpkt)
&&
extract(rcvpkt,data)
notcorrupt(rcvpk
deliver_data(data)
t)
udt_send(ACK)

Rdt2.0
rdt2.0 is a stop and wait
protocol
Sender sends one packet, then
waits for receiver response

rdt2.0 has a fatal flaw


What happens if ACK/NAK get
corrupted?

Add checksum bits to ACK/NAK

How the protocol should recover


from errors in ACK/NAK?
Retransmission on receipt of a
corrupt ACK/NAK
Retransmission causes
duplicates

Receiver does not know


whether ACK or NAK it sent was
received correctly
Receiver does not know a priori
whether an arriving packet
contains new data or is a
retransmission

Handling Duplicates:
Sender retransmits current
packet if ACK/NAK garbled
Sender adds sequence
number to each packet
Receiver discards (doesnt
deliver up) duplicate packet

Rdt2.1: Sender, handles garbled


ACK/NAKs
rdt_send(data)

rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt)

sndpkt = make_pkt(0, data, checksum)


udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
Wait for
Wait for
ACK
udt_send(sndpkt)
call 0
or NAK 0
from
above
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt)

rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
udt_send(sndpkt)

Wait for
ACK or
NAK 1

Wait
for
call 1
from
rdt_send(data) above

sndpkt = make_pkt(1, data, checksum)


udt_send(sndpkt)

Rdt2.1: Receiver, handles garbled


ACK/NAKs
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)

rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt))
sndpkt = make_pkt(NAK,
chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) &&
has_seq1(rcvpkt)
sndpkt = make_pkt(ACK,
chksum)
udt_send(sndpkt)

extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt))
sndpkt = make_pkt(NAK,
Wait
for
0 from
below

Wait
for
1 from
below

chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) &&
has_seq0(rcvpkt)

sndpkt = make_pkt(ACK,
chksum)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
udt_send(sndpkt)
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)

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
Receiver must explicitly include seq # of
the packet being ACKed
Duplicate ACK at sender results in same
action as NAK: retransmit current packet

Rdt2.2: Sender, Receiver Fragments


rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
rdt_rcv(rcvpkt) &&
udt_send(sndpkt)
( corrupt(rcvpkt) ||
Wait
for
Wait for
isACK(rcvpkt,1) )
ACK

call 0 from
above

rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) ||
has_seq1(rcvpkt))
udt_send(sndpkt)

Wait for
0 from
below

Sender FSM
Fragment

Receiver FSM
Fragment

udt_send(sndpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)


&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK,1, chksum)
udt_send(sndpkt)

Rdt3.0: Channels with Errors


and Loss

New Assumption: Underlying channel can also lose


packets (data or ACKs)
What to do when packet loss occurs?
Retransmissions
How to detect loss?
Sender waits reasonable amount of time for
ACK
Must wait at least as long as RTT plus
processing delay.
Retransmits if no ACK received in this time
If packet (or ACK) just delayed (not lost):
Retransmission will be duplicate, but use of
sequence numbers can handles this.

Rdt3.0: Channels with Errors


and Loss

Rdt3.0
Sender

Wait for
call 0 from
above

rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,0) )

timeout
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
stop_timer

stop_timer
timeout
udt_send(sndpkt)
start_timer

Wait
for
ACK 0

rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,1)

rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )

sndpkt = make_pkt(0, data, checksum)


udt_send(sndpkt)
start_timer

rdt_rcv(rcvpkt)

rdt_send(data)

Wait
for
ACK1

Wait for
call 1 from
above
rdt_send(data)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
start_timer

Rdt3.0 Receiver?

rdt_rcv(rcvpkt)

Pipelined Reliable Data Transfer


Protocols
Rdt3.0 works, but performance is poor
Poor Performance is due to the fact that

it is a stop and wait protocol

Poor utilization of the resource

Solution

Sender is allowed to send multiple packets


without waiting for ACKs.
Pipelining

Since many sender to receiver packets can be


visualized as filling a pipeline
Increase utilization

Pipelined Reliable Data Transfer Protocols


Pipelining has the following consequences for

reliable data transfer


Range of sequence numbers must be increased
Sender and receiver sides may have to buffer
more than one packet.

Two basic approaches towards pipeline error

recovery:
Go-Back-N, Selective Repeat

Go-Back-N (GBN)
Sender:
Sender is allowed to transmit multiple packets without waiting

for an acknowledgement
Constrained to a certain maximum number N.
Base or send_base
Sequence number of oldest unacknowledged packet
Nextseqnum
Sequence number of next packet to be sent
The range of sequence numbers for transmitted but not
acknowledged packets can be viewed as a window of size N.
This window slides forward as the protocol operates

Go-Back-N
GBN sender must respond to three types of events
Invocation from above (rdt_send() is called):
If window is full, returns data to upper layer
Maintain synchronization mechanism
Receipt of an ACK:
ACK for packet with seq # n is taken asCumulative ACK
More shortly in receiver
Time out event:
Sender has timer for oldest unacknowledged packet
If timer expires, retransmit all unacknowledged packets

Go-Back-N
Receiver:
If a packet with seq # n is received correctly and is in
order

ACK is sent and data is delivered to upper layers

For all other cases


Receiver discards the packet and resends ACK for most
recently received in order packet
Packets are delivered one at a time to upper layers
If a packet k has been received and delivered, then all
packets with seq # lower than k have also been delivered.
Receiver discards out of order packets
No receiver buffering
Need only remember expectedseqnum

GBN in
action

http://www.eecis.udel.edu/~amer/450/TransportApplets/GBN/GBNindex.html

Course till this Lecture


Good Luck with OHT-1

Você também pode gostar