rfc1152.txt

RFC 的详细文档！

   Kentucky) was that processes requiring communication service would
   specify their needs in terms of peak and average data rate as well as
   defining burst parameters (frequency and size).  Bandwidth for a
   given flow would be allocated at the effective data rate that is
   computed on the basis of flow parameters.  The effective data rate
   lies somewhere between the peak and average data rate based on the
   burst parameters.  Statistical multiplexing would take up the gap
   between peak and effective rate when a sudden burst of traffic
   arrives.  Bounds on packet loss rate can be computed for a given set
   of flow parameters and corresponding effective data rate.

   This presentation led to a discussion about deliberate disciplining
   of inter-process communication demands to match the requested flow
   (service) profile.  This point was made in response to the
   observation that we often have little information about program
   behavior and might have trouble estimating the network service
   requirements of any particular program.

Architectural Discussion

   An attempt was made to conduct a high-level discussion on various
   architectural questions.  The discussion yielded a variety of
   opinions:

      1.  The Internet would continue to exist in a form similar
          to its current incarnation, and gateways would be required,



Partridge                                                      [Page 19]

RFC 1152                  IRSG Workshop Report                April 1990


          at least to interface the existing facilities to the high
          speed packet switching environment.

      2.  Strong interest was expressed by some participants in access
          to raw (naked ATM) services.  This would permit users
          to construct their own gigabit nets, at the IP level, at any
          rate.  The extreme view of this was taken by David Cheriton
          who would prefer to have control over routing decisions and
          other behavior of the ATM network.

      3.  The speed of light problem (latency, round-trip delay)
          is not going to go away and will have serious impact on
          control of the system.  The optimistic view was taken,
          for example, by Craig Partridge and Van Jacobson, who felt
          that many of the existing network and communications
          management mechanisms used in the present Internet protocols
          would suffice, if suitably implemented, at higher speeds.
          A less rosy view was taken by David Clark who observed
          (as did others) that many transactions would be serviced in
          much less than one round-trip time, so that any end-to-end
          controls would be largely useless.

      4.  For applications requiring fixed, periodic service,
          reservation of resource seemed reasonably attractive to many
          participants, as long as the service period dominated the
          set-up time (round-trip delay) by an appreciable
          margin.

      5.  There was much discussion throughout the workshop of
          congestion control and flow control.  Although these
          problems were not new, they took on somewhat newer
          character in the presence of much higher round-trip delays
          (measured in bits outstanding).  One view is that end-to-end
          flow control is needed, in any case, to moderate sources
          sending to limited bandwidth receivers.  End-to-end flow
          control may not, however, be sufficient to protect the
          interior of the network from congestion problems, so
          additional, intra-network means are needed to cope with
          congestion hot spots.   Eventually such conditions
          have to be reflected to the periphery of the network to
          moderate traffic sources.

      6.  There was disagreement on the build or simulate
           question.  One view was in favor of building network
          components so as to collect and understand live application
          data.  Another view held that without some careful
          simulation, one might have little idea what to build
          (for example, Sincoskie's large buffer pool requirement was



Partridge                                                      [Page 20]

RFC 1152                  IRSG Workshop Report                April 1990


          not apparent until the system was simulated).

Comments from Workshop Evaluation Forms

   At the end of the IRSG workshop, we asked attendees to fill out an
   evaluation form.  Of the fifty-one attendees, twenty-nine (56%)
   turned in a form.

   The evaluation form asked attendees to answer two questions:

      #1.  Do you feel that having attended this workshop will help you
           in your work on high speed networks during the next year?

      #2.  What new ideas, questions, or issues, did you feel were
           brought up in the workshop?

   In this section we discuss the answers we got to both questions.

Question #1

   There was a satisfying unanimity of opinion on question #1.  Twenty-
   four attendees answered yes, often strongly (e.g., Absolutely and
   very much so).  Of the remaining five respondents, three said they
   expected it to have some effect on their research and only two said
   the workshop would have little or no effect.

   Some forms had some additional notes about why the workshop helped
   them.  Several people mentioned that there was considerable benefit
   to simply meeting and talking with people they hadn't met before.  A
   few other people noted that the workshop had broadened their
   perspective, or improved their understanding of certain issues.  A
   couple of people noted that they'd heard ideas they thought they
   could use immediately in their research.

Question #2

   Almost everyone listed ideas they'd seen presented at the conference
   which were new to them.

   It is clear that which new ideas were important was a matter of
   perspective - the workshop membership was chosen to represent a broad
   spectrum of specialties, and people in different specialities were
   intrigued by different ideas.  However, there were some general
   themes raised in many questionnaires:


      (1)  Limitations of our traffic models.  This particular subject
           was mentioned, in some form, on many forms.  The attendees



Partridge                                                      [Page 21]

RFC 1152                  IRSG Workshop Report                April 1990


           generally felt we didn't understand how network traffic would
           behave on a gigabit network, and were concerned that people
           might design (or worse, standardize) network protocols for
           high speed networks that would prove inadequate when used
           with real traffic.  Questions were raised about closed-loop
           vs. open-loop traffic models and the effects of varying types
           of service.  This concern led several people to encourage the
           construction of a high-speed testbed, so we can actually see
           some real traffic.

      (2)  Congestion control.  Despite the limitations of our traffic
           models, respondents felt that congestion control at both
           switching elements and network wide was going to be even more
           important than today, due to the wider mix of traffic that
           will appear on gigabit networks.  Most forms mentioned at
           least one of the congestion control talks as a containing a
           new idea.  The talks by Victor Frost, Jamal Golestani and
           Scott Shenker received the most praise.  Some attendees were
           also interested in methods for keeping the lower-layer
           switching fabric from getting congested and mentioned the
           talks by Robinson and Maxemchuk as of interest.

      (3)  Effects of fixed delay.  While the reviews were by no means
           unanimous, many people had come to the conclusion that the
           most serious problem in gigabit networking was not bandwidth,
           but delay.  The workshop looked at this issue in several
           guises, and most people listed at least one aspect of fixed
           delay as a challenging new problem.  Questions that people
           mentioned include:


    -    How to avoid a one round-trip set up delay, for less than one
         round-trip time's worth of data?

    -    How to recover from error without retransmission (and thus
         additional network delays)?  Several people were intrigued by
         Nachum Shacham's work on error detection and recovery.

    -    Should we use window flow-control or rate-based flow control
         when delays were long?

    -    Can we modify the idea of remote procedure calls to deal with
         the fact that delays are relatively long?

A couple of attendees noted that while some of these problems looked
similar to those of today, the subtle differences caused by operating a
network at gigabit speeds led them to believe the actual approaches to
solving these problems would have to be very different from those of



Partridge                                                      [Page 22]

RFC 1152                  IRSG Workshop Report                April 1990


today.

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Craig Partridge
   Bolt Beranek and Newman Inc.
   50 Moulton Street
   Cambridge, MA 02138

   Phone: [phone]

   EMail: [e-mail]



































Partridge                                                      [Page 23]