Stack Processing Algorithm for Go Back N protocol

Team Members:Vinti (vv2236)

Garvit Singh (gs2731)Pramod Nayak (ppn2106)

Vidhatre Gathey (vvg2111)

ContentsIntroduction: Go back N protocolAlgorithmSoftware ModulesTerminating ConditionsGo Back N EFSMAssumptions

Go Back N protocolAllow multiple packets in transmission so that

the line isn’t idle in networks with long delaysAccept all packets in proper orderIf packet ‘i’ lost, Transmitter sends ‘i+1’ and

receiver receives ‘i+1’ out of order and rejects itAfter 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 sequenceIf 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++, <stack> class

used to implement the stack.

Algorithm Flow Chart

Terminating ConditionsCheck for incorrect service sequence, if there is

one, stopCheck the probability of the top most element

poped from the stack.P = pow(0.0001, probability.top()) If P < 10-16, stop

GBN EFSM

Probabilistic Search

AssumptionsIf the receiver receives a message it is not

expecting, it does nothingSender 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 whenWe 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.

<sender state, receiver state, forward channel, reverse channel>

(0, 0, M0, E)

FALLACIES(GBN model)

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 !