S 5.162 Planning the bandwidth when using terminal servers

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

In a classic client/server network, the network load between the client and the server is subject to strong punctual fluctuations, for example while a file is transmitted. However,when the client application does not currently require any information, no bandwidth is required either.

In a terminal server environment, on the other hand, data must often also be transmitted over the network even if only minor changes to the user view arise. Therefore, the flow of data can be controlled more easily overall. On the one hand, input and output data can be compressed efficiently and limited by bandwidth management; on the other hand, only a single flow of data is created between the terminal and the terminal server for each user per session. Connections to file, database, or email services may then the established from the terminal server, for example. The files themselves do not leave the terminal server at any time, but are only displayed on the client.

The required bandwidths for the different implementations of the terminal server concept vary greatly. Sessions using RDP must be estimated with an average of 250kbit/s, Citrix recommends 160kbit/s for the ICA protocol used, X11 even uses approx. 4 to 5Mbit/s in the absence of additional safeguards. Therefore, a typical 100Mbit network is already fully stretched by 15 active X-Window terminals, since 30% of additional demand must be taken into account for the underlying TCP/IP protocol. However, using compression and buffer mechanisms with proxy systems, e.g. NX or FreeNX, the data volume can be reduced efficiently to an average of 40 kbit/s.

The values mentioned here must only be considered rough reference values for the planning stages. In practice, it is therefore absolutely required to analyse the specific application situation. Applications requiring large parts of the screen content to be updated quickly naturally put more strain on the network than applications where individual characters in user dialogues change only occasionally. Graphically complex user interfaces reduce the number of users that can be serviced using a given line capacity, as the behaviour of the users themselves has decisive effects on the load profile of the network.

If no exact empirical values are present for the planned scenario in advance, realistic tests of the specific configuration should therefore be conducted for larger installations so that substantiated statements regarding the data volumes to be expected and the required network resources can be made. This may either be performed in field tests with real user groups or by synthetic tests with the help of script-controlled access simulations. In both cases, the response times that must not be exceeded must be specified before evaluation.

Furthermore, reserves should be created so that higher requirements in the future can be compensated to a certain extent, e.g. caused by an expansion of the number of users or application updates.

If it is determined that the existing line capacities to the individual terminals are insufficiently dimensioned within the framework of the requirements determination because they compete with other services provided in the network, the use of bandwidth management provides the option of eliminating bottlenecks by prioritising the data traffic. Additionally, terminal servers are particularly suitable for providing the user with quick storage networks at the workplace with relatively low effort. This way, downstream services can be connected with the help of a secondary network, e.g. one with particularly powerful technologies such as iSCSI or fibre channel, directly to the terminal server, sustainably relieving the network between the terminal and the terminal server.

Particularly when providing terminal server services using WAN routes (wide area network), the latency of a connection is of significant importance in addition to the bandwidth. Since the screen output of the applications is performed almost synchronously with the processing on the terminal server, short packet runtimes to the remote system are decisive for working without any delays. A higher data volume due to additional protocol layers, e.g. from encrypted remote accesses in VPN systems, must be taken into consideration, as well as error correction mechanisms of the line providers that may have additional adverse effects on the signal runtimes.

Review questions:

© Federal Office for Information Security. All rights reserved.