Group1_Charisma: Selective Repeat ARQ Ppt

Group1_Charisma: Selective Repeat ARQ

Below is a link to an applet which animates the Selective Repeat ARQ protocol:

http://media.pearsoncmg.com/aw/aw_kurose_network_3/applets/SelectRepeat/SR.html

Group1_Charisma:Questions and Answers

1. What is the difference between fragments and packets? (Questioned by Supriya)

Ans: There exists something called maximum resolution unit (MRU) which gives the maximum size of a packet which can be transmitted through a network. If the packet size exceeds this limit, it has to be fragmented. Each fragment has an identifier and ultimately once the fragments are transmitted, they are reassembled to get the original packet back. (Answered by Sridevi)

2. What is an open port? (Questioned by Bhargavi)

Ans:Open port is a TCP/IP port number that is configured to accept packets. Open port is considered a potential security risk and acts as an avenue for attack. Hackers use port scanning software to exploit the open ports.
In contrast, a closed port is a port which is set to deny all packets with that port number. (Answered by Ramya)

3. Explain 3 way handshake. (Questioned by Dhanusha)

Ans:Consider host A downloading some data from host B. Host A initially sends a SYN flag to host B which then responds by sending an ACK along with a SYN flag indicating it is ready for the virtual connection to be established. Finally host A sends an ACK and the virtual connection gets established.
Two synchronous flags are involved in a given data transfer, one sent by host A and the other by host B. (Answered by Nagchandrika)

Group1_Charisma:Mandatory Blog

Team Name: Charisma
Team Members: M Ramya(1MS07IS042), Madhura S Karanth(1MS07IS042), Nagchandrika Rao(1MS07IS056), Sridevi YV(1MS07IS137)
Group A Project Chosen: Network Protocol Analysis
Group B Project Chosen: Selective Repeat ARQ
Presentation Date of Group A Project (Completed / Not Completed as on Blog Date): Completed (On 21st October,2009).
Presentation Date of Group B Project (Completed / Not Completed as on Blog Date): Not completed. (To be presented on 18th November,2009)
Group A PPT Uploaded(Yes or No): Yes
Group B PPT Uploaded(Yes or No): No
Group A Project Report Made(Yes or No): No
Group B Project Report Made(Yes or No): No
Group A Project PROBLEMS FACED and SOLVED Blog Uploaded(Yes or No): Yes
Group B Project PROBLEMS FACED and SOLVED Blog Uploaded(Yes or No): No

Group1_Charisma:Network Protocol Analysis Ppt

Group1_Charisma:Problems faced during the course of groupA project

Problem faced: Selecting the right tool other than wireshark which is efficient as well as easy to use.Since initially the only thing we knew about protocol analysers was that they decode packets,though we came across quite a few tools, we were in a fix as to which is a better one and which could be chosen and also whether to use ubuntu or windows platform.

Solution: Once we decided that we are going to use windows,we started scanning the different protocol analysers available for windows and etherdetect caught our attention mainly because it was very simple and easy to use,and we decided to use it.Though it misses out some of the features provided by wireshark,it does show the essential packet details and hex code of the corresponding data and can be easily configured according to our needs.

Problem faced: Gathering theoritical information about protocol analysis and understanding it.Demonstration of the network protocol analyser is the heart and soul of our project and hence we didn’t have much idea as to what theory can be presented other than basics like what an analyser is and why it is used.

Solution: We decided to explail each packet detail i.e each header field and what exactly the values associated with the fields interpret.We gathered information and learnt  about every new technical word or concept we came across during this process.

Problem faced: Demonstration of the tool.We wanted to make it innovative and demonstrate any of the applications of protocol analysis like password detection or spying etc and the main barriers were lack of sufficient knowledge,unavailability of required tools(ACE PASS DETECT was blocked by anti-virus).

Solution: We couldn demonstrate any of the applications mentioned above.However we used VOISE website as an example and could actually show the source code of it encapsulated in the data portion of the packet captured when the website is hit.

Group1_CHARISMA_Report(5)

