Internet DRAFT - draft-waters-reduce-isdn-costs

draft-waters-reduce-isdn-costs



HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 12:07:04 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 31 Jul 1996 22:14:00 GMT
ETag: "3ddd42-54a3-31ffdaa8"
Accept-Ranges: bytes
Content-Length: 21667
Connection: close
Content-Type: text/plain


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.
                <draft-waters-reduce-isdn-costs-00.txt>

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]