home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_s_z / draft-waters-reduce-isdn-costs-01.txt < prev    next >
Text File  |  1996-08-02  |  22KB  |  615 lines
  1.  
  2. Internet Engineering Task Force                                S.Waters
  3. INTERNET-DRAFT                               Digital Equipment Co. Ltd.
  4. July 1996
  5.  
  6.  
  7.    Reducing the ISDN costs of Network Applications that use TCP/IP.
  8.                 <draft-waters-reduce-isdn-costs-01.txt>
  9.  
  10. Status of this Memo
  11.  
  12.    This memo provides information for the Internet community. This memo
  13.    does not specify an Internet standard of any kind.
  14.  
  15.    Distribution of this memo is unlimited.
  16.  
  17. Abstract
  18.  
  19.    This document discusses TCP/IP traffic on ISDN links and makes
  20.    recommendations to Network Application and Router developers with a
  21.    view to reducing the cost of using ISDN.
  22.  
  23.    This topic is partly related to current activity in the PPP Working
  24.    Group on controls for Protocol Spoofing, but mainly targets the
  25.    developers of Network software such as Resource Sharing protocols,
  26.    for example Network Service and Directory Sharing.
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53. Expires January 1996                                            [Page 1]
  54.  
  55. DRAFT        Reducing the ISDN costs of TCP/IP Applications    July 1996
  56.  
  57.  
  58. 1. Introduction
  59.  
  60.    ISDN is growing rapidly as a way of connecting remote LANs and remote
  61.    workstations, typically connecting small offices to larger ones.
  62.  
  63.    For ISDN connections that incur 'use-based' tariffs, as opposed to
  64.    fixed-rate, connection time is money.  Since ISDN provides for rapid
  65.    call establishment, it is possible to disconnect an ISDN connection
  66.    during a period of no data activity (idle time) and re-connect when
  67.    data is presented for forwarding - this is sometimes called Time-
  68.    Cutting.  Moreover, it may be that ISDN only competes with other
  69.    services on cost if the profile of the data on the ISDN link permits
  70.    effective use of Time-Cutting.
  71.  
  72.    With TCP being a common choice for Remote Access and Lan-connect over
  73.    ISDN, consideration should be given to the possibility of ISDN
  74.    connection cost reduction while using TCP connections.
  75.  
  76.    An optional extension to TCP (TCP Keepalive messages) and the current
  77.    nature of common NetBios and Resource Sharing packages can greatly
  78.    reduce the opportunity to Time-Cut an ISDN connection. This document
  79.    suggests short-term measures to reduce 'noise' over TCP connections,
  80.    and long-term measures that could be adopted by network software and
  81.    router developers to increase sensitivity to the requirements of ISDN
  82.    connections. Some suggestions are also made for general working
  83.    practices that may help increase connection idle time.
  84.  
  85.    The recommendations in this document are most relevant to networks
  86.    that use ISDN as primary links, e.g. a  Small Office/Home Office
  87.    where the opportunities for idle time are greatest.
  88.  
  89.  
  90. 2. General Overview
  91.  
  92.    To help the discussion, the following network links will be
  93.    referenced:
  94.  
  95.    Server--LAN1--Router1---ISDN---Router2--LAN2--Client
  96.  
  97.  
  98.  
  99.    The definition of 'noise' for the purposes of this  document is :
  100.  
  101.    "Any IP datagram sent as part of a TCP connection that is additional
  102.    to the basic needs of the TCP protocol and the protocols that are
  103.    direct or indirect clients of TCP."
  104.  
  105.  
  106.  
  107.  
  108.  
  109. Expires January 1996                                            [Page 2]
  110.  
  111. DRAFT        Reducing the ISDN costs of TCP/IP Applications    July 1996
  112.  
  113.  
  114.    The following types of noise are discussed :
  115.  
  116.  
  117.    1.    Keepalive Messages, e.g. TCP Keepalives and Netbios Keepalives.
  118.  
  119.  
  120.    2.    Resource sharing background activity, e.g. Resource Browsing.
  121.  
  122.  
  123.    3.    Data resulting from bad working practices.
  124.  
  125.  
  126.  
  127.    These noise sources can be dealt with by using one of the following
  128.    options :
  129.  
  130.  
  131.    1.    Protocol Spoofing by the local router.
  132.  
  133.  
  134.    2.    Tuning server/client systems.
  135.  
  136.  
  137.    3.    Fixing server/client application defaults at source.
  138.  
  139.  
  140.    4.    Changing working practices.
  141.  
  142.  
  143.    For each noise source, each of the solutions listed above will be
  144.    considered and a recommendations made.  Since the functions available
  145.    in routers and servers/clients are different for each network, there
  146.    is no single answer to a given situation and the fix may involve a
  147.    combination of approaches.
  148.  
  149.    This document does not cover making the best use of ISDN tariff
  150.    structures (e.g. time-of-day tariff variances) or making the best use
  151.    of available bandwidth (e.g. compression), but rather how to reduce
  152.    the number of connections made.  Apart from the benefit of increased
  153.    bandwidth availability, this discussion is not relevant to ISDN con-
  154.    nections that have a fixed-rate ISDN tariffs (as opposed to use-
  155.    based) since there is no saving to be made from Time-Cutting.
  156.  
  157. 3. Problems with Spoofing TCP
  158.  
  159.    This section discusses problems with spoofing TCP-Client data, i.e,
  160.    data generated by the client of the TCP connection,  and then makes a
  161.    recommendation.
  162.  
  163.  
  164.  
  165. Expires January 1996                                            [Page 3]
  166.  
  167. DRAFT        Reducing the ISDN costs of TCP/IP Applications    July 1996
  168.  
  169.  
  170.    The word 'Spoofing', in this context, is where a router responds to a
  171.    message on behalf of the client or server at the remote site (e.g.
  172.    Router1 generates a reply to a message sent by Server intended for
  173.    Client).
  174.  
  175.    At first, Spoofing seems to offer the best way for ISDN routers to
  176.    reduce TCP traffic over ISDN links, but there are a number of prob-
  177.    lems with this approach that limit the usefulness of Spoofing.
  178.  
  179.    TCP defines a TCP Header that is prefixed to the TCP-Client data and
  180.    is used to provide a reliable transport service to TCP Clients.  The
  181.    TCP Header contains two fields of interest to this discussion:
  182.    Sequence Number (SEQN), and Acknowledgment Number (ACKN).  When a TCP
  183.    connection is first initiated, the TCP peers (Server and Client in
  184.    this example) agree an Initial Sequence Number (ISN) for the SEQN
  185.    field at both ends of the connection, and from that point, SEQN is
  186.    incremented by one for each octet of TCP-Client data sent.   The ACKN
  187.    field is set to the next SEQN expected from the TCP peer which ack-
  188.    nowledges receipt of all data to that point in the exchange.
  189.  
  190.    TCP Keepalive messages can be exchanged between TCP peers to ensure
  191.    that the connection is still active.  These messages do not cause
  192.    SEQN and ACKN to be incremented since they do not contain any actual
  193.    data. All TCP-Client data (including Netbios Keepalives)  will affect
  194.    the values of SEQN and ACKN.
  195.  
  196.    For Router1 and Router2 to spoof TCP-Client messages (e.g. Netbios
  197.    messages) received on the LAN1/LAN2 ports, each router needs to gen-
  198.    erate messages onto the LAN ports and this will cause the SEQN and
  199.    ACKN values of TCP messages on each LAN to drift apart since each
  200.    router will spoof a different number of TCP-Client messages.
  201.  
  202.    For Spoofing to be useful, it needs to be applicable to complex net-
  203.    works and allow TCP connections to survive router failures and
  204.    reloads.  The following problems make TCP-Client spoofing (as
  205.    described above) problematic:
  206.  
  207.  
  208.    1.   Alternative links.
  209.  
  210.         If there is more than one link possible between the remote LANs
  211.         (e.g. a back-up link or a new, cheaper route), TCP packets may
  212.         be received via a link that is not spoofing TCP data and the
  213.         SEQN/ACKN values in those datagrams will not match those
  214.         expected by the peer.  This will cause data loss,  data corrup-
  215.         tion or TCP connection failure.
  216.  
  217.  
  218.  
  219.  
  220.  
  221. Expires January 1996                                            [Page 4]
  222.  
  223. DRAFT        Reducing the ISDN costs of TCP/IP Applications    July 1996
  224.  
  225.  
  226.    2.   Re-load of Router running spoofing.
  227.  
  228.         Since it may not be possible to store the information concerning
  229.         spoofed TCP connections from one re-boot to another (i.e.
  230.         SEQN/ACKN for all virtual TCP links),  the only option for a
  231.         spoofing router on recovery from failure is to block all TCP
  232.         data on connections for which the Connection Establishment was
  233.         not seen (i.e. block active TCP-connection data).  This approach
  234.         would mean that TCP connections would not survive router
  235.         failures.
  236.  
  237.  
  238.    3.   Processing Power.
  239.  
  240.         Routers that spoof TCP-Client messages will need to generate TCP
  241.         headers for each datagram forwarded (onto the LAN or the ISDN
  242.         link) and the 16bit Checksum in the header would need to be re-
  243.         calculated for each datagram since the checksum includes the
  244.         value of the SEQN/ACKN fields.
  245.  
  246.  
  247.    For the above reasons, it is the recommendation of this document that
  248.    TCP Spoofing is restricted to the Spoofing of TCP Keepalive messages
  249.    which is possible without incurring the penalties listed.
  250.  
  251.  
  252.  
  253. 4. Options for the containment of  TCP and TCP-Client Keepalive Message.
  254.  
  255.    For TCP connections, there are two types of Keepalive message :
  256.  
  257.  
  258.    1.   TCP Keepalive messages - which do not cause the TCP-header
  259.         fields Sequence-Number and Acknowledge-Number to increment.
  260.  
  261.  
  262.    2.   TCP-Client Keepalive messages, e.g. Netbios Keepalive messages -
  263.         which do cause TCP Sequence and Acknowledgement number incre-
  264.         ments.
  265.  
  266.  
  267. 4.1. Spoofing TCP Keepalive messages.
  268.  
  269.    If a TCP-Client (e.g. Netbios) requires a Keepalive mechanism, the
  270.    recommendation is that the TCP-Client avoids sending its own polls,
  271.    and relies instead on TCP Keepalive message to verify connections.
  272.    This recommendation is in agreement with [1] which has the following
  273.    text:
  274.  
  275.  
  276.  
  277. Expires January 1996                                            [Page 5]
  278.  
  279. DRAFT        Reducing the ISDN costs of TCP/IP Applications    July 1996
  280.  
  281.  
  282.    "Since many TCP implementations provide a parallel TCP "keep-alive"
  283.    mechanism, the NetBIOS session keep-alive is made a configurable
  284.    option.  It is recommended that the NetBIOS keep-alive mechanism be
  285.    used only in the absence of TCP keep-alive."
  286.  
  287.    This recommendation applies to all TCP-Client software that requires
  288.    a 'health-check' exchange with the peer entity, and implies that all
  289.    TCP/IP packages should support TCP Keepalive messages.
  290.  
  291.    The mechanisms for co-ordinating TCP Keepalive spoofing are not dis-
  292.    cussed in this document.
  293.  
  294. 4.2. Tuning TCP and TCP-Client Keepalive messages.
  295.  
  296.    It is likely that TCP Keepalive and TCP-Client Keepalive messages
  297.    will be tuneable on most Network Software packages.  The problem with
  298.    this approach is that all systems that are connected with TCP may
  299.    need to be tuned, which is labour-intensive and may affect support
  300.    agreements.  Another problem is that multiple TCP sessions will gen-
  301.    erate Keepalive messages in an uncoordinated way such that even with
  302.    long timers, frequent calls over an ISDN link may be necessary.
  303.  
  304.    If the TCP-Client software does not need a health-check to function
  305.    correctly,  it should be tuned to eliminate the messages.
  306.  
  307. 4.3. Fixing the Keepalive messages problem.
  308.  
  309.    TCP Keepalive messages are not part of the base TCP specification
  310.    [2], but are part of TCP-Client specifications (e.g. [1]).  If TCP-
  311.    Client Keepalives are abandoned, it may cause server resource prob-
  312.    lems, e.g. Netbios session that have ended abruptly still accounting
  313.    for TCP and TCP-Client resource allocation in the server.
  314.  
  315.    One option may be for the servers to adopt an Inactivity policy where
  316.    sessions that have been inactive for a specified time are silently
  317.    abandoned (TCP connection resources deallocated) or actively discon-
  318.    nected (TCP disconnection procedures invoked).  If a particular TCP
  319.    Client does not need Keepalive messages to function correctly, the
  320.    default setting for all Keepalive options should be 'Disabled'. For
  321.    TCP Client applications that do need a keepalive mechanism, TCP
  322.    Keepalives should be used.
  323.  
  324. 4.4. Changes to Working Practices that affect TCP and TCP-Client
  325.    Keepalives
  326.  
  327.    Since TCP connections can cause noise, care should be taken to
  328.    cleanly disconnect connections that are no longer in use, say, at the
  329.    end of the working day. If the ISDN router is powered-off as well
  330.  
  331.  
  332.  
  333. Expires January 1996                                            [Page 6]
  334.  
  335. DRAFT        Reducing the ISDN costs of TCP/IP Applications    July 1996
  336.  
  337.  
  338.    (once TCP connections have been disconnected to free server
  339.    resources), then no ISDN charges can be incurred.
  340.  
  341.    An alternative to powering-off  the router could be 'Call Blocking'
  342.    by Time-Of-Week, e.g. configuring routers to block calls during
  343.    'out-of-hours' periods.
  344.  
  345.    Of course, call-blocking and power-off options are applicable to any
  346.    noise problem.
  347.  
  348. 4.5. Summary of Recommendations for Keepalive containment.
  349.  
  350.    Since all systems in the network may not offer the same degree of
  351.    manageability and function, it may be necessary to apply more than
  352.    one of these recommendations :
  353.  
  354.  
  355.    1.   If 'health checks' are required by TCP-Clients, TCP Keepalive
  356.         polls should be used and should  be the default arrangement, as
  357.         recommended in [1]). For ISDN routers that do not support TCP
  358.         Keepalive Spoofing,  tuning of the TCP timer controls on all
  359.         systems, or installing ISDN-friendly TCP Client packages may be
  360.         necessary.
  361.  
  362.         Developers of TCP-Client software packages that require 'health
  363.         checks'  should follow the recommendation stated in [1] when
  364.         possible,  i.e. use TCP Keepalive messages in preference to
  365.         TCP-Client Keepalives.  For the consumers of TCP-Client applica-
  366.         tions, this would avoid the need for labour-intensive tuning and
  367.         the risk of affecting support agreements.
  368.  
  369.  
  370.  
  371.    2.   If 'health checks' are not required, they should be disabled
  372.         (both TCP and TCP-Client versions) and silent or active discon-
  373.         nection of inactive session should be considered  to help main-
  374.         tain server resources.
  375.  
  376.         TCP and TCP-Client software packages that use 'health checks' as
  377.         a default optional-extra should consider changing the default
  378.         setting to 'Disabled' (as recommended in [3]).
  379.  
  380.  
  381.    3.   Unused TCP connections should be disconnected and, if possible,
  382.         the ISDN router should be powered-off or a call-blocking facil-
  383.         ity should be activated while the ISDN router is not in use.
  384.  
  385.  
  386.  
  387.  
  388.  
  389. Expires January 1996                                            [Page 7]
  390.  
  391. DRAFT        Reducing the ISDN costs of TCP/IP Applications    July 1996
  392.  
  393.  
  394. 5. Options for the containment of Resource Query Messages.
  395.  
  396.    Resource Sharing software (such as SMB File Sharing Protocol) is
  397.    used to access file systems and services (such as printers) and can
  398.    cause a large amount of WAN traffic if the services are accessed
  399.    remotely - e.g. over ISDN links.
  400.  
  401.    User-invoked Browsing of network resources is a requirement of
  402.    Resource Sharing applications, but Background, or Proactive browsing
  403.    (e.g. regular resource queries not directly requested by the user)
  404.    should be considered as an optional extra since it may result in very
  405.    high ISDN connection charges. Wherever possible, Background Browsing
  406.    should be avoided or disabled by default.
  407.  
  408.    Since user-invoked browsing is not the issue, the following sub-
  409.    sections are concerned with controlling Background Browsing activity.
  410.  
  411. 5.1. Spoofing Background Resource Query messages.
  412.  
  413.    As has been stated already in this document, spoofing of TCP-Client
  414.    data is not recommended (see section 3).
  415.  
  416. 5.2. Tuning  Background Resource Querries
  417.  
  418.    Like TCP Keepalive messages, Background Resource Sharing may be tune-
  419.    able with most software, but tuning is labour-intensive and may
  420.    affect the support agreements.
  421.  
  422. 5.3. Fixing the Background Resource Query message problem.
  423.  
  424.    Resource Sharing software developers should consider the option of
  425.    making Browsing 'reactive' and not 'proactive', i.e. by default,
  426.    server/client systems will not do background browsing, but will
  427.    browse network resources when a refresh is requested by the user.
  428.    To provide continued support for background browsing on a shared LAN,
  429.    reactive browsing could be provided as the default for routed
  430.    resource connections, e.g. TCP/IP.
  431.  
  432.    As an example,  Printer Sharing software may default to sending fre-
  433.    quent resource query messages to the remotely accessed printers to
  434.    obtain the current information on queued print jobs and general
  435.    printer status.  As an alternative to this, the default action for
  436.    routed connections (e.g. TCP connections) should be to only refresh
  437.    the remote printer information when the user directly requests the
  438.    current information or queues a print job to one of the remote
  439.    printers.
  440.  
  441.  
  442.  
  443.  
  444.  
  445. Expires January 1996                                            [Page 8]
  446.  
  447. DRAFT        Reducing the ISDN costs of TCP/IP Applications    July 1996
  448.  
  449.  
  450. 5.4. Changes to working Practices that affect Background Resource Query
  451.    messages
  452.  
  453.    Disconnecting  from network resources that are used  infrequently
  454.    will save ISDN connections from being made to retrieve information
  455.    that will most probably not be used.
  456.  
  457.    Some Server/Client packages may offer a  poor-man's  way of connect-
  458.    ing to network resources that avoids using  background browsing.
  459.    This would remove the need to disconnect from infrequently used
  460.    resources.
  461.  
  462. 5.5. Summary of Recommendations for Background Resource Query message
  463.    containment.
  464.  
  465.    If possible, install TCP-Client software that uses reactive browsing
  466.    to support remote resource sharing.  Resource Sharing application
  467.    developers should, wherever possible, support reactive browsing as
  468.    the default for routable data.
  469.  
  470.    For applications that use proactive browsing by default, tuning may
  471.    allow the feature to be disabled or the frequency of messages may be
  472.    reduced.
  473.  
  474.    Disconnecting from resources and logging-off server-client sessions
  475.    will cause the underlying TCP connection to be disconnected. And, as
  476.    with all ISDN links,  turning off the router or using call-blocking
  477.    is a useful option for offices with well defined working hours.
  478.  
  479.  
  480. 6. General options for changes to Working Practices
  481.  
  482.    This section lists a number of Working Practices that could be
  483.    adopted to reduce ISDN connection time.
  484.  
  485.  
  486.    1.   Editing.
  487.  
  488.         Remote Editing works very well over an ISDN link, but should be
  489.         avoided since each change or scroll will cause network data.
  490.         Whenever possible, copy files to be edited to the local system
  491.         and return them once the required changes have been made.
  492.  
  493.  
  494.    2.   Mail.
  495.  
  496.         For users with active mail accounts, receiving real-time notifi-
  497.         cation of mail arrivals may cause a large number of ISDN
  498.  
  499.  
  500.  
  501. Expires January 1996                                            [Page 9]
  502.  
  503. DRAFT        Reducing the ISDN costs of TCP/IP Applications    July 1996
  504.  
  505.  
  506.         connections to be made.   Some Mail server products allow a user
  507.         to connect to a mail server to check for new mail and then to
  508.         copy the mail onto the local system for off-line processing,
  509.         i.e. making replies or generating new mail en masse.
  510.  
  511.  
  512.    3.   Time Servers.
  513.  
  514.         Time Server protocols,  e.g. Network Time Protocol, may cause
  515.         significant traffic.  For provision of Time services at a remote
  516.         site, it would be better to use a local server.  If  it is
  517.         required that Time be retrieved from a central/head-office site,
  518.         only one of the systems at the remote site should make the query
  519.         and then act as local Time Server on the remote LAN.  To avoid
  520.         Time Servers causing connections out-of-hours,  use call-
  521.         blocking, batch scripts to disable the Time Clients, or power-
  522.         off the router.
  523.  
  524.  
  525.    4.   Web Browsing. - such as Netscape.
  526.  
  527.         Each system should make use of  Memory and Disk Cache if
  528.         appropriate and perhaps user-request based refresh.
  529.  
  530.  
  531.  
  532.    5.   Telnet Sessions.
  533.  
  534.         Once logged-on to a remote system, avoid 'broadcast' or 'system
  535.         manager' messages if possible and make use of  batch jobs and
  536.         log files to reduce terminal activity.  If  Spoofing of TCP
  537.         Keepalive is not supported by the ISDN routers,  use a telnet
  538.         package that does not request Keepalive from TCP or allows tun-
  539.         ing of  the Keepalive timers.
  540.  
  541.  
  542.    6.   ISDN Routers.
  543.  
  544.         Some ISDN routers support  controls over  ISDN connections, e.g.
  545.         Call-Blocking.  These controls should be used where possible to
  546.         control  the when/where-to/where-from/how-long nature of connec-
  547.         tions.  Powering-off remote access routers when not in use or
  548.         connecting to a timed power supply ensures ISDN calls will not
  549.         be made out-of-hours.
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557. Expires January 1996                                           [Page 10]
  558.  
  559. DRAFT        Reducing the ISDN costs of TCP/IP Applications    July 1996
  560.  
  561.  
  562.    Stephen Waters
  563.    Digital Equipment Co. Ltd.
  564.    Digital Park
  565.    Imperial Way
  566.    Reading
  567.    Berkshire
  568.    RG2 0TE
  569.    UK
  570.    Tel: +44 1548 831170
  571.    Fax: +44 1548 831170
  572.    Email: waters@marvin.enet.dec.com
  573.  
  574.  
  575.  
  576. 7.  References
  577.  
  578.    [1]     "Protocol standard for a NetBIOS service on a  TCP/UDP  tran-
  579.    sport: Concepts and methods'', RFC 1001
  580.  
  581.    [2]     "Transmission Control Protocol'' , RFC 793,  J. Postel,  Sep-
  582.    tember 1981
  583.  
  584.    [3]     "Requirements for Internet hosts  -  communication  layers'',
  585.    RFC 1122,  R. Braden,  October 1989
  586.  
  587. 8.  Acknowledgements
  588.  
  589.    Thanks to Chris Chapman and Mike Shand who took the time to review
  590.    this draft.
  591.  
  592.    (End of Draft)
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613. Expires January 1996                                           [Page 11]
  614.  
  615.