Internet Engineering Task Force S.Waters INTERNET-DRAFT Digital Equipment Co. Ltd. July 1996 Reducing the ISDN costs of Network Applications that use TCP/IP. Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This document discusses TCP/IP traffic on ISDN links and makes recommendations to Network Application and Router developers with a view to reducing the cost of using ISDN. This topic is partly related to current activity in the PPP Working Group on controls for Protocol Spoofing, but mainly targets the developers of Network software such as Resource Sharing protocols, for example Network Service and Directory Sharing. Expires January 1996 [Page 1] DRAFT Reducing the ISDN costs of TCP/IP Applications July 1996 1. Introduction ISDN is growing rapidly as a way of connecting remote LANs and remote workstations, typically connecting small offices to larger ones. For ISDN connections that incur 'use-based' tariffs, as opposed to fixed-rate, connection time is money. Since ISDN provides for rapid call establishment, it is possible to disconnect an ISDN connection during a period of no data activity (idle time) and re-connect when data is presented for forwarding - this is sometimes called Time- Cutting. Moreover, it may be that ISDN only competes with other services on cost if the profile of the data on the ISDN link permits effective use of Time-Cutting. With TCP being a common choice for Remote Access and Lan-connect over ISDN, consideration should be given to the possibility of ISDN connection cost reduction while using TCP connections. An optional extension to TCP (TCP Keepalive messages) and the current nature of common NetBios and Resource Sharing packages can greatly reduce the opportunity to Time-Cut an ISDN connection. This document suggests short-term measures to reduce 'noise' over TCP connections, and long-term measures that could be adopted by network software and router developers to increase sensitivity to the requirements of ISDN connections. Some suggestions are also made for general working practices that may help increase connection idle time. The recommendations in this document are most relevant to networks that use ISDN as primary links, e.g. a Small Office/Home Office where the opportunities for idle time are greatest. 2. General Overview To help the discussion, the following network links will be referenced: Server--LAN1--Router1---ISDN---Router2--LAN2--Client The definition of 'noise' for the purposes of this document is : "Any IP datagram sent as part of a TCP connection that is additional to the basic needs of the TCP protocol and the protocols that are direct or indirect clients of TCP." Expires January 1996 [Page 2] DRAFT Reducing the ISDN costs of TCP/IP Applications July 1996 The following types of noise are discussed : 1. Keepalive Messages, e.g. TCP Keepalives and Netbios Keepalives. 2. Resource sharing background activity, e.g. Resource Browsing. 3. Data resulting from bad working practices. These noise sources can be dealt with by using one of the following options : 1. Protocol Spoofing by the local router. 2. Tuning server/client systems. 3. Fixing server/client application defaults at source. 4. Changing working practices. For each noise source, each of the solutions listed above will be considered and a recommendations made. Since the functions available in routers and servers/clients are different for each network, there is no single answer to a given situation and the fix may involve a combination of approaches. This document does not cover making the best use of ISDN tariff structures (e.g. time-of-day tariff variances) or making the best use of available bandwidth (e.g. compression), but rather how to reduce the number of connections made. Apart from the benefit of increased bandwidth availability, this discussion is not relevant to ISDN con- nections that have a fixed-rate ISDN tariffs (as opposed to use- based) since there is no saving to be made from Time-Cutting. 3. Problems with Spoofing TCP This section discusses problems with spoofing TCP-Client data, i.e, data generated by the client of the TCP connection, and then makes a recommendation. Expires January 1996 [Page 3] DRAFT Reducing the ISDN costs of TCP/IP Applications July 1996 The word 'Spoofing', in this context, is where a router responds to a message on behalf of the client or server at the remote site (e.g. Router1 generates a reply to a message sent by Server intended for Client). At first, Spoofing seems to offer the best way for ISDN routers to reduce TCP traffic over ISDN links, but there are a number of prob- lems with this approach that limit the usefulness of Spoofing. TCP defines a TCP Header that is prefixed to the TCP-Client data and is used to provide a reliable transport service to TCP Clients. The TCP Header contains two fields of interest to this discussion: Sequence Number (SEQN), and Acknowledgment Number (ACKN). When a TCP connection is first initiated, the TCP peers (Server and Client in this example) agree an Initial Sequence Number (ISN) for the SEQN field at both ends of the connection, and from that point, SEQN is incremented by one for each octet of TCP-Client data sent. The ACKN field is set to the next SEQN expected from the TCP peer which ack- nowledges receipt of all data to that point in the exchange. TCP Keepalive messages can be exchanged between TCP peers to ensure that the connection is still active. These messages do not cause SEQN and ACKN to be incremented since they do not contain any actual data. All TCP-Client data (including Netbios Keepalives) will affect the values of SEQN and ACKN. For Router1 and Router2 to spoof TCP-Client messages (e.g. Netbios messages) received on the LAN1/LAN2 ports, each router needs to gen- erate messages onto the LAN ports and this will cause the SEQN and ACKN values of TCP messages on each LAN to drift apart since each router will spoof a different number of TCP-Client messages. For Spoofing to be useful, it needs to be applicable to complex net- works and allow TCP connections to survive router failures and reloads. The following problems make TCP-Client spoofing (as described above) problematic: 1. Alternative links. If there is more than one link possible between the remote LANs (e.g. a back-up link or a new, cheaper route), TCP packets may be received via a link that is not spoofing TCP data and the SEQN/ACKN values in those datagrams will not match those expected by the peer. This will cause data loss, data corrup- tion or TCP connection failure. Expires January 1996 [Page 4] DRAFT Reducing the ISDN costs of TCP/IP Applications July 1996 2. Re-load of Router running spoofing. Since it may not be possible to store the information concerning spoofed TCP connections from one re-boot to another (i.e. SEQN/ACKN for all virtual TCP links), the only option for a spoofing router on recovery from failure is to block all TCP data on connections for which the Connection Establishment was not seen (i.e. block active TCP-connection data). This approach would mean that TCP connections would not survive router failures. 3. Processing Power. Routers that spoof TCP-Client messages will need to generate TCP headers for each datagram forwarded (onto the LAN or the ISDN link) and the 16bit Checksum in the header would need to be re- calculated for each datagram since the checksum includes the value of the SEQN/ACKN fields. For the above reasons, it is the recommendation of this document that TCP Spoofing is restricted to the Spoofing of TCP Keepalive messages which is possible without incurring the penalties listed. 4. Options for the containment of TCP and TCP-Client Keepalive Message. For TCP connections, there are two types of Keepalive message : 1. TCP Keepalive messages - which do not cause the TCP-header fields Sequence-Number and Acknowledge-Number to increment. 2. TCP-Client Keepalive messages, e.g. Netbios Keepalive messages - which do cause TCP Sequence and Acknowledgement number incre- ments. 4.1. Spoofing TCP Keepalive messages. If a TCP-Client (e.g. Netbios) requires a Keepalive mechanism, the recommendation is that the TCP-Client avoids sending its own polls, and relies instead on TCP Keepalive message to verify connections. This recommendation is in agreement with [1] which has the following text: Expires January 1996 [Page 5] DRAFT Reducing the ISDN costs of TCP/IP Applications July 1996 "Since many TCP implementations provide a parallel TCP "keep-alive" mechanism, the NetBIOS session keep-alive is made a configurable option. It is recommended that the NetBIOS keep-alive mechanism be used only in the absence of TCP keep-alive." This recommendation applies to all TCP-Client software that requires a 'health-check' exchange with the peer entity, and implies that all TCP/IP packages should support TCP Keepalive messages. The mechanisms for co-ordinating TCP Keepalive spoofing are not dis- cussed in this document. 4.2. Tuning TCP and TCP-Client Keepalive messages. It is likely that TCP Keepalive and TCP-Client Keepalive messages will be tuneable on most Network Software packages. The problem with this approach is that all systems that are connected with TCP may need to be tuned, which is labour-intensive and may affect support agreements. Another problem is that multiple TCP sessions will gen- erate Keepalive messages in an uncoordinated way such that even with long timers, frequent calls over an ISDN link may be necessary. If the TCP-Client software does not need a health-check to function correctly, it should be tuned to eliminate the messages. 4.3. Fixing the Keepalive messages problem. TCP Keepalive messages are not part of the base TCP specification [2], but are part of TCP-Client specifications (e.g. [1]). If TCP- Client Keepalives are abandoned, it may cause server resource prob- lems, e.g. Netbios session that have ended abruptly still accounting for TCP and TCP-Client resource allocation in the server. One option may be for the servers to adopt an Inactivity policy where sessions that have been inactive for a specified time are silently abandoned (TCP connection resources deallocated) or actively discon- nected (TCP disconnection procedures invoked). If a particular TCP Client does not need Keepalive messages to function correctly, the default setting for all Keepalive options should be 'Disabled'. For TCP Client applications that do need a keepalive mechanism, TCP Keepalives should be used. 4.4. Changes to Working Practices that affect TCP and TCP-Client Keepalives Since TCP connections can cause noise, care should be taken to cleanly disconnect connections that are no longer in use, say, at the end of the working day. If the ISDN router is powered-off as well Expires January 1996 [Page 6] DRAFT Reducing the ISDN costs of TCP/IP Applications July 1996 (once TCP connections have been disconnected to free server resources), then no ISDN charges can be incurred. An alternative to powering-off the router could be 'Call Blocking' by Time-Of-Week, e.g. configuring routers to block calls during 'out-of-hours' periods. Of course, call-blocking and power-off options are applicable to any noise problem. 4.5. Summary of Recommendations for Keepalive containment. Since all systems in the network may not offer the same degree of manageability and function, it may be necessary to apply more than one of these recommendations : 1. If 'health checks' are required by TCP-Clients, TCP Keepalive polls should be used and should be the default arrangement, as recommended in [1]). For ISDN routers that do not support TCP Keepalive Spoofing, tuning of the TCP timer controls on all systems, or installing ISDN-friendly TCP Client packages may be necessary. Developers of TCP-Client software packages that require 'health checks' should follow the recommendation stated in [1] when possible, i.e. use TCP Keepalive messages in preference to TCP-Client Keepalives. For the consumers of TCP-Client applica- tions, this would avoid the need for labour-intensive tuning and the risk of affecting support agreements. 2. If 'health checks' are not required, they should be disabled (both TCP and TCP-Client versions) and silent or active discon- nection of inactive session should be considered to help main- tain server resources. TCP and TCP-Client software packages that use 'health checks' as a default optional-extra should consider changing the default setting to 'Disabled' (as recommended in [3]). 3. Unused TCP connections should be disconnected and, if possible, the ISDN router should be powered-off or a call-blocking facil- ity should be activated while the ISDN router is not in use. Expires January 1996 [Page 7] DRAFT Reducing the ISDN costs of TCP/IP Applications July 1996 5. Options for the containment of Resource Query Messages. Resource Sharing software (such as SMB File Sharing Protocol) is used to access file systems and services (such as printers) and can cause a large amount of WAN traffic if the services are accessed remotely - e.g. over ISDN links. User-invoked Browsing of network resources is a requirement of Resource Sharing applications, but Background, or Proactive browsing (e.g. regular resource queries not directly requested by the user) should be considered as an optional extra since it may result in very high ISDN connection charges. Wherever possible, Background Browsing should be avoided or disabled by default. Since user-invoked browsing is not the issue, the following sub- sections are concerned with controlling Background Browsing activity. 5.1. Spoofing Background Resource Query messages. As has been stated already in this document, spoofing of TCP-Client data is not recommended (see section 3). 5.2. Tuning Background Resource Querries Like TCP Keepalive messages, Background Resource Sharing may be tune- able with most software, but tuning is labour-intensive and may affect the support agreements. 5.3. Fixing the Background Resource Query message problem. Resource Sharing software developers should consider the option of making Browsing 'reactive' and not 'proactive', i.e. by default, server/client systems will not do background browsing, but will browse network resources when a refresh is requested by the user. To provide continued support for background browsing on a shared LAN, reactive browsing could be provided as the default for routed resource connections, e.g. TCP/IP. As an example, Printer Sharing software may default to sending fre- quent resource query messages to the remotely accessed printers to obtain the current information on queued print jobs and general printer status. As an alternative to this, the default action for routed connections (e.g. TCP connections) should be to only refresh the remote printer information when the user directly requests the current information or queues a print job to one of the remote printers. Expires January 1996 [Page 8] DRAFT Reducing the ISDN costs of TCP/IP Applications July 1996 5.4. Changes to working Practices that affect Background Resource Query messages Disconnecting from network resources that are used infrequently will save ISDN connections from being made to retrieve information that will most probably not be used. Some Server/Client packages may offer a poor-man's way of connect- ing to network resources that avoids using background browsing. This would remove the need to disconnect from infrequently used resources. 5.5. Summary of Recommendations for Background Resource Query message containment. If possible, install TCP-Client software that uses reactive browsing to support remote resource sharing. Resource Sharing application developers should, wherever possible, support reactive browsing as the default for routable data. For applications that use proactive browsing by default, tuning may allow the feature to be disabled or the frequency of messages may be reduced. Disconnecting from resources and logging-off server-client sessions will cause the underlying TCP connection to be disconnected. And, as with all ISDN links, turning off the router or using call-blocking is a useful option for offices with well defined working hours. 6. General options for changes to Working Practices This section lists a number of Working Practices that could be adopted to reduce ISDN connection time. 1. Editing. Remote Editing works very well over an ISDN link, but should be avoided since each change or scroll will cause network data. Whenever possible, copy files to be edited to the local system and return them once the required changes have been made. 2. Mail. For users with active mail accounts, receiving real-time notifi- cation of mail arrivals may cause a large number of ISDN Expires January 1996 [Page 9] DRAFT Reducing the ISDN costs of TCP/IP Applications July 1996 connections to be made. Some Mail server products allow a user to connect to a mail server to check for new mail and then to copy the mail onto the local system for off-line processing, i.e. making replies or generating new mail en masse. 3. Time Servers. Time Server protocols, e.g. Network Time Protocol, may cause significant traffic. For provision of Time services at a remote site, it would be better to use a local server. If it is required that Time be retrieved from a central/head-office site, only one of the systems at the remote site should make the query and then act as local Time Server on the remote LAN. To avoid Time Servers causing connections out-of-hours, use call- blocking, batch scripts to disable the Time Clients, or power- off the router. 4. Web Browsing. - such as Netscape. Each system should make use of Memory and Disk Cache if appropriate and perhaps user-request based refresh. 5. Telnet Sessions. Once logged-on to a remote system, avoid 'broadcast' or 'system manager' messages if possible and make use of batch jobs and log files to reduce terminal activity. If Spoofing of TCP Keepalive is not supported by the ISDN routers, use a telnet package that does not request Keepalive from TCP or allows tun- ing of the Keepalive timers. 6. ISDN Routers. Some ISDN routers support controls over ISDN connections, e.g. Call-Blocking. These controls should be used where possible to control the when/where-to/where-from/how-long nature of connec- tions. Powering-off remote access routers when not in use or connecting to a timed power supply ensures ISDN calls will not be made out-of-hours. Expires January 1996 [Page 10] DRAFT Reducing the ISDN costs of TCP/IP Applications July 1996 Stephen Waters Digital Equipment Co. Ltd. Digital Park Imperial Way Reading Berkshire RG2 0TE UK Tel: +44 1548 831170 Fax: +44 1548 831170 Email: waters@marvin.reo.dec.com 7. References [1] "Protocol standard for a NetBIOS service on a TCP/UDP tran- sport: Concepts and methods'', RFC 1001 [2] "Transmission Control Protocol'' , RFC 793, J. Postel, Sep- tember 1981 [3] "Requirements for Internet hosts - communication layers'', RFC 1122, R. Braden, October 1989 8. Acknowledgements Thanks to Chris Chapman and Mike Shand who took the time to review this draft. (End of Draft) Expires January 1996 [Page 11]