Transport Layer II

Question 1

Reliable Data Transfer

Answer 1

A sending process (like an app or server) passes data to the transport layer (e.g., TCP).

The transport layer sends it over the network.

The receiving process gets the data from the transport layer.

Challenge:
Real networks can be unreliable:

Corruption: Data gets changed during transfer.

Loss: Data never arrives.

Reordering: Data arrives out of order.
So what happens?
The transport protocol must:

Detect errors (using checksums)

Recover lost data (using retransmissions)

Fix the order (using sequence numbers)

Question 2

Reliable data transfer protocol (rdt): interfaces

Answer 2

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 receiver side of channel

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

use finite state machines (FSM) to specify sender, receiver

Question 3

the question: how to recover from errors?

what happens if ACK/NAK
corrupted?

Answer 3

• 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

▪sender doesn’t know what happened at receiver!
▪can’t just retransmit: possible
duplicate

handling duplicates:
▪sender retransmits current
packet if ACK/NAK corrupted
▪sender adds sequence number
to each packet
▪receiver discards (doesn’t
deliver up) duplicate packet

Question 4

channels with errors and loss

Answer 4

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 packet being ACKed

▪ use countdown timer to interrupt after “reasonable” amount
of time

Question 5

Performance of rdt3.0 (stop-and-wait)

Answer 5

time to transmit packet into channel:
Dtrans = L/
R

Question 6

pipelined protocols operation

Answer 6

pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged
packets
* range of sequence numbers must be increased
* buffering at sender and/or receiver

Question 7

Go-Back-N: sender

Answer 7

Sender can send up to N packets before needing ACKs.

Each packet has a sequence number.

ACK(n) means: all packets up to n were received.

When ACK is received, the window slides forward to send more.

A timer tracks the oldest unACKed packet.

If it times out, the sender resends that packet and the rest not yet acknowledged.

Question 8

Go-Back-N: receiver

Answer 8

Receiver only accepts the next expected packet (in sequence).

If the correct packet arrives → it’s delivered and ACKed.

If an out-of-order packet arrives → it’s discarded.

Receiver sends ACK for the last correctly received packet.

Question 9

Selective repeat:

Answer 9

SENDER:
data from above:
▪if next available seq # in
window, send packet
timeout(n):
▪resend packet n, restart timer
ACK(n) in [sendbase,sendbase+N-1]:
▪mark packet n as received
▪if n smallest unACKed packet,
advance window base to next unACKed seq #

RECEIVED:
packet n in [rcvbase, rcvbase+N-1]
▪ send ACK(n)
▪out-of-order: buffer
▪ in-order: deliver (also deliver
buffered, in-order packets),
advance window to next not-yet
received packet
packet n in [rcvbase-N,rcvbase-1]
▪ACK(n)
otherwise:
▪ ignore