rfc898.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,393 行 · 第 1/3 页

RFC 898                                                       April 1984
Gateway SIG Meeting Notes


      BBN Van gateway PSS - IPSS -Telenet - for hosts that can't use
      SATNET.

      SAM does access control and multihoming.  Clever Multihoming gives
      host a second address and sends an ICMP/Redirect to force TCP
      connection to go through a different route, but  wind up at same
      place!!!

      Wrote EGP in ADA.  It didn't help at all.

   Design of the FACC Multinet Gateway -- FACC - Cook

      Postel:  This is a distributed multiprocessor machine using a
      special bus network for the interprocessor communication.  The
      softaware is written in C.  The gateways is in an early test
      phase.

      Muuss:

      RADC program

      Started with AUTODIN II, switched to DDN.
      Small to large switching devices.
      DoD uses of PDNs, and partitioned network problems.
      
      Distributed processing architecture -
        Parallel contention, 90M bps bus, 22 wires. Each node has cpu,
        memory, optimal comm line. Wire - OR presentation of address,
        contention happens each time bus becomes free, all requestors
        put out type of msg, pri, and address.   Reads back wire - OR of
        result, and highest gwy wins, sorted by (pri, type, higher
      addr).
        Bus was originally designed for our FAA fail-soft application
        Z-800l w/MMU. Not binary addressing, but unitary (base1)
      One element resolved per bus transaction.
      Boards may be plugged in while running.
      Inherent parallelism in layered protocols.

      Interface connector clues board to modem levels and date rate.  Up
      to 100K bps now, soon up to T1 rate.

      Multiprocessor approach allows routing calculation to take place
      out-of-band from the measurement of delay and traffic, and allows
      use of more compute power for routing.

      Mostly written in C, with some assembler.  Multiprocessor
      operating system, designed from scratch.



Hinden, Postel, Muuss, & Reynolds                              [Page 17]



RFC 898                                                       April 1984
Gateway SIG Meeting Notes


   SAC Gateway -- SRI - Su/Lewis

      Postel:  This was a presentation of the design for the gateways to
      be used in the advanced SAC demo experiments on network
      partitioning and reconstitution, and communication between
      intermingiling mobile networks.  Much of these demonstrations will
      be done with packet radio units and networks.  Some of the ideas
      are to use a gateway-centered type of addressing and double
      encapsulation (i.e., an extra IP header) to route datagrams.

      Muuss:

      Network dynamics due to component mobility or failure.
      Mobile host, reconstitution, partitioning.
        H/W:  11/23
        S/W:  Some "C" gateway
        OS:   VMOS (SRI)

      Gateway-centered addressing, rather than network.
        Gw host instead of net.host.
      Double encapsulation:  additional IP header.
        TCP uses addr as an ID, IP uses it as an ADDRESS (-> route)
        Need to separate these dual uses of this address field.
      Incremental Routing (next-hop indication)

   EGP -- Linkabit - Mills

      Postel:  A presentation of the EGP design.  EGP has three major
      aspects, neighbor acquisition, neighbor reachability, and network
      reachability.  The autonomous system concept was discussed.

      Muuss:

      Background, Implementation, Experience, Disparaging Remarks

      Design goals -
        o   Established demarcations
        o   Decouple implementations
        o   Confine routing loops
        o   Exchange reachability information
        o   Provide flow control for connectivity information
        o   Medium-term lifetime

      Non goals                       Not trying to do these!
        o   Flexibility of topology
        o   Rapid response             Very slow update




Hinden, Postel, Muuss, & Reynolds                              [Page 18]



