CS/EE 145ACS/EE 145A Reliable Reliable

Transmission over Transmission over Unreliable Channel Unreliable Channel

IIIINetlab.caltech.edu/courseNetlab.caltech.edu/course

Reliable Communication Reliable Communication over Unreliable Channelsover Unreliable Channels

Retransmission for Lost Packets: Retransmission for Lost Packets: Loss SignalsLoss Signals

Sliding-Window AlgorithmSliding-Window Algorithm Protocol State MachineProtocol State Machine Lab 3Lab 3

Lab 3Lab 3 How to split a file into packets?How to split a file into packets? How to detect errors (packet corruption, How to detect errors (packet corruption,

packet loss, duplication, reordering…)?packet loss, duplication, reordering…)? How to recover from packets reordering?How to recover from packets reordering? How to recover from loss?How to recover from loss? How to use the bandwidth efficiently?How to use the bandwidth efficiently? How to share the bandwidth fairly?How to share the bandwidth fairly? ……

Last class…Last class…

TCP:TCP: Reliable Transmission Reliable TransmissionGuarantee: The packets sent will be Guarantee: The packets sent will be

received with the same order.received with the same order.File SystemFile System

Stream Stream

P1, P2, … ???

This class!This class!

TCP:TCP: Reliable Transmission Reliable TransmissionGuarantee: The packets sent will be Guarantee: The packets sent will be

received with the same order.received with the same order.IP:IP: Unreliable Transmission Unreliable Transmission

Best Efforts: Packets can be dropped, can Best Efforts: Packets can be dropped, can be reordered, can be duplicated, can be …be reordered, can be duplicated, can be …

Stream Stream

P1, P2, … ???

What’s the difference?What’s the difference? Packets cannot arrive at the same Packets cannot arrive at the same

timetime The sender and receiver should be The sender and receiver should be

able to know the start of the flow able to know the start of the flow and the end of the flowand the end of the flow

The receiver has to let the sender The receiver has to let the sender know which packet is lost.know which packet is lost.

Even worse…Even worse…

Loss SignalsLoss Signals Form: Piggyback vs. Control PacketForm: Piggyback vs. Control Packet Signal: Acknowledgment vs. Signal: Acknowledgment vs.

Negative AcknowledgementNegative Acknowledgement Amount of information: one packet Amount of information: one packet

vs. multiple packetsvs. multiple packets

Piggyback vs. Control Piggyback vs. Control PacketPacket

PiggybackPiggyback• Each packet in the Each packet in the

reverse traffic reverse traffic carries control carries control information for the information for the forward traffic.forward traffic.

• Good for two-way Good for two-way traffic.traffic.

• RobustRobust• Less overheadLess overhead

Control PacketControl Packet• Special packets carry Special packets carry

control informationcontrol information• Usually uses NACKUsually uses NACK• Good for one way Good for one way

traffictraffic• May carry more May carry more

informationinformation• Less robust or More Less robust or More

overhead?overhead?

ACKACKRTT

time

time

Source

Destination

1 2 W

1

1 2 W

data ACKs

1 2

1 2 W

ACK (Loss Detection by ACK (Loss Detection by Timeout)Timeout)

Time Out!Time Out!RTT

time

time

Source

Destination

1 2 W 1 2 W

data ACKs

1

1 2 W

ACK (False Loss)ACK (False Loss)Time Out!Time Out!

RTT

time

time

Source

Destination

1 2 W

1

1 2 W

data ACKs

1

1 2 W

NACK (Loss Detection)NACK (Loss Detection)

time

time

Source

Destination

1 2 W

data NACK:3

1 2 4

3 4 3

3 41 2

NACK (NACK Loss)NACK (NACK Loss)

time

time

Source

Destination

1 2

data NACK:3

1 2 4

3 4

3 41 2

W5

5

3

5

Stop & WaitStop & WaitRTT

time

time

Source

Destination

1 2 W

1

