2.3-application-FTP

Podcast Beta

Play an AI-generated podcast conversation about this lesson

Questions and Answers

Which protocol uses a 'window' of up to N consecutive transmitted but unACKed packets?

Transport Layer

Go-Back-N (correct)

Selective repeat

Receiver window

What is the purpose of the cumulative ACK in the Go-Back-N protocol?

To acknowledge all packets up to and including a specific sequence number (correct)

To acknowledge all packets in the window

To acknowledge only out-of-order packets

To acknowledge only the most recently received packet

What happens when a timeout occurs in the Go-Back-N protocol?

All packets in the window are retransmitted

The sender window is resized

The receiver window is resized

The oldest in-flight packet is retransmitted (correct)

What does the Go-Back-N receiver do when it receives an out-of-order packet?

It can discard the packet or buffer it Signup and view all the answers

In the Go-Back-N protocol, how does the receiver handle duplicate ACKs?

It ignores them Signup and view all the answers

What does the Selective Repeat protocol do to ensure in-order delivery of packets?

It buffers packets and delivers them in order Signup and view all the answers

How does the Selective Repeat protocol handle unACKed packets?

The sender times-out and retransmits each unACKed packet individually Signup and view all the answers

What is the purpose of the sender window in the Selective Repeat protocol?

To limit the sequence numbers of sent, unACKed packets Signup and view all the answers

What does the Selective Repeat receiver do when it receives an out-of-order packet?

It buffers the packet Signup and view all the answers

What relationship is needed between sequence number size and window size to avoid a dilemma in the Selective Repeat protocol?

The sequence number size should be greater than the window size Signup and view all the answers

What is the purpose of the 'window' in the Go-Back-N protocol?

The 'window' in the Go-Back-N protocol limits the number of consecutive transmitted but unACKed packets. Signup and view all the answers

What is the function of the cumulative ACK in the Go-Back-N protocol?

The cumulative ACK in the Go-Back-N protocol acknowledges all packets up to, including the sequence number specified in the ACK. Signup and view all the answers

How does the Go-Back-N protocol handle a timeout event?

When a timeout occurs in the Go-Back-N protocol, the sender retransmits the packet that triggered the timeout and all higher sequence number packets in the window. Signup and view all the answers

What is the main difference between the Go-Back-N protocol and the Selective Repeat protocol?

The main difference between the Go-Back-N protocol and the Selective Repeat protocol is that the Go-Back-N protocol resends all unACKed packets, while the Selective Repeat protocol only resends individual unACKed packets. Signup and view all the answers

What does the Selective Repeat protocol do when it receives an out-of-order packet?

When the Selective Repeat protocol receives an out-of-order packet, it can either discard the packet or buffer it, depending on the implementation. It will also re-ACK the packet with the highest in-order sequence number. Signup and view all the answers

Study Notes

UDP: User Datagram Protocol

"No frills," "bare bones" Internet transport protocol
"Best effort" service, UDP segments may be:
- Lost
- Delivered out-of-order to app
- Connectionless: no handshaking between UDP sender, receiver
- Each UDP segment handled independently of others
Advantages:
- No connection establishment (which can add RTT delay)
- Simple: no connection state at sender, receiver
- Small header size
- No congestion control
- Can function in the face of congestion
Typical use cases:
- Streaming multimedia apps (loss tolerant, rate sensitive)
- DNS
- SNMP (Simple Network Management Protocol)
- HTTP/3
- If reliable transfer needed over UDP (e.g., HTTP/3): add needed reliability at application layer and add congestion control at application layer

UDP Checksum