RFC 898                                                       April 1984
Gateway SIG Meeting Notes


        o   Adaptive routing
        o   Common routing metric      No agreement at all
        o   Load sharing or splitting

      "Good news travels fast and bad news travels forever."
      Not for routing, but only provides reachability
      
      RFC827 initial mode, RFC888 stub protocol

      Neighbor acquisition protocol
         o   2-way shake
         o   Flow - rates
         o   Explicit acquisition/cause

      Neighbor reachability protocol
         o   Periodic polling
         o   Parasitic information
         o   Reachability algorithm Network reachability
             protocol
         o   Periodic pulling
         o   Remote information
         o   Direct and indirect neighbors
         o   Indirect internal and indirect external
             neighbors
         o   Distance information

      EGP neighbors do not need to peer with more than one
      CORE gateway, but you may peer with anybody you wish.

      Shortcomings -
         o   Slow reaction due polling
         o   Tree-structured routing constraint
           - Rigid topology
           - Administrative resistance to odering
           - Lack of adaptive connectivity
         o   Neighbor acquisition incomplete.

      Loops between autonomous systems will last a long
      time, and are a real no-no.

      System models -
         o   "Appropriate first hop" criterion
           - Not useful for implementation
           - Requires global information
           - Inadequate for verification
         o   Graph models
           - N-graph shows net connectivity
           - T-graph shows system connectivity


Hinden, Postel, Muuss, & Reynolds                              [Page 19]



RFC 898                                                       April 1984
Gateway SIG Meeting Notes


           - T-acycloc criterion insures loop-free
         o   Derived features
           - Induces spanning tree

      N-graph

                                        G1
                                  A_______________B
                                 / \            /\
                            G2  /   \  G3   G4 /  \ G5
                               /     \        /    \
                              C------D        E-----F G6

         AS1 = G2, G3, G6                   A         B
         AS2 = G1
         AS3 = G4, G5                 AS1 ----- AS2 ----- AS3

                                               T-graph

      Test:  to ensure that there are no cycles

      Spanning subtree

      Specification effort - Status report State machine designed

      Remaining issues -
        o   Remove extra hop in core system
        o   Expand tables
        o   Test backdoor "GGP"
        o   Resolve specification issues
        o   Resolve full gateway configuration
              - Back door connectivity guidance
              - can only advertise 1 path at a time.
              - APF rule guidancee
              - Self organization issues
        o   Implement and distribute for operational systems.

   Congestion Control -- FACC - Nagle

      Postel:  This was a discussion of the situation leading to the
      ideas presented in RFC 896, and how the policies described there
      improved overall performance.








Hinden, Postel, Muuss, & Reynolds                              [Page 20]



RFC 898                                                       April 1984
Gateway SIG Meeting Notes


      Muuss:

      First principle of congestion control:

         DON'T DROP PACKETS (unless absolutely necessary)

      Second principle:

         Hosts must behave themselves (or else)

         Enemies list -

            1.  TOPS-20 TCP from DEC
            2.  VAX/UNIX 4.2 from Berkeley

      Third principle:

         Memory won't help (beyond a certain point).

         The small packet problem: Big packets are good, small are bad
         (big = 576).

      Suggested fix: Rule: When the user writes to TCP, initiate a send
      only if there are NO outstanding packets on the connection. [good
      for TELNET, at least] (or if you fill a segment). No change when
      Acks come back. Assumption is that there is a pipe-like buffer
      between the user and the TCP.

      The source quench problem Rule: When a TCP gets an ICMP Source
      Quench, it must reduce the number of outstanding datagrams on
      relevant TCP connections.

      Rule: When a gateway nears overload, before starting to drop
      packets, send a Source Quench.

      Node capacity: Each node ought to have one buffer for each TCP
      connection, plus some for overload.

      Both fixes really need to be done together, although the first one
      is often helpful by itself. Side effect: FTPs start off "slowly,"
      until the first Ack comes back Dave Mills thinks this will
      increase the mean delay for medium-size interactions. This
      probably will not work so well for SATNET.

      Problems about propagation time of links biasing the validity of
      this result!!




Hinden, Postel, Muuss, & Reynolds                              [Page 21]



