1. Transport / Network Layers

• Client makes an API call to pass the message to TCP.
• TCP then attaches TCP header to the message, making it a segment.
• Network layer receives it, adds another header, making it a datagram.
• Packet is a general name that refers to the message in each stage.

2. UDP: User Datagram Protocol

• Multiplexing (sender) means to gather information from different processes of different hosts,
  • then send the info down to network layer.
• De-multiplexing (receiver) means to receive packets from lower layer, then dispatching them to the right processes.
• UDP transmission is unreliable:
  • When data is lost, it does not get resent.

2-1. Connectionless De-multiplexing

• Destination port # is in UDP header.
• Packets with same destination port # is sent to the same UDP socket.

2-2. UDP Header

2-3. UDP Checksum

• Check the sum of the bits between sender and the receiver.
  • Same bits do not mean that the packets are void of errors.

2-4. Checksum Computation

• Sum by 16 bits, then flip the bits in the end.
• Carry on the last digit is added to the first digit.

3. Principles of Reliable Data Transfer

• Network layer is unreliable: data can get lost there.
• Building a reliable transport layer on top of Network layer is thus important.
  
• Possible Network layer Complications:
  • Packets can have their bits changed for various reasons.
  • Packets can get lost due to packet loss in the queue.
  • Packets can come in different order, because packet switching does not have resource reservation, so they can take different paths to reach the same destination.
  • Packets may come very late.

3-1. RDT (Reliable Data Transfer): Service Model

Finite State Machine

3-2. RDT 1.0: Perfectly Reliable Channel

• No error detection is needed.

3-3. RDT 2.0: Channel with Bit Errors

• packets may get corrupted.
• Use Checksum to detect error.
• How to recover?:
  • Acknowledgements (ACKs):
    • Receiver sends the sender that the packet is received well.
  • Negative Acknowledgements (NAKs):
    - Receiver explicitly tells the sender that the packet has errors
    - Sender then re-trasmits packets.
    
• The protocol is called stop and wait protocol because the sender sends, then waits for the receiver to send back the feedback.
  
• In the diagram we can see that there is a loop for sender:
  • Wait for ACK or NAK state will return to itself when the received feedback is NAK instead of ACK.

RDT 2.0: Flaws

• Even ACK or NAK can get corrupted.
• Sender has no idea if the receiver received the packet right.
• Solution: Ask the sender to send the packet again.
  
• For corrupted NAK, sending the packet again will be just fine,
• However for corrupted ACK, sending the packet again will create a duplicate of the already received packet.
• Duplicate happens because of corrupted ACK!!

3-3-1. RDT 2.1: RDT 2.0 + Sequence Number

• RDT 2.1 uses sequence number to detect duplicate packets.
• If the previously sent packet has the same sequence number as the one right now, then it is a duplicate. The new one is discarded.

RDT 2.1 Sender FSM:

• Sender waiting for data 0 can:
  • send the data straight away.
• Then sender waits for ACK or NAK:
  • Case 1: ACK, then move on to waiting for data 1.
  • Case 2: NAK, then re-trasmit the data 0.
  • Case 3: Data is corrupted, then re-transmit the data.
• The same is applied for data 1.

RDT 2.1 Receiver FSM:

• The receiver waiting for 0 from below can:
  • Case 1: receive corrupted packet, then sends the NAK feedback to the sender.
  • Case 2: recieve packet with sequence number 1 (duplicate):, then send ACK feedback with no data extraction and deliver.
  • Case 3: receive uncorrupted and right sequence # packet, then the receiver extracts the data, deliver the data to the upper lever, then sends ACK feedback. Moves on to waiting for 1.
• The same happens for waiting for 1.

3-3-2. RDT 2.2: NAK Free Protocol

• For receivers, instead of sending NAK for case 1, now it sends ACK1, indicating that data 0 is not received.
• For case 2, instead of just sending ACK, we send ACK1.
• Case 3 sends ACK0.
• Basically there is now a number added to ACK to differentiate NAK and ACK.

3-4. RDT 3.0: Corrupted, loss, and delayed.

• How do we detect packet loss?
• Use time-out retransmission!
  
• When the packet is lost while sending, receiver does not send back the ACK message.
• When certain time passes, the sender will resend the packet.
  
• Lost of ACK1 resends the packet1.
  • Duplicate packet can still be detected by packet sequencing.
• Sender ignores duplicate ACK message.:
  • Duplicate ACK message can happen due to delayed ACK message, in which case without ignoring the same message, the sender will send the same packet again.
  • Can also happen due to corrupted packet (pck1 sent, ACK1 received, pck0 corrupted, ACK1 received again).
    - In case of RDT 2.2, duplicate ACK message would send the packet again because the only possible problem is corrupted packet.
    - For RDT 3.0, it is also possible that it's due to delayed ACK feedback. Ignoring the message will make the sender resend the packet due to time-out.
    
• We can see the circled part does not do anything when the packet is corrupted. It is just waiting for the time-out.