1 2 W

data ACKs

1 2

1 2 W

sec)/(1 pktRTT

T

Sliding WindowSliding Window

~ W packets per RTT~ W packets per RTT

RTT

time

time

Source

Destination

1 2 W

1 2 W

1 2 W

data ACKs

1 2 W

sec)/( pktRTTwT

w?

Loss Detection with Sliding Loss Detection with Sliding WindowWindow

Duplicate Acknowledgement Duplicate Acknowledgement indicates packet loss?indicates packet loss?

RTT

time

time

Source

Destination

1 2 W

2 W

1 2 W

ACK=1

1 2 W

ACK=w+1

How to start a flow?How to start a flow? Three-way handshake for TCPThree-way handshake for TCP Simpler Handshake for one-way Simpler Handshake for one-way

traffic:traffic:• Add a flag field in packet header for Add a flag field in packet header for

starting signalstarting signal• Anything to be negotiate in your Anything to be negotiate in your

protocol?protocol?

How to end a flow?How to end a flow? TCP styleTCP style Simpler solution for one-way traffic?Simpler solution for one-way traffic?• Add a flag field in packet header for Add a flag field in packet header for

ending signal?ending signal?• Which side should disconnect first? Which side should disconnect first?

Why?Why?• Does a perfect solution exist?Does a perfect solution exist?

How to design?How to design?The concept of protocol state and The concept of protocol state and

finite state machine (FSM)finite state machine (FSM) Have a clear idea of your designHave a clear idea of your design Follow the transition in state Follow the transition in state

machine during implementationmachine during implementation Test the implementation according Test the implementation according

to the transition graphto the transition graph

State Transition GraphState Transition Graph

I nitialConnectionList

={}

Listen

Start/

UDPCommunication UDP got msg/

/ read msg and reply

I ncoming Sock: i /

TCPConnection

TCPCommunication

Sock i is activated/

Something to read/Read sock i and reply

/ ConnectionList=ConnectionList+{i}

Client Disconnect/ConnectionList

=connectionList-{i}

State Transition GraphState Transition GraphBasic (FSM):Basic (FSM): Possible State SetPossible State Set Possible Input SetPossible Input Set Possible Output (Action) Set*Possible Output (Action) Set* State Transition Set: State Transition Set: {(origin_state[i], input[i], output[i], target{(origin_state[i], input[i], output[i], target_state[i])}_state[i])} Initial State SetInitial State Set

I nitialConnectionList

={}

Listen

UDPCommunication

TCPConnection

TCPCommunication

Something to read/Read sock i and reply

/ ConnectionList=ConnectionList+{i}

Concept of “State Concept of “State Machine”Machine”

Flexible for Extensions:Flexible for Extensions: VariablesVariables TimersTimers Informal conditions and actionsInformal conditions and actions

Implement a State Implement a State MachineMachine

Define protocol state: SDefine protocol state: S Translate the transition graph into prograTranslate the transition graph into program:m:If ((S== origin_state[i]) && (Input==input[i]))If ((S== origin_state[i]) && (Input==input[i])){{ Action=output[i]Action=output[i]

S=target_state[i]S=target_state[i]}}

Test the implementationTest the implementation Design test case according to the Design test case according to the

transition graph:transition graph:• Is each transition covered by at least Is each transition covered by at least

one test case?one test case?• Is each action covered by at least Is each action covered by at least

one test case?one test case?

States for TCP States for TCP ConnectionConnection

Lab 3Lab 3

Lab 3 - TaskLab 3 - Task Implement a reliable communication Implement a reliable communication

protocol over UDP:protocol over UDP:• Revise your packet format definition Revise your packet format definition

in Lab2in Lab2• Implement packet retransmissionImplement packet retransmission

Lab 3 - RequirementsLab 3 - Requirements The implementation is based on UDP.The implementation is based on UDP. The implementation is able to send a The implementation is able to send a

file from one machine to the other.file from one machine to the other. The network in the middle is not The network in the middle is not

reliable: The network may drop or reliable: The network may drop or duplicated or reorder some packets in duplicated or reorder some packets in the middlethe middle

Assumption: A single packet will not be Assumption: A single packet will not be contaminated. (Don’t worry about the contaminated. (Don’t worry about the error inside one packet)error inside one packet)

Lab 3 - DetailsLab 3 - Details Two programs: “sender” and “receiver”Two programs: “sender” and “receiver” Sender should be able to read a file from the local Sender should be able to read a file from the local

disk, cut it into packets, and send it to the disk, cut it into packets, and send it to the receiver.receiver.

Sender can use a port to listen to the feedback Sender can use a port to listen to the feedback from the receiver.from the receiver.

Receiver should be able to listen to a port, get the Receiver should be able to listen to a port, get the packets from the sender, and send feedback to packets from the sender, and send feedback to the receiver, if necessary.the receiver, if necessary.

Assumption: Assumption: There is only one sender and one receiver. (All There is only one sender and one receiver. (All

the packets to the sender is from the receiver, the packets to the sender is from the receiver, and vice versa.)and vice versa.)

<Filename> is a text file in the local disk<Filename> is a text file in the local disk

Lab 3 – Details: SenderLab 3 – Details: Sender Format: “sender <port1> <IP> <port2> Format: “sender <port1> <IP> <port2>

<Filename>”<Filename>”• Port1: the port you are listening to the Port1: the port you are listening to the

receiver’s feedbackreceiver’s feedback• IP: the receiver’s IPIP: the receiver’s IP• Port2: the receiver’s portPort2: the receiver’s port• Filename: The file to be sentFilename: The file to be sent The sender should read from <filename>, The sender should read from <filename>,

send the content of the file to <IP> send the content of the file to <IP> <port2>, and listen to port1 for feedback <port2>, and listen to port1 for feedback from the receiver.from the receiver.

Lab 3 – Details: ReceiverLab 3 – Details: Receiver Format: “receiver <port1> <IP> <port2> Format: “receiver <port1> <IP> <port2>

<Filename>”<Filename>”• Port1: the port you are listening to the Port1: the port you are listening to the

sender’s datasender’s data• IP: the sender’s IPIP: the sender’s IP• Port2: the sender’s listening portPort2: the sender’s listening port• Filename: The file to be savedFilename: The file to be saved The receiver should listen to <port1> for The receiver should listen to <port1> for

data, write the data to <filename> and data, write the data to <filename> and send feedback to <IP> <port2> (sender) send feedback to <IP> <port2> (sender) if necessary.if necessary.

Lab 3 - Possible Lab 3 - Possible ProblemsProblems

How to design the packet format? How to design the packet format? What kind of feedback? (ACK/NACK? What kind of feedback? (ACK/NACK?

Control packet / piggyback?)Control packet / piggyback?) How to detect loss? (Timeout? How to detect loss? (Timeout?

Duplicate ACK…)Duplicate ACK…) How to maintain the window (If you How to maintain the window (If you

use window scheme)?use window scheme)?

Lab 3 - TipsLab 3 - Tips Re-Use the codes in Lab 1 and Lab 2Re-Use the codes in Lab 1 and Lab 2 Packet format?Packet format?• Packet type? (initial packet, ack Packet type? (initial packet, ack

packet, terminating packet…)packet, terminating packet…)• Packet length?Packet length?• Packet sequence number? Packet sequence number? • Data area…Data area… Window maintenanceWindow maintenance How to Test?How to Test?

Lab 3 Lab 3 Due: Nov 21Due: Nov 21stst (Friday) 23:59:59 (Friday) 23:59:59 Email: Email: weixl@caltech.eduweixl@caltech.edu GradingGrading TA hours: TA hours: Tue / Thu (20:00 – 22:00) JRG 170Tue / Thu (20:00 – 22:00) JRG 170