Due to the upcoming internals, we didn’nt manage any susbstantial development to either projects.

Group 1_Charisma:NPA

Wireshark was the tool which was supposed to be used by us to demonstrate the protocol analysis.Since its more relevant for the TCP dump using team to use the same we have decided to use a tool called Ether Detect.

EtherDetect Packet Sniffer is an easy for use and award-winning packet sniffer and network protocol analyzer, which provides a connection-oriented view for analyzing packets more effectively. With the handy tool, all that one needs to do is to set up the filter, start capturing, and view connections, packets as well as data on the fly.

Features of Ether Detect:

• Organize captured packets in a connection-oriented view

Traditional sniffers or protocol analyzers just put everything captured together without any further categorizing. However, no matter how we debug programs or analyze network traffic, we tend to follow the same TCP connection or UDP thread. Obviously, a messy view doesn’t fit our requirements, so EtherDetect provides a connection view as well as a common packet view. Therefore, it displays related packets together to enable users to analyze deeper information through packets. EtherDetect gives you an ideal opportunity to capture full TCP connections and UDP threads, which is essential for debugging programs, locating network problems, diving into network protocol, and extracting application data from a variety of packets.

 

• Capture IP packets on your LAN with nearly no packet lost.

EtherDetect Packet Sniffer utilizes the same packet-capturing engine as EffeTech HTTP Sniffer and Ace Password Sniffer, which is highly reliable and proven by thousands of our customers. This ensures the low packet-loss rate and high availability.

• Smart real-time analyzer enables on-the-fly content viewing while capturing and analyzing.

In traditional sniffers, you have to wait for sniffers to stop before viewing the result. That is very inconvenient, and sometimes
important packets will be lost during capturing halt. With the development of performance of computers, we have improved our analyzer engine thoroughly. In contrast to these traditional sniffers, EtherDetect allows you to view captured connections and packets while capturing. You may view packets on the fly with the same performance as traditional mode.

• Parse and decode a variety of network protocols.

EtherDetect Packet Sniffer’s highly advanced decoding engine is continually fine-tuned to deliver more optimized data analyzing and decoding for all sizes and all levels of protocol. EtherDetect decodes TCP/IP traffic and generates a protocol tree in real time. Also, it can highlight syntax of HTTP and HTML/XML.

• Support saving captured packets for reopening afterward.

EtherDetect Packet Sniffer saves captured packets into files in a format compatible with LibPcap and WinPcap. This allows you to use other programs, provided they support the same file format, to open packet file saved by EtherDetect. When you open a packet file, EtherDetect lets you select whether to apply the current filter to discard useless packets.

• Powerful filter provides a flexible mechanism to capture specific packets.

Its powerful filter mechanism enables you to set up a default packet accpetance policy and customized packet-capturing filters. Each packet will pass through every filter. If a packet is matched and explicitly accepted or dropped by a filter, other filters will not apply on the same packet. The default accpetance policy will apply if none of filters match. Thus, you will neither lose anything you want, nor will any irrelevant packets disturb you. You can focus on the problem directly and exclusively.

• Syntax highlighting for application data in the format of HTML, HTTP and XML.

EtherDetect Packet Sniffer provides a colorful data view. You can easily understand data inside captured packets.

Group 1_Charisma: More about Selective Repeat ARQ

Selective repeat is employed by the TCP transport protocol for error recovery during transmission of data packets which are referred to as PDUs,short for Protocol Data Units.

Features required for Selective Repeat ARQ

• To support Go-Back-N ARQ, a protocol must number each PDU which is sent. (PDUs are normally numbered using modulo arithmetic, which allows the same number to be re-used after a suitably long period of time. The time period is selected to ensure the same PDU number is never used again for a different PDU, until the first PDU has “left the network” (e.g. it may have been acknowledged)).
• The local node must also keep a buffer of all PDUs which have been sent, but have not yet been acknowledged.
• The receiver at the remote node keeps a record of the highest numbered PDU which has been correctly received. This number corresponds to the last acknowledgement PDU which it may have sent.

