TODO for the next month

Just had a meeting with my advisor after a very long time. Below is a list of things we discussed about and the work that needs to be done. I am listing it here as I often tend to forget stuff immediately after the meeting.

• Have to write 2 papers. The first one will be for Sigmetrics 2007 in which we will concentrate on the experiments conducted for the wireless environment. The abstract for this conference is due on Oct. 27th and the full paper on Nov. 3rd. The set of wireless experiments are listed in the TOC of the thesis.
  
  The other paper will be for Networking 2007 in which we will concentrate on the experiments for resource utilization of a HB under multiple flows. In the setup, there will be n number of flows passing through a bottleneck HB. The graphs will be for Throughput (packets/sec) vs CPU Utilization. The graph should be a linear curve which will (intiution says) top off at a certain point. Compare this with the graph of Number of Flows vs CPU Utilization. The Full paper is due by Oct. 30th. (Seems a tough deadline to meet especially with the Sigmetrics one in parallel)
  


• The other most interesting part we discussed was about the alternate congestion control mechanism in the HB. We discussed about marking the packets with increasing probability as the resource utilization within the HB increases. There are 2 methods of marking - Explicit Marking and Minimal Marking.
  
  Explicit marking makes use of at least 2 bits. One bit is used to indicate that the packet is marked and the remaining are used to provide additional information. This information can be, but it not limited to, what should be the new cwd of the sender, by how much should the sender reduce the window etc.
  
  Minimal marking makes use of only 1 bit which indicates whether the packet is marked or not. We can change the values of _alpha_ and _beta_ to get some interesting results. See the notes.
  

Some issues concering marking of packets.

Lets assume that the HB is configured to mark packtes with probability of 1 once the resource utilization is about to reach a threshold. It will continue to mark packet till it receives an acknowledgement of the markings OR when it sees that the sender did reduce the window. However this change will be visible only after 1 RTT. If the traffic is intense, then the sender might reduce the window beyond what is required. Hence it is not a good idea to mark all packets.

A HB may be configured to mark a packet once per RTT. Similar to ECN. In this case there will too few a markings. In case of of intense traffic flow, this is not good as the flow will go into error recovery almost certainly.

Hence we decide to mark the packet with increasing probability as the resource utilization of the HB increases. Something imilar to what RED does.