sliding window protocol slides and research

PRESENTATIONON

SLIDING WINDOW PROTOCOL

MADE BY:

AYUSH JAIN

ABOUT HCL

• HCL is a leading global Technology and IT Enterprise with annual revenues of US$ 5 billion. The HCL Enterprise comprises two companies listed in India, HCL Technologies and HCL Info Systems.

• The 3 decade old enterprise was founded in 1976. HCL has global partnerships with several leading multinational firms, including several IT majors.

ABOUT THE PROJECTThe project involves the following perspectives

of SLIDING WINDOW PROTOCOL (SWP)• Study of basic SWP• Implementation of SWP on Linux• Study of SWP with varying Window Sizes• Study the effect of Window Size on Bandwidth• Study the impact of Timeouts and Packet Size

HARDWARE & SOFTWARE REQUIREMENTS

• HARDWARE • One Intel-Pentium 2 System • SOFTWARE

– OPERATING SYSTEMS • Red Hat 7.1 Linux for compiling and executing Source Code• Windows 98 for studying SWP • EMULATOR • SWP Emulator (3 column and 5 column) to study effect of varying Window sizes

• BROWSER • Microsoft Internet Explorer 5.0

INTRODUCTION

• SWP (Sliding Window Protocol) is a connection-less protocol in one direction between a pair of users. It allows data to be sent in one direction subject to a maximum number of unacknowledged messages.

• The sliding-window algorithm is the basis of many standard network protocols, such as TCP and SPX. It ensures reliable, in-order delivery, and provides a mechanism for flow control and congestion control.

Sliding-Window Fundamentals

• The key feature of the sliding-window protocol is that it permits pipelined communication. In contrast, with a simple stop-and-wait protocol, the sender waits for an acknowledgment after transmitting every frame.

• As a result, there is at most a single outstanding frame on the channel at any given time, which may be far less than the channel's capacity.

SENDER• The sender assigns a sequence number to each frame, ranging from 0 up to some maximum

number.• At any instant of time, the sender maintains a list of consecutive sequence numbers

corresponding to frames it is permitted to send. This list, termed the sending window, represents frames sent but not yet acknowledged.

• When an acknowledgment arrives, the lower edge of the window is advanced to the corresponding sequence number, thereby allowing the sender to transmit new frames.

• Let SWS be the maximum sender window size.Let LAR be the sequence number of the last acknowledgment received.Let LFS be the sequence number of the last frame sent.

• The sender maintains the invariant:LFS - LAR + 1 <= SWS.

• Since frames currently within the sender's window may ultimately be lost or damaged in transit, the sender must keep all these frames in its memory for possible retransmission. Thus, the sender must have a buffer large enough to hold as many frames as there are in its window.

• The sender records the time at which every packet is sent. If the sender does not receive an acknowledgment for a packet before the timeout period elapses, it retransmits the original frame.

RECIEVER• The receiver also maintains a receiving window, corresponding to the number of out-of-

order frames it is permitted to accept. Any frames falling outside the window are discarded without comment.

• Let RWS be the maximum receiver window size.Let HFA be the highest-numbered frame that will be accepted.Let NFE be the next frame expected.

• The receiver maintains the invariant:HFA - NFE + 1 <= RWS.

• When a frame with sequence number s arrives, the receiver takes the following action.If s < NFE or s > HFA, then the frame is outside the receiver's window and so it is discarded.If NFE <= s <= HFA, then the frame is accepted.

• An acknowledgment for s is sent if the following conditions are met:1) s has not yet been acknowledged.2) all frames in the range from NFE to s have been received.

• In this way, the acknowledgments are cumulative. When the acknowledgment is sent, the receiver sets NFE = s + 1 and HFA = s + RWS.

MAJORSNAPSHOTS

OFTHE

PROJECT

SENDER SIDE

SENDER WINDOW

RECEIVER SIDE

RECEIVER WINDOW

