CLAMP: End-to-End Window Based Flow Control for Low & Variable Bandwidth (e.g. Wireless LAN, xDSL, HFC Modem) Terminated IP Access Networks
(My Main Thesis Topic)

In this paper we propose a novel, sliding window, flow control algorithm for controlling the total queue size at a single bottleneck link, the practical implementation of this algorithm is called CLAMP (See below).   We present a theoretical fluid model of the system, which demonstrates the algorithm simultaneously controls the queue size and ensures equal (or differentiated) bandwidth allocation to independent flows.

Our proposal only requires aggregate network feedback information from the bottleneck node to the receivers (no per flow information is required).   Hence, it remains within Internets end-to-end framework.  The algorithm does not require estimates of propagation delays in the network, and provides fair operation that is independent of propagation delays.

We have recently modified the algorithm to work with non-greedy sources, and provide differentiated sharing of the bottleneck capacity.  Several  papers on different aspects of this work has been submitted for publication.

Related Publications:

1. Rami Mukhtar, Stephen Hanly, and Lachlan Andrew, "Efficient Internet Traffic Delivery over Wireless Networks", IEEE Communications Magazine, December 2003, Pages 2-9.
2. Lachlan Andrew, Stephen Hanly and Rami Mukhtar, "CLAMP: A System to Enhance the Performance of Wireless Access Networks,"  GLOBECOM 2003. 
3. Lachlan Andrew, Stephen Hanly, and Rami Mukhtar, "CLAMP: Differentiated Capacity Allocation in Access Networks," WORKSHOP ON END-TO-END SERVICE DIFFERENTIATION (EESD2003)
4. Lachlan Andrew, Stephen Hanly, and Rami Mukhtar, "Analysis of a Flow Control Scheme for Rate Adjustment by Managing Inflows,"  The 4th Asian Control Conference, September 25-27, 2002, Singapore.

CLAMP is an acronym for "Curtailing Large AWNDs to Maximize Performance".

In summary CLAMP is a receiver side congestion avoidance algorithm that uses the TCP receiver side advertised window (AWND) to limit the amount of unacknowledged packets the sender can inject into the network.

The philosophy behind receiver side control is as follows.  For specialized access network, e.g. wireless, usually the receiver knows more about the nature of the connection then the sender.  For example, if the rate changes between several distinct values, due to changes in the modulation scheme, maintaining a queue at the base station may be preferable.  Or perhaps the administrator may want to control the proportion of the precious link capacity allocated to each user.  It wouldn't make sense to deploy these special features, specific to the access network over the whole Internet.  Hence, it makes sense for the receiver to have some control over the rate at which packets are sent into the network, this void is filled by CLAMP.  Congestion control is still relevant in the core, that is why CLAMP works in conjunction with TCP and active queue management mechanisms.

TCP will set its window (the maximum number of unacknowledged packets in the network) to the minimum of its congestion window (CWND) and AWND.  Hence, if congestion in the core is more severe, TCP and active queue management mechanisms control the send rate.  Otherwise, if the access network is the bottleneck, CLAMP will limit the send rate by setting the AWND at the receiver.

The majority of existing differentiated services architectures rely on the sender to mark each flow according to the applications requirements.  The network will then endeavor to meet these quality of service requirements.  Although this model may provide a reasonable network wide solution, it is highly limited in flexibility, and does not empower the network administrator in any way.

Consider a small to medium size access network.  The administrator may want to have the ability to give preferential access to particular users, so that they can obtain a larger proportion of the capacity when they need it, relinquishing the capacity to lower priority users when they become idle.  Alternatively, a user may want to assign a higher rate to one particular FTP flow.  All of these requirements are satisfied by CLAMP.  CLAMP is a receiver side implementation, hence, a user that has control of the receivers is capable of controlling service priorities as best suits their requirements.  This is the advantage of receiver side congestion control!

CLAMP reduces TCP network buffering requirements and fixes fairness problems!

TCP's Additive Increase Multiplicative Decrease (AIMD) algorithm is a simple a robust way to equally share the capacity of a link between two flows that have identical network characteristics.  However, flows with longer Round Trip Times RTTs will obtain a smaller proportion of the bottleneck capacity then a flow with a smaller RTT.

Furthermore, due to the nature of the AIMD algorithm, for a single flow to fully utilize the channel the buffer size must be set to be equal to the bandwidth delay product!  This is huge, and literally doubles the number of in-flight packets that should be in the network.  By carefully controlling the bottleneck buffer occupancy, CLAMP solves both of these problems simultaneously.