RFC 898                                                       April 1984
Gateway SIG Meeting Notes


   A Gateway Congestion Control Policy--NW Systems - Niznik

      Postel:  This talk was (for Postel) hard to follow.  There were a
      number of references to well known results in queuing theory etc,
      but I could not follow how they were being used.

      Muuss:

      Replacements for IMP SPF
      Topological observations
      Nodal congestion control policy
        GMD - control application [from German network]
        RPN - relational Petri net
        DCT - dynamic congestion table
      NCCP performance evaluation
      Planned GCCP:  Gateway congestion control policy

      Lots of diagrams and figures.

      Better throughput than SPF, but somewhat higher delay.

      Cubic structure of table.

   DISCUSSION (Postel's personal comments)

      There was very little organized discussion during the meeting and
      not really very much question and answer interaction during the
      presentation.  There was a lot of discussion during the breaks,
      and at lunch time, and at the end of each day.

      Some things that occured to me during the meeting that may have
      been triggered by something someone said (or maybe by the view out
      the window):

         Don't design a protocol where you expect to get a lot of
         messages from a lot of sources at the same time.  For example,
         don't ask all the hosts on an Ethernet to send you an ack to a
         broadcast packet.

         Has anyone worked out in detail the routing traffic costs for
         the GGP vs the SPF procedures for the actual case of the
         Internet?

         How will the fact that thinking of the routing in the core
         autonomous system is cast in terms of an entry and an exit
         gateway effect other things?  Will there be special




Hinden, Postel, Muuss, & Reynolds                              [Page 22]



RFC 898                                                       April 1984
Gateway SIG Meeting Notes


         arrangements between the entry and exit gateway?  Will an
         autonomous system become a circuit switch connecting pairs of
         entry/exit gateways?

         Is TOS routing worth the cost?

         Should we allow (as a new type of ICMP message) redirects to
         Gateways?

         Does making memory larger ever hurt?  If a gateway's memory is
         full of inappropriately retransmitted TCP segments would it be
         better if there were less memory?

         Is there something reasonable to do with source quench at the
         TCP?  Re: RFC-896.

         If there are links (or networks) of vastly differing delay and
         thruput characteristics what impact would an IP level load
         splitting (say by gateways) have on TCP connections (some of
         the segments of the connection go one path and others go a
         different path)?

         Are any problems avoided (either way) by using double IP
         headers vs a "source route like" IP option to separate the IP
         level addressing and routing function from the TCP level
         end-point naming function of the IP addresses.

         What bad things could happen from the proposed IP
         multidestination routing option?





















Hinden, Postel, Muuss, & Reynolds                              [Page 23]



RFC 898                                                       April 1984
Gateway SIG Meeting Notes


MEETING ATTENDEES

   Mike Accetta - CMU
   R. Buhr - Canada
   J. Noel Chiappa - MIT
   Paul Cook - Ford
   Jon Crowcroft - UCL
   Barbara Denny - SRI
   Jim Forgie  - LL
   Steve Groff - BBN
   Phill Gross - Linkabit
   Kjell Hermansen - NTA
   Robert Hinden - BBN
   Patrick Holkenbrink - FACC
   Ruth Hough - AIRINC
   Willie Kantrowitz - LL
   Paul Kirton -ISI
   Mark Lewis -SRI
   Liza Martin - MIT
   Doug Miller - MITRE
   Dave Mills - Linkabit
   Mike Muuss - BRL
   Jose Nabielsky - MITRE
   Ron Natalie - BRL
   John Nagle  - Ford
   Carol Niznick  NW Systems
   Jon Postel - ISI
   Joyce Reynolds  -ISI
   Marshall Rose - UCI
   Joe Sciortino - AIRINC
   Linda Seamonson - BBN
   Nachum Shacham - SRI
   Alan Sheltzer - UCLA
   Marvin Solomon  - WISC
   Zaw-Sing Su - SRI
   Mitch Tasman - BBN














Hinden, Postel, Muuss, & Reynolds                              [Page 24]