The above features are also required for Go-Back-N, however for selective repeat, the receiver must also maintain a buffer of frames which have been received, but not acknowledged.

Recovery of lost PDUs using Selective Repeat ARQ

The recovery of a corrupted PDU proceeds in four stages:

• First, the corrupted PDU is discarded at the remote node’s receiver.
• Second, the remote node requests retransmission of the missing PDU using a control PDU (sometimes called a Selective Reject). The receiver then stores all out-of-sequence PDUs in the receive buffer until the requested PDU has been retransmitted.
• The sender receives the retransmission request and then transmits the lost PDU(s).
• The receiver forwards the retransmitted PDU, and all subsequent in-sequence PDUs which are held in the receive buffer.

 A remote node may request retransmission of corrupted PDUs by initiating Selective Repeat error recovery by sending a control PDU indicating the missing PDU. This allows the remote node to instruct the sending node where to retransmit the PDU which has not been received. The remote stores any out-of-sequence PDUs (i.e. which do not have the expected sequence number) until the retransmission is complete.

Upon receipt of a Selective Repeat control PDU (by the local node), the transmitter sends a single PDU from its buffer of unacknowledged PDUs. The transmitter then continues normal transmission of new PDUs until the PDUs are acknowledged or another selective repeat request is received.

If the retransmission is not successful, the protocol relies upon a ‘protocal timer’ in the local node to detect that no acknowledgment was received. The lost PDUs may then be recovered by polling.

Group1_CHARISMA_Selective Repeat Protocol: Introduction(4)

Selective Repeat ARQ is a specific instance of the Automatic Repeat-reQuest (ARQ) Protocol. It may be used as a protocol for

->The delivery and acknowledgement of message units, or

->The delivery of subdivided message sub-units.

When used as the protocol for the delivery of messages, the sending process continues to send a number of frames specified by a window size even after a frame loss. The receiving process will continue to accept and acknowledge frames sent after an initial error. The receiver process keeps track of the sequence number of the earliest frame it has not received, and sends that number with every ACK it sends. If a frame from the sender does not reach the receiver, the sender continues to send subsequent frames until it has emptied its window. The receiver continues to fill its receiving window with the subsequent frames, replying each time with an ACK containing the sequence number of the earliest missing frame. Once the sender has sent all the frames in its window, it re-sends the frame number given by the ACKs, and then continues where it left off.

When used as the protocol for the delivery of subdivided messages it works somewhat differently. In non-continuous channels where messages may be variable in length, standard ARQ or Hybrid ARQ protocols may treat the message as a single unit. Alternately selective retransmission may be employed in conjunction with the basic ARQ mechanism where the message is first subdivided into sub-blocks (typically of fixed length) in a process called Packet segmentation. The original variable length message is thus represented as a concatenation of a variable number of sub-blocks. While in standard ARQ the message as a whole is either acknowledged (ACKed) or negatively acknowledged (NAKed), in ARQ with selective transmission the NAKed response would additionally carry a bit flag indicating the identity of each sub-block successfully received. In ARQ with selective retransmission of sub-divided messages each retransmission diminishes in length, needing to only contain the sub-blocks that were NAKed.

In most channel models with variable length messages, the probability of error-free reception diminishes in inverse proportion with increasing message length. In other words it’s easier to receive a short message than a longer message. Therefore standard ARQ techniques involving variable length messages have increased difficulty delivering longer messages, as each repeat is the full length. Selective retransmission applied to variable length messages completely eliminates the difficulty in delivering longer messages, as successfully delivered sub-blocks are retained after each transmission, and the number of outstanding sub-blocks in following transmissions diminishes.

Applications:

->The ITU-T(International Telecommunication Union) G.hn (common name for the “next generation” home network technology standard being developed under the ITU) standard, which provides a way to create a high-speed (up to 1 Gigabit/s) Local area network using existing home wiring (power lines, phone lines and coaxial cables), uses Selective Repeat ARQ to ensure reliable transmission over noisy media.

->G.hn employs Packet segmentation to sub-divide messages into smaller units, to increase the probability that each one is received correctly.