Stack Processing Algorithm for Go Back N protocol Team Members: Vinti (vv2236) Garvit Singh (gs2731) Pramod Nayak (ppn2106) Vidhatre Gathey (vvg2111)

Contents Introduction: Go back N protocol Algorithm Software Modules Terminating Conditions Go Back N EFSM Assumptions

Go Back N protocol Allow multiple packets in transmission so that the line isn’t idle in networks with long delays Accept all packets in proper order If packet ‘i’ lost, Transmitter sends ‘i+1’ and receiver receives ‘i+1’ out of order and rejects it After time out, Transmitter must go back and retransmit the lost frame and subsequent frames

Stack Processing and Probabilistic Search Form probabilistic search tree, create a push down pop up Place state with lowest probability at the bottom of the stack At each new step, pop the top most sequence If a low probability event leads to this state, increase the probability by 1

Software Modules Modular approach used to develop the software for portability to any EFSM. Software verified using ARQ protocol first. EFSM states and transition saved in the header file. For a new protocol, only the header file needs to be updated. Implementation done in C++, class used to implement the stack.

Algorithm Flow Chart

Terminating Conditions Check for incorrect service sequence, if there is one, stop Check the probability of the top most element poped from the stack. P = pow(0.0001, probability.top()) If P < , stop

GBN EFSM

Probabilistic Search

Assumptions If the receiver receives a message it is not expecting, it does nothing Sender goes into state of failure if it receives Ack of a packet greater than the base+window_size. The number of retransmissions by sender after timeout is limited, once the limit is hit, it goes into a state of failure A simplified sequencing of the analysis has been considered

STOP STATES We have stopped further analysis when We reach a state that has already been considered. Often when we considered a message getting lost in the forward channel, in such cases transmitter and receiver won’t change their states and there will eventually be retransmission(after timeout). Thus we made such states as stopping states. We also made those states as stopping states after which were not considering any message/ack lost, thus there will be successful transmission of the messages after that, and no need to visit states beyond that as they will not result in failure.

FALLACIES(software) Hard coding the FSM instead of generating it in software. Strict stack implementation instead of array based stack with pointers for the top tuple. Using only one ID for message number (mod N). Instead, two IDs should have been used, one the actual message number and other the mod N ID.

Not an exhaustive search. Though we know we are right we the approach but exhaustive search was time consuming and we did not figure out how to automate the process. Only one initial state has been considered. i.e our probabilistic model is always starting with initial state. (0, 0, M 0, E) FALLACIES(GBN model)

Only two cases considered in probabilistic model: Tx time for 1 message = 1 side propagation delay Tx time for 2 message = 1 side propagation delay

FALLACIES(GBN model) Propagation delay in forward and reverse channel are the same Receiver and transmitter are functioning properly, only the channel is lossy. The state machines can function very differently if we consider sender and receiver with weird behaviors, say holding back for certain amount of time and the responding with Ack or sending message.

Thank You !