Outline

Reliable Transmission

because packets may be lost in (most) networks, additional protocols can be used to provide reliable transmission
there is no protocol that can remedy the problem if the physical layer becomes unable to transmit for long periods of time
in a wired network, this is the "air gap" problem
most reliable transmission aims to overcome occasional packet losses
reliable transmission can also reliably detect when the connection is down (after a certain time)
but cannot reliably report exactly how much data the receiver has received

sender transmits one packet, then stops and waits
receiver transmits a special packet, an acknowledgment (ack), whenever it gets a data packet
once the sender gets the ack, it transmits the next data packet
if the sender does not get the ack within a certain time, it retransmits the packet
advantages of stop-and-wait: very simple, easy to implement
disadvantages of stop-and-wait:
- fairly slow: the sender can send at most one new packet per RTT
- not robust: if the ack can get lost, when the receiver gets a packet, the receiver cannot tell if it is a retransmission or a new packet
to deal with the last problem, must distinguish new packets from retransmissions

same as stop-and-wait, but each packet and each ack carries a 1 bit sequence number
the sequence number is incremented (modulo 2) for every new packet sent
retransmissions carry the same sequence number as the original packet
acks carry the same sequence number as the packet that was received
sender and receiver must agree on which sequence number to use for the first packet
problem: what if a packet is delayed in the network and delivered much later?

instead of a 1-bit sequence number, packets can carry a larger (N-bit) sequence number, e.g. a 32-bit sequence number
this way, the receiver can distinguish among up to 2^N different packets, even if delivered out of order
even for large N, all arithmetic must be modulo 2^N, unless we want to put artificial limits on how much data can be sent

even the alternating-bit protocol suffers from performance problems: at most 1 packet/RTT
assuming a 1250-byte (10,000 bit) packet and a RTT of 50ms, that limits throughput to 200Kb/s
even if the hardware would allow much higher speeds!
so, instead of sending just one packet at a time, send multiple packets
the number of packets sent at once cannot exceed 2^{N - 1} -- why? (in-class exercise)
often, there are good reasons to limit this number even more
the maximum number of packets (or data) transmissible at any one time is called a window
the transmission window begins with the first unacknowledged packet, which the sender must buffer in case it must be retransmitted
the transmission window usually ends a fixed offset from the beginning of the window

in the sliding window protocol, the receiver acknowledges receiving all packets up to sequence number S, by sending the numbe S in the acknowledgement
when S is received, the sender can slide the window "up" or "to the right" so that S+1 is the first unacknowledged packet
a sender cannot send data the application hasn't generated (yet), so part of the window may still be open for further transmissions
the receiver window starts from the last packet received in order
any received packets that are not in the receiver window, e.g., old retransmitted packets, are acknowledged and discarded
if a receiver receives packet number S+i when it expects packet number S, it has two choices:
- the receiver can buffer this out-of-order packet, hoping the missing packet(s) will be received soon, or
- the receiver can discard this out-of-order packet, and wait for the sender to retransmit the packets in order
the first strategy avoids retransmissions, but works best if there is a mechanism to tell the sender which packets are missing: selective acknowledgements
the second strategy avoids the need for buffering at the receiver, but expects the sender to retransmit all its unacknowledged packets at once: go-back-N
in a window system, many packets are in transit at once, which increases performance: up to W/RTT bits/second can be sent

the sender uses a single timer, which is restarted whenever a packet is transmitted
when the timer expires, all unacknowledged packets are retransmitted
this could be a lot of data, and
is especially wasteful if the receiver is only missing one or two packets
go-back-N simplifies the receiver implementation, since no buffering is needed

a selective acknowledgement might carry more detailed data than the cumulative acknowledgement used in go-back-N
for example, the ack packet might carry both a cumulative acknowledgement, and selective acknowledgement(s) for at least some of the out-of-order packets
the ack packet can also carry an indication of which packets are missing: negative acknowledgements (naks or nacks)
unless the receiver has specific information about how much data the sender will send, it can only send a nak when it receives an out-of-order packet
the sender must maintain a timer for every outstanding packet, and retransmit each packet independently when its timer expires
both the sender and transmitter are more complex compared to go-back-N, but less data needs to be sent in case of retransmission

if packets are only retransmitted very rarely, timer settings are not crucial
using a long-period (slow) timer, packets are only retransmitted when needed, reducing the additional data sent
using a fast period timer, packets are retransmitted as quickly as possible, reducing the time before the receiver gets all its data
timers can be set adaptively, based on the observed RTT of the connection, that is, the time from sending a packet (that is never retransmitted) to getting the ack for that packet

checksum is used to ensure packet integrity
timer is used to decide when to retransmit a packet
sequence number is used to determine correct packet re-ordering, duplication, and loss
acknowledgement is a packet used to inform the sender of packet receipt
negative acknowledgement is a packet used to inform the sender that an expected packet was not received
window is the amount of outstanding unacknowledged data a sender may have. Once the whole window is sent, the sender must stop
flow control is the slowing down of a sender to achieve specific goals, e.g., avoid sending more data than a receiver has buffer space