Results Illustrating Basic Features

This section includes results and analysis of SWP . These conclusions have been drawn from extensive study of Sliding Window Protocol from books and web pages on Internet.These results are divided into two sections.1. The first section presents plots of sequence number vs. time, which

illustrate how the sliding window algorithm works.2. The second section emphasizes the impact of window size on

performance.

The following figure shows a plot of frames sent and acknowledgments received versus time for the SWP with a window size of 25 on a 100 Megabits/second Ethernet. In this case, the window size is clearly optimal. Acknowledgments arrive before all the frames in the sender's window have been sent; as a result, the sender transmits without interruption. The horizontal distance between the two lines represents the round-trip time. It is about 20 milliseconds.

The following figure shows a plot of frames sent and acknowledgments received versus time for the SWP with a window size of 10, again on a 100 Megabits/second Ethernet. In this case, the window size is too small. The sender transmits all the frames in its window before any of the acknowledgments arrive. In the interim, the sender is idle, as indicated by the plateaus in the graph. The effect is to reduce the communication rate.

The following figure shows a plot of frames sent and acknowledgments received versus time for the SWP with a window size of 300, this time for a 10 Megabits/second Ethernet. In this case, the window size is too large. The data quickly overflows the receiver's buffer, so most of the packets are dropped. The sender times-out waiting for acknowledgments, and then retransmits the lost packets. Since the window size is so large, this again causes buffer overflow at the receiver end. The result is a dramatic drop in the communication rate.

Bandwidth versus Window Size

The results show that window size has a dramatic effect on the performance of the protocol. From the previous subsection, we have an idea of how the sliding window protocol can "keep the pipe full", while not overflowing the receiver buffer. This convinces us of the existence of an optimal window size that maximizes the throughput.

The above plot displays the data collected on a 100 Mb/s Ethernet LAN with almost no background traffic. The data has similar characteristics to the previous case, except that performance increases more smoothly for small window sizes and levels off; conversely, it drops off more rapidly for large window sizes. This indicates that for faster networks there is a greater penalty for buffer overflow.

The above plot was collected in trials from the University of Montreal to Caltech. A striking observation is that for low window sizes the throughput increases almost linearly with window size. Furthermore the optimal performance is more than double that of TCP. From the above plots we see that, compared to communication over a LAN, communication over a WAN is sensitive to window size changes in cases where it affects performance positively, and less sensitive to window size changes when it affects performance negatively.

TIMEOUT

Timeouts play a crucial role in network performance. The following graph shows that an insufficient timeout period reduces performance. From this, it can easily be understood that we are re-sending packets unnecessarily when the timeout is too short.

PACKETSIZE

It has been observed that across a WAN lower packet size generally gives better performance, while across a LAN bigger packet size does. In the case of a WAN, the packet must go through many hops where defragmentation takes place. A smaller packet size will improve the performance. In the case of a LAN, however, defragmentation cost is low, and bigger packet size reduces the application level overhead.

FUTURE SCOPE• The project is a 3 column implementation of Sliding Window Protocol wherein a single

parameter --- Window Size is required. Herein after the server’s approval the client can start transmitting packets. The connection ceases if the client quits or the number of packets surpasses the Window Size, whichever earlier.

• The project can be enhanced to be a 5 column implementation of Sliding Window Protocol wherein two parameters --- Window Size and Maximum Sequence Number are required. The protocol has a maximum number of messages that can be sent without acknowledgement. If this window becomes full, the protocol is blocked until an acknowledgement is received for the earliest outstanding message. At this point the transmitter is clear to send more messages.

• The protocol was implemented on a single machine using loop-back IP address. The protocol can be implemented on two distinct machines using any serial communication media. The source code requires simple changes:a) Changing IP address field in client from loop-back address to the IP address of server

b) Changing port addresses on both sides.• Finally some timeout mechanism may be added to enhance the utility of project.