Compare what happens in a connection environment versus a connectionless environment when we answer each of the questions.
Detecting congestion
Usually high buffer usage indicates congestion. In connectionless environments, users typically share a common storage area. This sharing provides the opportunity for one misbehaving user to affect the transport performance seen by others. Any mischief can also be compounded by retransmission activity. In a connection transport, the ability to identify connections (and if necessary constructing a queue per connection) prevents one abusive user from affecting the service level of others. It helps detect congestion and, if necessary, pinpoint the individual, misbehaving user.Which packet do you throw away?
The primary question here is: What action does a node in the transport take when it becomes congested? With a stateless environment, the origin of traffic arriving at a congested network node is not known. Nodes could examine the packet header, but this extra processing cannot be performed in a high-speed environment. Typically, in a connectionless environment, discarding packets is the usual response to congestion. The decision of which packet(s) to discard is important. When responding to congestion, should a node discard an arriving packet or an existing packet in the queue? If a node discards a packet from the queue, how does it decide which one? IP networks do not have state information to determine the cause of congestion and the best recovery actions.The fundamental philosophy of the connectionless environments is that there is no state; therefore, congestion control is problematic. We certainly do not want to throw away high priority traffic. Prioritization is most important when congestion is occurring. Without an effective transport-wide congestion control scheme, the network is unable to fairly prioritize different types of traffic. In a connectionless transport, detecting and dealing with congestion is extremely difficult.
Reporting congestion
How is congestion reflected to the senders that are causing the problem? TCP/IP does have an optional feature called source quench. A transport node can issue a source quench packet to indicate congestion. However, because an IP node doesn't know who is causing the congestion, there is no guarantee that the location that receives the source quench packet caused the congestion problem. If a TCP sender is not causing the congestion problem and elects to slow down because of source quench notification, it only penalizes itself and makes even more bandwidth available to the traffic causing the congestion. Also, while the source quench packet is making its way through the network, the transport could reroute traffic making the source quench packet irrelevant. For these reasons, most IP network products do not support source quench activity. Any rerouting decision is also uncontrolled (that is, not planned or managed to ensure overall network stability or to meet Quality of Service objectives). Load may be simply transferred elsewhere, potentially causing thrashing or other problems.A partial solution?
One potential solution to some of the congestion control limitations unfortunately does not solve all of our connectionless performance problems. The solution is to prevent limitations from becoming an issue by using a design and capacity planning strategy that deliberately underutilizes transport components. That's why router advocates respond to performance problems with three words: "add more capacity". In fact, this line of reasoning implies that overcapacity is the only effective congestion control mechanism for connectionless environments. This philosophy not only wastes money but has limited effectiveness in bursty, high speed environments. Also, it is well known that carriers make more money and users save more money when network resources are effectively used.
TASK
All the above is just background to the problem. You must read the following paper, which is called Internet congestion. This paper will give you all the background neccessary to understand the importance of this area of research. Basically, we are looking for keen students to take this research further and this assignment is just a starting point. Students are free to conduct their own experiments instead.Therefore the project is to conduct a series of experiments of sending ping packets to the following web sites:
http://www.netscape.com
http://www.ebay.co.uk
http://www.infc.ulst.ac.uk
http://www.acca-australia.org
Do it over a period (as in the paper). Look for strange results, bottlenecks etc. Read the literature surrounding this area of networking, suggest methods of improving bandwidth utilisation etc.
The end-result should be a thesis outlining your approach, results and evaluation.
Note:
You are not tied to using the Ping Plotter Utility. There may be better programs out there. One good starting
point is at Locate Software's Homepage or Tucows. I'd like to see different packages
used and comments on any improvements over Ping Plotter.
This project is obviously linked to tools such as Ping and
NeoTrace Program.
To contact Author: Email: [email protected]