Goal: detect errors (i.e., flipped bits) in transmitted segment
Sender:
- Treat contents of UDP segment (including UDP header fields and IP addresses) as sequence of 16-bit integers
- Checksum: addition (one's complement sum) of segment content
- Checksum value put into UDP checksum field
Receiver:
- Compute checksum of received segment
- Check if computed checksum equals checksum field value:
  - Not equal: error detected
  - Equal: no error detected

Internet Checksum

Example: add two 16-bit integers
Note: when adding numbers, a carryout from the most significant bit needs to be added to the result
Weak protection: even though numbers have changed (bit flips), no change in checksum

RDT (Reliable Data Transfer) Protocols

RDT 1.0: Reliable Transfer over a Reliable Channel

Underlying channel perfectly reliable: no bit errors, no loss of packets
Separate FSMs (Finite State Machines) for sender, receiver:
- Sender sends data into underlying channel
- Receiver reads data from underlying channel

RDT 2.0: Channel with Bit Errors

Underlying channel may flip bits in packet
Checksum (e.g., Internet checksum) to detect bit errors
The question: how to recover from errors
Human analogy: how to recover from "errors" during conversation
Approach:
- 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
- Stop and wait: sender sends one packet, then waits for receiver response

RDT 2.0: FSM Specifications

Sender FSM:
- Send packet
- Wait for ACK or NAK
- If NAK, retransmit packet
- If ACK, wait for next packet
Receiver FSM:
- Receive packet
- Check if packet corrupted
- If corrupted, send NAK
- If not corrupted, extract data and send ACK

RDT 2.1: A NAK-free Protocol

Same functionality as RDT 2.0, using ACKs only
Instead of NAK, receiver sends ACK for last pkt received OK
Receiver must explicitly include seq # of pkt being ACKed
State indicates whether 0 or 1 is expected pkt seq #

RDT 3.0: Channels with Errors and Loss

New channel assumption: underlying channel can also lose packets (data, ACKs)
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 (timeout)

RDT 3.0: Stop-and-Wait Operation

Pipelining: sender allows multiple, "in-flight", yet-to-be-acknowledged packets
Range of sequence numbers must be increased
Buffering at sender and/or receiver

RDT 3.0: Performance

U sender: utilization – fraction of time sender busy sending
Example: 1 Gbps link, 15 ms prop. delay, 8000 bit packet
Time to transmit packet into channel: 8000 bits / 1 Gbps = 8 microsecs
RDT 3.0 protocol performance stinks
Protocol limits performance of underlying infrastructure (channel)### Reliability in Transport Layer
Reliable data transfer is ensured by using error detection and retransmission mechanisms.

Stop-and-Wait Protocol

A sender sends a packet and waits for an ACK (Acknowledgment) from the receiver.
The receiver sends an ACK upon receiving the packet correctly.
If the sender doesn't receive an ACK within a certain time, it retransmits the packet.

Handling Garbled ACKs/NAKs

Sender checks if the received ACK/NAK is corrupted.
If corrupted, the sender retransmits the packet.
If not corrupted, the sender checks if the ACK/NAK is for the expected packet.

RDT2.1 Protocol

Sender adds a sequence number to each packet.
Receiver discards duplicate packets.
If the receiver receives a corrupted packet, it sends a NAK.
If the receiver receives a packet with an incorrect sequence number, it sends a NAK.

RDT2.2 Protocol (NAK-free)

Instead of sending a NAK, the receiver sends an ACK for the last packet received correctly.
The receiver explicitly includes the sequence number of the packet being ACKed.
A duplicate ACK at the sender results in the same action as a NAK: retransmit the current packet.

RDT3.0 Protocol (Channels with Errors and Loss)

The underlying channel can lose packets (data, ACKs).
Checksum, sequence numbers, ACKs, and retransmissions are used to handle errors and loss.
The sender waits for a "reasonable" amount of time for an ACK and retransmits if no ACK is received.

Performance of RDT3.0 (Stop-and-Wait)

Utilization of the sender is the fraction of time the sender is busy sending.
Example: 1 Gbps link, 15 ms propagation delay, 8000-bit packet.

Pipelining

The sender allows multiple, "in-flight", yet-to-be-acknowledged packets.
The range of sequence numbers must be increased.
Buffering at the sender and/or receiver is required.

Go-Back-N Protocol

The sender has a "window" of up to N consecutive transmitted but unACKed packets.
The receiver sends a cumulative ACK: ACK(n) acknowledges all packets up to, including sequence number n.
On receiving ACK(n), the sender moves the window forward to begin at n+1.

Selective Repeat Protocol

The receiver individually acknowledges all correctly received packets.
The sender times out and retransmits individually for unACKed packets.
The sender maintains a timer for each unACKed packet.
The receiver buffers packets, as needed, for eventual in-order delivery to the upper layer.

Selective Repeat in Action

The sender window is N consecutive sequence numbers.
The receiver window is N consecutive sequence numbers.
The receiver sends an ACK for each packet received correctly.
If the receiver receives a packet with an incorrect sequence number, it buffers the packet.

Selective Repeat Dilemma

Example: sequence numbers 0, 1, 2, 3 (base 4 counting).
Window size = 3.
The receiver window and sender window can lead to a problem.
The relationship between sequence number size and window size is needed to avoid this problem.

Studying That Suits You

Use AI to generate personalized quizzes and flashcards to suit your learning preferences.

Description

This quiz tests your understanding of handling garbled ACK/NAKs in a sender using the rdt_send function. It covers topics such as making packets, sending and receiving packets, checking for corruption, and handling ACKs and NAKs.