home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1346 < prev    next >
Text File  |  1992-06-17  |  13KB  |  340 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           P. Jones
  8. Request for Comments: 1346                        Joint Network Team, UK
  9.                                                                June 1992
  10.  
  11.  
  12.              Resource Allocation, Control, and Accounting
  13.                     for the Use of Network Resources
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  It does
  18.    not specify an Internet standard.  Distribution of this memo is
  19.    unlimited.
  20.  
  21. 0. MANAGEMENT SUMMARY
  22.  
  23.    This paper gives reasons for wanting better sharing mechanisms for
  24.    networks.  It concludes that the challenge of sharing network
  25.    resources (and for example intercontinental link resources) between
  26.    groups of users is neither well understood, nor well catered for in
  27.    terms of tools for those responsible for managing the services.  The
  28.    situation is compared with other fields, both inside and outside IT,
  29.    and examples are cited. Recommendations for further work are made.
  30.  
  31.    The purpose of this RFC is to focus discussion on particular
  32.    challenges in large service networks in general, and the
  33.    International IP Internet in particular.  No solution discussed in
  34.    this document is intended as a standard.  Rather, it is hoped that a
  35.    general consensus will emerge as to the appropriate solutions,
  36.    leading eventually to the adoption of standards.
  37.  
  38.    The structure of the paper is as follows:
  39.  
  40.       1. Findings
  41.       2. Conclusions
  42.       3. Recommendations
  43.  
  44. 1. FINDINGS
  45.  
  46.    Issues arising from contention in the use of networks are not
  47.    unusual.  Once connectivity and reliability have been addressed to a
  48.    reasonable level, bandwidth becomes (or appears to become?) the main
  49.    issue.  Usage appears to have a strong tendency to rise to fill the
  50.    resources available (fully in line with the principles of Parkinson's
  51.    Law).  Line-speed upgrades have an effect, but with no guarantee of
  52.    permanently alleviating the problem.  Line-speeds are increasing as
  53.    technology improves over time, but the variations on matters like
  54.    availability and funding are wide, and users remain avaricious.
  55.  
  56.  
  57.  
  58. Jones                                                           [Page 1]
  59.  
  60. RFC 1346      Resource Allocation, Control, and Accounting     June 1992
  61.  
  62.  
  63.    Often the situation can appear worse than having to survive in a
  64.    jungle, in the sense that the strong (even if "good") seem to have
  65.    little advantage over the weak.  It may seem that it is the
  66.    determined person rather than the important work that gets service.
  67.  
  68.    Most people will have experienced poor service on an overloaded
  69.    network at some time. To help the end-users, it seems on the face of
  70.    it that one must help the IT Service Manager he relates to.  Examples
  71.    relating to the relationship between the network manager and his
  72.    customers, IT Service Managers at institutions connecting to his
  73.    network, include the following:
  74.  
  75.    (a) If the IT Service Manager finds his link to the Network Manager's
  76.    network overloaded, he may be offered a link upgrade, probably with a
  77.    cost estimate.  He might prefer control mechanisms whereby he can say
  78.    that department X deserves more resources than department Y, or that
  79.    interactive terminal use takes preference over file transfers, or
  80.    that user U is more important than user V.
  81.  
  82.    (b) Where an IT Service Manager is sharing a link, he will commonly
  83.    get more than his institution's share of the link, and often get very
  84.    good value-for-money compared to using a dedicated link, but he has
  85.    no guarantee that his end-users' usage won't get swamped by the use
  86.    of other (perhaps much larger) partners on the shared link.  This
  87.    could be seen as wishing to have a guaranteed minimum share according
  88.    to some parameter(s).
  89.  
  90.    (c) On a shared link as under (b), the Network Manager may wish to
  91.    ensure that usage of the link (which might be a high-performance
  92.    trunk line on a network or an international link for example) by any
  93.    one partner is "reasonable" in relation perhaps to his contribution
  94.    to the costs.  In contrast to (b), the Network Manager is wishing to
  95.    impose a maximum value on some parameter(s).  He may be happy if the
  96.    width of the IT Service Manager's access link is not greater than his
  97.    share of the shared link (assuming the measure agreed on is "width"),
  98.    but this will commonly not be the case.  To be able to reach
  99.    agreement, the Network Manager and the IT Service Manager may need
  100.    options on the choice of parameters, and perhaps a choice on the
  101.    means of control, as well as being able to negotiate about values.
  102.  
  103.    In circumstances where the Network Manager can exercise such controls
  104.    over his customers, the IT Service Managers may say with some feeling
  105.    and perhaps with justification, that if they are going to be
  106.    controlled can the Network Manager please provide tools whereby they
  107.    can arrange for the onward sharing of the resource they have, and
  108.    thence onwards down the hierarchy to the end-users.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Jones                                                           [Page 2]
  115.  
  116. RFC 1346      Resource Allocation, Control, and Accounting     June 1992
  117.  
  118.  
  119.    (d) It may be Network Manager A has a link that Network Manager B
  120.    would like to use on occasion, perhaps as back-up on access to a
  121.    third network.  Network Manager A might well wish to be
  122.    accommodating, perhaps as examples because of financial benefit or
  123.    perhaps because of the possibility of a reciprocal arrangement.
  124.    However, the fear of overload affecting normal use and the lack of
  125.    control over the usage militates against arrangements that the
  126.    parties could be quite keen to make.
  127.  
  128.    Such challenges are very far from being unique to networking.
  129.    Government and both public and private organisations and companies
  130.    allocate budgets (and resources other than money), control and
  131.    account for usage, recognising the possibility of overdrawing and
  132.    borrowing.  In times of shortage, food is rationed.  I haven't
  133.    checked this out, but it would surprise me if Jerry Hall wasn't
  134.    guaranteed a ticket for any Rolling Stones concert, should she wish
  135.    to attend.
  136.  
  137.    The charging factor influences use but does not control it (except
  138.    perhaps in unusual circumstances where say payment was expected in
  139.    advance and usage was cut off when the money ran out).
  140.  
  141.    In the IT world, multi-user hosts have filestore control systems; one
  142.    that I use has an overdraft facility with no penalty for not having a
  143.    prior arrangement!  There are also system designs and implementations
  144.    for sharing host processor time with more sophistication than just
  145.    counting seconds and chopping people off; this problem seems to me to
  146.    be reasonably well understood.  (Library catalogue searches under
  147.    author "John Larmouth" should provide some references for those who
  148.    require convincing.)  Some multi-user hosts have controls of sorts on
  149.    terminal connections.  On the other hand, I am not aware of any
  150.    control system in operation that can guarantee multi-user host
  151.    response time even outside the network context among directly
  152.    connected terminals.
  153.  
  154.    The various roles bring different interests to bear.  A provider will
  155.    not necessarily see it in his interests to control usage, or (perhaps
  156.    even more likely) to provide customers with control tools, since the
  157.    lack of these may encourage - or even oblige - the customer to buy
  158.    more.  Even if the IT Service Manager can deal with the issue of who
  159.    or what is important, and the issues of the relative importance of
  160.    allocating resources against requests, other issues like social
  161.    acceptability may arise to complicate his life.  For example it may
  162.    be generally agreed (and perhaps the network manager instructed) that
  163.    "everyone" must be able to do a small amount of work at any time,
  164.    perhaps to do some housekeeping or seek information.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Jones                                                           [Page 3]
  171.  
  172. RFC 1346      Resource Allocation, Control, and Accounting     June 1992
  173.  
  174.  
  175.    Time is an important factor.  Network resources, like computer
  176.    processor time and unlike filestore, vanish if they are not used.
  177.    People will in general prefer resources during prime shift to those
  178.    in the middle of their night; however, in global terms the middle of
  179.    their night can be during prime shift somewhere along their path of
  180.    usage.
  181.  
  182.    What's to do?  Splitting lines with multiplexers is rather
  183.    inflexible, and may well militate against the benefits of resource-
  184.    sharing that give rise commonly to link-sharing arrangements.  Some
  185.    technologies:
  186.  
  187.       - have the ability to treat (or at least mark) traffic as of high
  188.         priority, for example where it gives emergency or status
  189.         information;
  190.  
  191.       - (in the case of X.25(84), I understand from my JNT colleague Ian
  192.         Smith,) have throughput class (section 6.13) and transit delay
  193.         (section 6.27).  (Ian tells me that it is in his view far from
  194.         clear how practical these facilities are);
  195.  
  196.       - may be able to discriminate between traffic on grounds of
  197.         network source address;
  198.  
  199.       - may be able to discriminate between traffic on grounds of
  200.         network destination address;
  201.  
  202.       - may be able to discriminate between traffic on grounds of
  203.         application protocol, perhaps giving preference to interactive
  204.         terminal traffic, or making a choice between preference for
  205.         email and for file transfer traffic;
  206.  
  207.       - may be able to discriminate between traffic on grounds of other
  208.         facets of network protocol or traffic.
  209.  
  210.    In practice, one may well not have adequate tools in these or other
  211.    terms, and one may well have to ignore the challenges of resource
  212.    control, and either ignore the issue or refuse service.
  213.  
  214. 2. CONCLUSIONS
  215.  
  216.       2.1 There seems to be a lack of tools to enable the controlling
  217.       and the sharing of networks and links.  This is militating against
  218.       the cooperative sharing of resources, and restricting the ability
  219.       of organisations to do business with one another.
  220.  
  221.       2.2 Further, the definition of what constitutes a share, or what
  222.       parameter of service one would try to measure and control (or what
  223.  
  224.  
  225.  
  226. Jones                                                           [Page 4]
  227.  
  228. RFC 1346      Resource Allocation, Control, and Accounting     June 1992
  229.  
  230.  
  231.       the choices are if any), is not clear.
  232.  
  233.       2.3 Following from that, it is then not clear whether what is
  234.       needed is new or enhanced protocols/services, new or enhanced
  235.       procurement specifications or profiles, or new or enhanced
  236.       networking products or tools.
  237.  
  238.       2.4 Service providers (more likely the public carriers or but also
  239.       some Network Managers) may see it as against their interests to
  240.       provide controlling tools if they see them as tending to constrain
  241.       usage and hence reducing income.  If so, they may not support, and
  242.       may even oppose, progress in the area.  However, they might be
  243.       persuaded that the provision of such tools might give them
  244.       competitive edge over their rivals, and therefore to support
  245.       appropriate projects and developments.
  246.  
  247. 3. RECOMMENDATIONS
  248.  
  249.    There seems scope for one or more studies to:
  250.  
  251.       - restate and refine the definition of the problems;
  252.  
  253.       - collect, catalogue and relate relevant experience in both the
  254.         networking and non-networking fields;
  255.  
  256.       - make recommendations as to what areas (e.g., among those
  257.         suggested in 2.3 above) projects should be undertaken;
  258.  
  259.       - outline possible projects, indicating the timescale on which
  260.         improved sharing of production network service resources is
  261.         likely to be achieved, and recommending an order of priority
  262.         among the suggested projects.
  263.  
  264. FOOTNOTES:
  265.  
  266.    Gender issues - where appropriate, the male embraces the female and
  267.    vice versa.
  268.  
  269.    Dramatis Personae:
  270.  
  271.       Jerry Hall is a close associate of Mr. M. Jagger, formerly of the
  272.       London School of Economics in the University of London, and now
  273.       Chairman and Chief Executive of an internationally prominent and
  274.       successful commercial musical operation.
  275.  
  276.       Others mentioned in this paper are assumed to prefer to remain
  277.       anonymous, although the standard is to give contact information
  278.       for the author (see Author's Address section).
  279.  
  280.  
  281.  
  282. Jones                                                           [Page 5]
  283.  
  284. RFC 1346      Resource Allocation, Control, and Accounting     June 1992
  285.  
  286.  
  287. Security Considerations
  288.  
  289.    Security issues are not discussed in this memo.
  290.  
  291. Author's Address
  292.  
  293.    Phil Jones
  294.    JNT
  295.    RAL, Chilton, Didcot, OXON  OX11 0QX
  296.  
  297.    Voice: +44-235-446618
  298.    Fax:   +44-235-446251
  299.  
  300.    Email: p.jones@jnt.ac.uk  or c=gb;a= ;p=uk.ac;o=jnt;i=p;s=jones;
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Jones                                                           [Page 6]
  339.  
  340.