The Organisation and Execution of the HICID Project
Peter T. Kirstein, 01 April 1999
The HICID project was conceived as an adjunct to the HIGHVIEW and JAVIC projects. It was intended to investigate QoS activities at the network level. Moreover these investigations were to be correlated with application activities at applications level with the other two projects.
It is now past the time of the end of the original proposed time of the work. The money on the project has actually been spent; however the work has gone in a somewhat different way from that originally envisaged. As a result, it has not been possible to make any claims; for that we must agree on a re-definition of the milestones or Deliverables to know what can be claimed. This note analyses what we have done, what we are doing, and how we propose to re-define the project. The note is in preparation for a discussion with BT at the end of April.
We are building and operating a wide area IP over ATM network infrastructure based on PC routers capable of providing advanced scheduling and queue-management facilities not currently implemented in production routers. As a test host platform we use the FreeBSD 2.2.8 and ALTQ-1.1.3 with ATM support.
The purpose of this testbed is to allow experiments conducted under the HICID project and the others (HIGHVIEW, JAVIC) that evaluate the aspects of QoS provision in high speed networks: management overhead for operating the infrastructure, performance, assurance, impact on applications and users.
Configuring and controlling the QoS mechanisms has been proved to be a non-trivial task especially in a relatively "novel" environment like ATM since most of the QoS mechanisms and the transport protocols are optimised for use over Ethernet. We have explored the implications of the ATM layer idiosyncrasies (e.g. large link MTU, multiple point-to-point connections on the same physical interface) both on transport protocol performance (especially TCP when it coexists with UDP flows) and the performance of the CBQ mechanism in particular. We will be presenting exact details in a Technical Report to be published in April '99. [ We expect that the information in this Technical Report will be the main deliverable and contribution; we already have a working draft]
We have focused mainly on the CBQ algorithm that is the milestone for network resource management (link sharing, rate limiting) and involves the greatest complexity of all the algorithms. We have experimented also with Weighted Fair Queuing (WFQ) and RED, and have also used RSVP for end-to-end QoS provision. The Hierarchical Fair Share Curve (HFSC) implementation from CMU has also been evaluated.
For all the work so far, we have used the UCL local testbed; only recently have we started being able to achieve connectivity experiments through a route, which includes only CAIRN routers between UCL and Essex. For the period immediately after Easter we have planned experiments between UCL and Essex with multimedia real time streams that pose strict bandwidth and delay requirements. The challenge we face is to find CBQ configurations that are flexible and general enough to provide this particular type of service.
For the performance measurements we use already existing tools for traffic generation (ttcp) modified for our purposes, packet capture (tcpdump), cbq and red router statistics. We have developed our own utilities for analysing the packet traces.
In the original contract, the milestones envisaged are listed below. Here we should remember that the project started officially at UCL on February 1, 1998 - as explained in our first Progress Report dated March 24, 1998. In the event, LEARNET was not properly available until late in the year for experiments; hence some delay in the later part of the project was inevitable. .
|
NO |
ACTIVITY |
COMPLETED Month |
|
1 |
Set up workstations, conference rooms, networks, basic routers |
6/98 |
|
2 |
Set up gateways, measurement facilities, servers, routers with PIM and with DVRMP |
4/98 |
|
3 |
Do test experiments with PIM and DVMRP; set up RSVP, CBT and WFQ and RED |
5/98 |
|
4 |
Do test experiments with WFQ + RSVP, CBT and RSVP, WFQ + RED |
8/98 |
|
5 |
Do application level experiments and pilot trials on MECCANO, HIGHVIEW and JAVIC tools with different Servers with single streams |
11/98 |
|
6 |
Extend test and application trials to use the later versions of the above tools, with improved QoS reservations. |
5/99 |
Table 1 Original Milesones based on a start date of February 1, 1998
If we compare Table 1 with the progress described in Section 2, we have done far more than intended on QoS activities, and have largely done Nos 1-4. We have not done one important aspect - the set-up of PIM and VMRP. These do not exist on our CAIRN platform, and we have planned to do serious experiments in HICID only with the CAIRN platform, not the Cisco one. We have really concentrated on the CBQ activity, and done it far more thoroughly locally than anticipated initially (remember we only have a total of 10 pm in the project!). I propose, therefore, that the last progress report, which describes the platform that has been set up, counts as achieving the milestone M1 and M2; with the ALTQ and HFSC replacing the PIM and DVMRP which are dropped from formal Deliverables.
When we describe the local experiments we have done on ALTQ and HFSC, we will have completed M3; the follow-on ones over the LEARNET testbed should count as M4. I would therefore propose that a draft of the current local experiments be prepared and submitted as M3; the early experiments with the HIGHVIEW and JAVIC applications count as M5, should be completed by 6/99 and will count as M5. Those done during the summer will count as M6, with a completion date of 9/99.
We hope to do further experiments on QoS with the Cisco routers; however, we have no experience on what they have in them, they are not as prevalent, and we do not have the same degree of remote control of them. For this reason, we would not like this to be part of the formal Deliverables.
Based on the above, I would advise our financial people on the revised billing schedule.