HotPools Technology - Continued

HotPools provides the benefits of dedicated access without consuming ISP resources.

HotPools constantly monitors user demand and adapts by adding or removing capacity.

HotPools provides Outbound access allowing a new range of services and bridging the gap between dedicated and classic dial-up access.

Multiple HotPools can co-exist at the same location.

HotPools share all the pool resources to satify customer demand.

HotPool members constantly monitor the 'health' and resource status of all other members.

HotPools architecturally provides 'continuous available' within the pool.

HotPools provides 'fine-grained' control over Quality of Service.

HotPools allows a wide selection of criteria for priority allocation.

HotPools provides automatic priority inheritence for certain application e.g. FTP.

HotPools provides infinitely variable servicing of each traffic type.

HotPools provides multiple features for ensuring the optimal network performance in overload situations.

HotPools implements 'state of the art' network design principles optimized for delay-sensitive traffic e.g. VoIP.

Peer-to-Peer Networking

HotPools optimizes the use of available 'link' capacity in combination with ZyTrax’s advanced MPPP capability to create virtual (or on demand) access for both Inbound and Outbound users. The following features are provided:

• 'Always ON' Service - where the underlying communications media is connection oriented HotPools will use the appropriate method to ensure that a connection is only present when data is being tramsitted or received.. At all other times no (or the minimim) connection will exist.

• Capacity Checking - A user defined 'Time slice' is used to periodically measure demand on the 'links' and, if appropriate close or open connections. In the case of wireless or other permanently connected media this parameter is used to control or limit throughput and 'burst mode' capablities. This parameter is used in conjunction with the following additional parameters:

  • 'Threshold' for wired 'links' this defines the percentage of capacity used over the 'time slice' above which capacity will be added and below which capacity will be removed. In the case of wireless or other connectionless media this defines the amount of time that a user may 'burst' to full link capacity.

  • 'Capacity' for wired 'links' this defines the maximum number of channels that may be used. For wireless or other connectionless media this defines the maximum allowed throughput in the 'time slice' and provides a means to limit user throughput even on lightly loaded connections.

• Inbound and Outbound Access - HotPools equipment maintains configuration databases of user to IP address and DN or TSP/NSP mapping to enable outbound connection set-up. Both ends of the connection, being true peers, may be configured to initate connections.

When a Peer opens a 'link' resource it is deemed to 'own' that resource and its corresponding Peer cannot remove it. Each end of a 'link' can operate with different configurations. Take, as an example, a link between two countries one of which has a high calling cost the other a low calling cost. The Peer in the high calling cost location would typically be configured to open minimal resources and to release them very rapidly while the Peer in the high calling cost location would be configured to add additional capacity.

Distributed Resource Management

HotPools dynamically shares all the available resources to create 'fat pipes' for transmission and reception of data. It provides the following features:

• Pool Creation A single parameter in the router controls pool membership. Multiple pools may co-exist in a single location each pool having its own set of resources and characteristics.

• Pool Failover Pool members continuously monitor the status and availablity of all other pool members through the use of a 'heartbeat' and take appropriate steps to reconfigure automatically in the case of an error condition. Error detection and reconfiguration typically occur within 5 to 10 seconds.

• Pool Sharing All the 'link' resources of the pool are constantly available to all members of the pool. Demands for additional resources are thus taken from the whole pool and not from any single element of the pool. Think of the pool as an infinitely large statistical multiplexor.

• Pool Availablity Since the pool does not consist of one system but rather all the members of the pool then the pool is 'continuously available'. Systems may be removed from the pool (e.g. for routine maintenance functions) or added to the pool with no effect on overall pool availablity.

HotPools have inherent 'continuous availability' characteristics making them ideally suited to to-days highly demanding network environment.

Quality of Service

HotPools provides 'fine-grained' control over Quality of Service. The following defines the functionality provided:

• Prioritisation Levels Three user defined levels of priority exist - high medium and low. Any traffic not defined to be 'high' or 'medium' is defaulted to 'low' priority. System functions (e.g. keep-alive checks) run at a 'super' priority level and will take precedence over all other traffic. Typically these functions consume less than 1% of bandwidth.

• Priority Allocation Priority levels may be defined by any combination of traffic type (TCP, UDP, ICMP etc), IP source or destination, port number or port number range for either the source or the destination address.

• Priority Inheritance Certain applications spawn secondary ports which are essentially a random number thus making classic port based priority allocation ineffective. HotPools will recognise applications that use 'secondary' ports by their 'primary' or 'control' port numbers (currently FTP, H.323 and SIP) and automatically inspect traffic to detect secondary ports being opened. These new 'secondary' ports will inherit the same priority level as the 'control' ports e.g. if the user configures port 21 (the FTP 'control' port) in any destination or source port or range then FTP secondary ports will be allocated the same priority as defined for port 21.

• Priority Servicing Traffic for each priority level is maintained in a separate queue. The relative frequency (the queue service ratio) with which these queues are serviced may be defined by the user. This mechanism provides infinitely variable control and can be used to, say, starve 'low' priority traffic in overload situations or to continue to give it some proportion of bandwidth.

• Priority Discard The priority mechanism is also used in cases where packets need to be discarded due to overload conditions. Data is always discarded from the lowest priority queue first. The user may configure the discard algorithm as FIFO (First in First Out) or LIFO (Last in First Out). The system defaults to FIFO discarding.

• Queue Depth The number of items that may be queued before discarding takes place may be controlled by user configuration. This figure essentially defines the maximum packet delay that can exist. This feature is especially important where a lot of delay sensitive traffic is being handled on a very busy network. It is extremely inefficient network design to queue and tramsit data that will be discarded at the receiver due to excessive packet delays.

Discarding of packets always sounds like a catastrophic situation. IT IS NOT. First, in a heavily (efficiently) used network it is inevitable that there will be peaks of data which will exceed the capability of the network. Historic routing systems were built with huge buffers to handle these peaks. This lead to gross network inefficiencies with even relatively minor peaks taking many hours to clear (we have all witnessed the time it can take to clear congested roads after a traffic problem). Modern network design concentrates rather on discarding selectively as quickly as possible to keep over-all queue sizes as low as possible. Second, certain protocols such as TCP adapt very quicky when data is discarded and slow the overall transmissin rate in a linear fashion thus rapidly easing bottle-neck problems. Third, networks are increasingly handling delay-sensitive traffic (such as VoIP). A delayed packet which will have consumed network resources (aggravating the bottle-neck problem) will perhaps to be discared as soon as it arrives. It is infinitely more efficient to discard the packet locally when its useful life is over.

HotPools incorporates 'state of the art' network design and concentrates on giving the user and network operator very precise and 'fine-grained' control over the discard process in over-load situations.