Chapter 3 Transport Layer

Chapter 3 Transport Layer

Computer Networking: A Top Down Approach 4th edition. Jim Kurose, Keith RossAddison-Wesley, July

2007.

Last Lecture

Chapter 3: Transport layerMultiplexing and De-Multiplexing

Connectionless Transport: UDP

Today’s Lecture

Principles of Reliable Data Transfer Protocol

Principles of Reliable Data Transfer• Important in application, transport, link layers• Top-10 list of important networking topics!

Principles of Reliable Data Transfer (rdt)• Important in application, transport, link layers• Top-10 list of important networking topics!

Principles of Reliable Data Transfer• Important in application, transport, link layers• Top-10 list of important networking topics!

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 protocol, 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 layer

Reliable Data Transfer: Getting Started

We’ll:• Incrementally develop sender, 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 sender, receiver

state 1

state 2

event causing state transitionactions taken on state transition

state: When in this “state” next state uniquely determined by next

event

eventactions

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

packet =make_pkt(data)udt_send(packet)

rdt_send(data)

extract (packet,data)deliver_data(data)

rdt_rcv(packet)

Sender Receiver

Wait for call from below

Note:Perfectly reliable channel no need for feedback

Rdt2.0: Channel with Bit Errors• More realistic model

– Underlying channel may flip bits in packet

• How people deal with such a situation– OK (positive acknowledgment)– Please repeat that (negative acknowledgements)– 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

• These control messages let the receiver know– What has been received in error and requires repetition

• Automatic Repeat reQuest (ARQ) protocols.

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

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


sender

receiver

rdt_send(data)

Rdt2.0: Operation with No Errors


snkpkt = make_pkt(data, checksum)udt_send(sndpkt)

extract(rcvpkt,data)deliver_data(data)udt_send(ACK)



udt_send(sndpkt)

rdt_rcv(rcvpkt) && isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) && corrupt(rcvpkt)Wait for

ACK or NAK


rdt_send(data)

Rdt2.0: error scenario


snkpkt = make_pkt(data, checksum)udt_send(sndpkt)

extract(rcvpkt,data)deliver_data(data)udt_send(ACK)


udt_send(sndpkt)

rdt_rcv(rcvpkt) && isNAK(rcvpkt)Wait for

ACK or NAK


rdt_send(data)

udt_send(NAK)

rdt_rcv(rcvpkt) && corrupt(rcvpkt)


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 (doesn’t

deliver up) duplicate packet

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 0udt_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 ACK or NAK 1

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)


&& has_seq1(rcvpkt)

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


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)

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

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


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

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

udt_send(sndpkt)Receiver FSMFragment

Rdt3.0: Channels with Errors and LossNew Assumption: Underlying channel can also lose packets

(data or ACKs) What to do when packet loss occurs?

Sequence nos, 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

sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)start_timer

rdt_send(data)

Wait for ACK 0

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


sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)start_timer

rdt_send(data)


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


stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)


Wait for ACK1

rdt_rcv(rcvpkt)

Documents

Chapter 3 Transport Layer