Conditional on using existing TCP Reno flow control as a sender side congestion control technique.  Receiver side window control is the only way to solve the bottleneck capacity sharing problem.  If only a single flow is active, then receiver side control is the only way to reduce buffering whilst maintaining maximum utilization.  CLAMP is an algorithm to set the receiver side window in a distributed way to satisfy the above objectives.  

This is the topic of my Ph.D. Thesis. The focus of my research is to look at the performance of existing TCP implementations over cellular networks.
Questions I address:

• How does the performance of TCP suffer as the random Bit Error Rate (BER) increases?
• How is TCP (and sliding window flow control) effected by variations in packet transmission times?
• What should be the key aims of a link layer protocol in order to optimize transport layer protocol performance?

1. Rami G. Mukhtar and Stephen V. Hanly (2001). "A Model for TCP Behavior over Cellular Radio Channels with Link Layer Error Recovery". Globecom, San Antonio, Texas, IEEE.
2. Rami G. Mukhtar, Stephen V. Hanly, Milosh Ivanovich, Paul Fitzpatrick and Hai L. Vu (2001). "Analysis of TCP Performance over Hybrid "Fast Fixed - to - Slow Wireless" Buffered Links". Globecom, San Antonio, Texas, IEEE.
3. Rami G. Mukhtar, Moshe Zukerman and Fraser Cameron (2002). "Packet Latency for Type-II Hybrid ARQ Transmissions over a Correlated Error Channel". EUROPEAN WIRELESS 2002 conference, Italy.
   • Rami G. Mukhtar,  Moshe Zukerman and Fraser Cameron, "A Model for the Performance Evaluation of Packet Transmissions Using Type-II Hybrid ARQ over a Correlated Error Channel," Accepted for Publication in Wireless Networks
     Note: This is an extended version of the conference paper.
4. Rami G. Mukhtar and Stephen V. Hanly (2001). "TCP Time Outs Caused by Wireless Link Layer Transmissions". (Technical Report)

A content distribution network (CDN) is comprised of two fundamental but coupled mechanisms: 1) A measurement subsystem that ascertains the network state and load of the serving nodes.   2) A request routing mechanism that distributes client requests to the edge server which can optimally serve the request.

We have developed a novel and distributed client side measurement technique which we have shown experimentally to provide information which more accurately describes both the server load and network state.  We couple this measurement technique with an efficient request routing mechanism.

Related Publications:

• Zvi Rosberg and Rami Mukhtar, "Architecture for Open Content Delivery Networks," (submitted for publication).
• Rami Mukhtar and Zvi Rosberg, "A Client Side Measurement Scheme for Request Routing in Virtual Content Delivery," (Accepted for publication in IEEE International Performance, Computing, and Communications Conference 2003)

I have done some research on network management, in particular management systems that intemperate across firewalls, and interface with legacy devices.
 

Djalalian, A., Mukhtar, R.. and Zukerman, M. “Unified web-based network management system based on distributed object orientated software agents,” Proceedings of the SPIE's International Symposium: Asia-Pacific Optical and Wireless Communications (APOC), Shanghai, China, to appear 14-18 October, 2002.

A Presentation that I gave on the above paper (Power Point File)

We have done some research on enhancing IP mobility management techniques for integration into GPRS networks.  In particular we have devised a mechanism to provide efficient mobility management across GPRS networks.
 
 

• Seong Gon Choi, Rami Mukhtar, Jun Kyun Choi and Moshe Zukerman, "Efficient Macro Mobility Management for GPRS IP Networks, " (Accepted for Publication)

This is some work I did whilst doing a summer scholarship at The Australian National University in 1996.
 

• J. Robert-Ribes and R.G. Mukhtar, "Automatic Generation of Hyperlinks Between Audio and Transcript," 5th European Conference on Speech Communication and Technology 22-25 September 1997

QNS simulates networks of queues - IP networks - stochastic networks - or any other type of queueing network.

I wrote QNS2 because I was initially very frustrated with NS2.  The main problem I had with NS2 was that the learning curve was way too steep, and the documentation was very scanty at the time I wanted to use it!  Accordingly, I decided to write my own Queueing Network Simulator.  Hence, QNS was born!

The main strategy behind QNS was to keep things simple!  One thing that frustrated me about NS was that if you wanted to add a new protocol or algorithm you really had to have a very good understanding of basically the whole NS structure.  Accordingly, I wrote QNS to be as self contained as possible.  Adding a new protocol such as a new variant of TCP requires the programmer to just write a single C++ file that contains the entire TCP state machine.  The only other modification to the core simulator is to change to parsing file to hook into the new module.