RFC 898

Gateway special interest group meeting notes

📅 published April 1984, from ietf

RFC 898: GATEWAY SPECIAL INTEREST GROUP MEETING NOTES 💖

(Part 1 of 4)

  • Network Working Group 🌸 The group this doc was filed under.
  • Request for Comments: 898
  • Authors: R. Hinden (BBN), J. Postel (ISI), M. Muuss (BRL), J. Reynolds (ISI)
  • Date: April 1984
  • Category: Not stated in the header. The Status section says it's a meeting report 📝
  • Obsoletes / Updates: The header doesn't list any RFCs this one obsoletes or updates 🙅‍♀️

STATUS OF THIS MEMO

Okay so this memo is just a recap of a meeting 🎀 There are no conclusions, decisions, or policy statements written down in here, so don't go hunting for any. It's a vibe check, not a rulebook ✨

INTRODUCTION

This memo recaps the Gateway Special Interest Group Meeting, which was held at ISI in Marina del Rey, California on 28 and 29 February 1984 🌴 Robert Hinden of BBNCC chaired, and Jon Postel of ISI hosted. Roughly 35 gateway designers and implementors showed up, so it was a whole thing 🙈

The notes come from what Jon Postel and Mike Muuss remembered. Under each topic, Jon's brief notes come first, followed by extra details from Mike 🧚

The rest of the memo has three parts: the agenda, notes on the talks, and the attendees list. 💅

MEETING AGENDA

Here's the schedule for both days, copied exactly so nothing gets lost in translation 🦋

   Tuesday, February 28

      9:00  Opening Remarks -- BBN - Hinden
      9:15  Opening Remarks -- ISI - Postel
      9:30  The MIT C Gateway -- MIT - Martin
      10:00 The Butterfly Gateway -- BBN - Hinden
      10:30 Break
      11:00 The EGP C Gateway -- ISI - Kirton
      11:20 The BRL Gateway -- BRL - Natalie
      11:40 The CMU Gateway -- CMU - Accetta
      12:00 Lunch
      1:30  The Wisconsin BITNET/CSNET Gateway -- UWisc - Solomon
      2:00  LAN to X.25 Gateway -- Computer Gateways Inc. - Buhr
      2:20  ISI-UCI Gateway -- UCI - Rose
      2:40  FACC Gateway -- FACC - Holkenbrink
      3:00  Break
      3:30  Lincoln IP/ST Gateway -- LL - Forgie/Kantrowitz
      3:50  Minimal Stub Gateways -- MITRE - Nabielsky
      4:10  Discussion

   Wednesday, February 29

      9:00  Opening Remarks -- BBN - Hinden
      9:10  SPF routing -- BBN - Seamonson
      9:35  Multiple Constraint Routing -- SRI - Shacham
      10:00 FACC Multinet Gateway Routing -- FACC - Cook
      10:30 Break
      11:00 Metanet Gateway -- SRI - Denny
      11:20 Address Mapping and Translation -- UCL - Crowcroft
      11:40 Design of the FACC Multinet Gateway -- FACC - Cook
      12:00 Lunch
      1:30  SAC Gateway -- SRI - Su/Lewis
      2:00  EGP -- Linkabit - Mills
      2:30  Congestion Control -- FACC - Nagle
      3:00  Break
      3:30  A Gateway Congestion Control Policy--NW Systems - Niznik
      4:00  Discussion

NOTES ON THE MEETING

Time to dig into the talks 🔥

The MIT C Gateway -- MIT - Martin ✨

Postel: Okay so Jon walks through the gateway that MIT built 💅 Noel Chiappa first developed it, and it's written in C. The MIT environment has 32 internal networks, and they're treated as subnets of MITNET on the Internet. The MIT gateways then do subnet routing in their interior protocol, and that scheme is similar to GGP. Liza also added an EGP implementation to this gateway 🫶

Muuss: Mike's notes are packed, so here's the tea with every number kept exactly as he wrote it 🍓

  • Campus network/project Athena
  • Dynamic routing
  • Congestion control - grad student
                     +---------------+---+
       Class A net  : | 18|subnet|res|host|
                     +---------------+---+
  • "Bridges" forward between subnets.
  • Campus Network and Project Athena 65 VAX 750s, 200 IBM PCs.
  • Hosts: Now = 400, 1986 = 3,000, 1990 = 10,000
  • Subnets: Now = 42, 1985 = 60, 1990 = 200, (4 subnets/building)
  • Protocols: Internet, DECnet, Chaosnet
  • FiberOptic spine between campus buildings.

MIT's gateway hardware was a mix of machines:

  • 11/03s and 11/23s
  • 68000 on Abus
  • 6800 on Multibus (Bridge communications)

The MIT C gateway runs under MOS, bridge OS, and a homegrown OS, and it handles multiple protocols across multiple interfaces 🌈

  • 11/03 - 100 packets/sec.
  • 11/23 - 180 packets/sec.

Quick glossary, because the acronyms are everywhere 🧚‍♀️

  • GGP - Gw/Gw
  • EGP - Exterior Gw
  • IGP - Interior Gw

On the EGP side, the big ideas are autonomous systems, plus these pieces:

  • Neighbor acquisition
  • Hello/I heard you
  • Net reachability poll
  • Net reachability message

For the MIT IGP, the IP header rides on the EGP protocol, and the destination is written like this:

IP header on EGP protocol
Dest: net number, subnet number, 0, 0377 (broadcast address)

The IGP header carries these fields:

IGP header:
    Autonomous system number
    Sequence number

The tasks are to propagate exterior and subnet routing 🦋

Packets handle ext route requests and updates to the routing server, which tracks:

  • Default gateway
  • Exceptional gateways
  • Nets reached

MIT's gateway broadcasts its initial routings when it comes up, and again on each change. Each change floods the net several times. Each bridge can ask for help 💜

Future: A wideband net gateway from BBN will also sit on net 18, along with an MIT routing server to acquire routing information. The trick is that BBN-Gw will sit on an Ethernet, and a modified ARP will be used by the bridges to "fool" the BBN gateway into acquiring the routes 🙈

Subnet routing is inspired by PUP and CHAOS, and it's built around a few structures:

Neighbor Bridge
    Net I/F
    Bridge address
    Latest seq number
    Aging value
Route to subnet
    Distance

Packets come in two flavours, a Request and an "I'm up":

Packets
    Request
    I'm up

The route update carries a distance vector of 256 bytes, and the values mean:

Route update
    Distance vector (256 bytes)
             0 - Direct
             1 -127 - hop count
             128-255 - "Interface used for next hop" to subnet
                       and hop count
             255 - Unreachable

The problem they flagged is that there are many neighbors, which means too much time and traffic is needed for processing 😭

  • Problem - Many neighbors --> too much time and traffic needed for processing.
  • 3 level addressing and routing strategy
  • Ext Gw: Routing server, Default Gw
  • Subnet routing: Small but rich subnet routing updates ✨
  • Consistency checks
  • Redirects does not forward misrouted packets
  • Fragmentation - ICMP dest unreach If DF Set
  • Access list for who can pass through

No GGP, no EGP, uses known gateways 💅

Ordinary devices and PDP-10 and PDP-20 🧚

The Wisconsin BITNET/CSNET Gateway -- UWisc - Solomon 🎀

Postel: This was a discussion of a mail relay between the Internet and BITNET to be installed at Wisconsin.

Muuss:

  • WISC-IBM (192.5.2.24) will connect to BITNET
  • Mail gateway, BITNET uses RFC 822 headers! 📬

LAN to X.25 Gateway -- Computer Gateways Inc. - Buhr 🦋

Postel: This was a description of a protocol translation device between an X.25 world and the DATAPOINT ARCNET world.

Muuss:

  • ARCNET to X.25 Bridge
  • ARCNET - from Datapoint,
    • Baseband coax, 2.5 mbps
    • Token passing
    • Reserve/send/wait/ack protocol
    • RIM chip implements this

"The OSI models seem less clear than the Internet models, perhaps because they are less well developed." 🙈

Wraps the subnetwork in an enhanced subnetwork layer.

Every pair of subnetworks must be connected in this design - hence a bridge not a gateway. 💀

Bridge is a network layer RELAY.

ARCNET address is sent as X.25 data.

ISI-UCI Gateway -- UCI - Rose 🌸

Postel: This was a description of the UCI dumb gateway. This one is made up of two hosts (VAX 750s) 50 miles apart. The VAXs are connected via a 9.6 Kbs leased line. One is interfaced to the ISI-NET (an Ethernet) and the other to UCIICS net (also an Ethernet). The VAXs run Berkeley Unix 4.1. These VAXs run as regular hosts too.

Muuss:

MTU is 512. Effective bandwidth of approximately 6000 baud over 9600 baud line.

FACC Gateway -- FACC - Holkenbrink 👑

Postel: A description of a gateway designed by Ford. The gateway is based on a MC68000 multiprocessor and a VME bus. An interesting question that came up during this presentation was "What is the least information a host (or gateway) must have when it comes up, and how can it acquire the rest of what it needs to go into full operation from the environment?"

Muuss:

  • Inter-segment Processor. M68000 CPU with various co-processors.
  • 68000 IOPS, 1822, IOP Ethernet IOP. 1 cpu does IP, routing.
  • Multi-cpu version of MOS

Lincoln IP/ST Gateway -- LL - Forgie/Kantrowitz ⭐

Postel: This was a discussion of the design of the Lincoln gateways used primarily in the WBCNET for speech transmission research. This gateway uses special I/O interfaces to promote a high packet processing rate. The gateway implements both the regular IP, and the ST protocol which permits resource reservations to minimize the variation in transmission delay. These gateways can, of course, act as regular internet gateways, and have achieved very good performance in terms of datagrams per second.

Muuss:

  • Packet voice experiments, wideband SATNET. Concentrate traffic from local nets to trunk net. Needed enough performance to load WBSATNET. 11/44 and ACC IF11 (Z-80). T1 trunk protocol converter. (voice T1 <--> datagram)
  • IP problems -
    • Congestion
    • High packet header overhead
    • No support for conference call
  • ST -
    • Virtual circuit
    • Know capacity in advance, schedule channel
    • Abbreviated header
  • 11/44 - 900 to 1000 pkts/sec.
  • Port processor:
    • Sync low speed: 600K bits/sec.
    • Packet processing: 500 pkts/sec. average
      • 20-talker LPC voice loop, 28 data bytes/pkt, 50% duty cycle
    • Data handling
      • 4 pcm voice stream loop 64K bps
      • 184 data bytes/pkt, 100% duty cycle
  • Dispatcher Requirements
    • Timely do ST
    • Utilize rest of circuit for IP
    • Performance measurement
  • Reservations on the SATNET: Each host makes a reservation for Nbytes of M messages every INTERVAL. Reservations are absolute.
  • ST and IP for each distant run = MPP multipurpose packets.
  • 12,000 lines of C code in 11/44 portion. 🔥

Minimal Stub Gateways -- MITRE - Nabielsky 🍓

Postel: This was a more abstract discussion of how stub gateways could interact and acquire information about the topology of the Internet.

Muuss:

  • Ethernet stub to Internet
  • Inexpensive, single-band ISBC 186/51 Intel @ $3000
  • High performance. EGP?
  • 128K bytes/board
  • The Internet forest
  • Alternative to ARP using Multicast

SPF routing -- BBN - Seamonson 💜

Postel: This was a fine presentation of the principles of the "Shortest Path First" (SPF) routing procedures with some remarks on how it is tailored to the Internet gateway situation. One point that was impressed on me was that when using SPF in a set of gateways (say, the core autonomous system) the procedure will do routing to an "exit" gateway. Somehow I had not thought about it in those terms before, but (obviously) just as there is a source and a destination IMP in the ARPANET there will be an entrance and an exit gateway in an SPF autonomous system.

Muuss:

  • Features -
    • Metric, update procedures, path calculation, forwarding
  • Current GGP problems -
    • Counting to infinity
    • Not enough topology information in each Gw
    • Updates potentially very large
  • SPF in ARPANET
    • Single path (not optimal) - no split of flow
    • Delay based, to minimize delay
    • Global knowledge of connection topology and delays
  • Metric used -
    • Delay, delay of each packet averaged (queueing plus transmission plus propagation) arrival-to-arrival time.
    • Average delay on each trunk computed every 9.6 seconds. Report large changes in delay, fast
  • Update procedure -
    • Updates report delay to each neighbor
    • Update triggered by topology change, significant delay change, or 1 time/minute. Decay of threshold to direct to send update
    • Sequence numbers
    • Flooding on all trunks sent out on all lines
    • Receipt of echo is acknowledgement
    • Retransmission
    • Aging of information
    • Updates are 2*n*l packet growth. n = number imps, l = number lines
      • When lines goes up, rather than dumping routing table, just waits one minute until all updates have been heard.
  • Path calculation
    • Dijkstras Algorithm
                          20
                 A _______________ F
                / \  \
             3 /   \10\15
              /     \  \
            B/___5___\D \E
             \      /  /
              \    /  /
             1 \  /  /5
                \/  /
                 C /
1.         A       B(A, 3), D(A, 10), E(A, 15). F(A, 20)

2.         A       C(B, 4), D(B, 8), E(A, 15), F(A, 20)
           |
           B

4.         A          E(C, 9),  F(A,20)
           |
           B
          / \
         C   D

5.         A
           |
           B
           |
           C
          /
         E

Then tree is inverted into a "go here to get to this destination."

For Internet -

  • Similar algorithm, needs special packet header to indicate "exit" gateway to get to destination network.
  • Update procedure -
    • Neighbor interface, neighbors, and delay to neighbor.
    • "Next door neighbors" for minimizing traffic.
    • Ability to package multiple updates in one average explicit Acks.
  • Path calculation -
    • Possible to build different trees based on type of service.
  • Forwarding -
    • Exit Gw
    • Consistent databases are important.

Multiple Constraint Routing -- SRI - Shacham 🦋

Postel: This was a clear presentation of some of the consequences of the idea of type of service routing. The level of complexity of the routing procedure is determined to depend on how many categories of service there are and how many selections there are in each category. A few examples were discussed including the current type of service parameters of IP.

Muuss:

Both current and proposed ARPANET algorithms provide "best" path under single constraint (number of hops, delay). Internet will have diverse characteristics, it would be nice to consider more than one constraint.

  • Determine a set of measures.
  • Represent each measure as a single number.
  • Determine range of values. (complexity 0(c**n) range of n)
  • Define path measure as a function of measure of length.
     sum (delay, cost)
     min/capacity, length, security)

If just one cost is used, then SPF (or whatever) can be used for each cost. However, under multiple constraints there is a more difficult problem. e.g.: minimum delay with packet size of at least 1000 bytes.

RUMC has been shown to be in the NP complete family.

RUMC needs bigger tables, more processing and routing overhead. it's not awful for 2-choice TOS, like in IP.

Table size is random, we have to be prepared for the worst case.

Possible strategies: flood a "search packet," dropped when constraints are not met, see if it makes it though. Good only for virtual circuit. Weighted sum (VC only) works only with some probability.

TOS is needed for Internet, but the algorithms are costly. Complexity for providing TOS IP style is not too high.

FACC Multinet Gateway Routing -- FACC - Cook ✨

Postel: This approach considered hop count to be an inadequate metric for routing decisions in a system of different types of networks (e.g., Ethernets, ARPANETs, 2.4Kb lines). Delay was selected as the metric to use. There are some interesting issues in the measurement of delay for some types of networks. Also, the design considers the use of multiple paths when they are available, and routing to provide connectivity between the parts of partitioned networks.

Muuss:

  • Routing with a single constraint.
  • A network of gateways Access, Transport, or Dual networks.
  • Some networks are used as backbones between gateways only.
  • Routing updates
    • Variable length
    • Broadcast routing updates
  • Unitary ends - A - Gw - B - Rest
    • Routing for A is really just routing to B
    • Neighbor Gws, nets
    • Lots and lots of tables

Metanet Gateway -- SRI - Denny 🌈

Okay so this one is a whole buffet of gateway drama, bestie 💅 Postel kicks off with a project to invent new addressing features for gateways 🦋 There's a scheme that uses an option kinda like the source route option to do multi-addressing of IP datagrams, and the gateways that implement it will have to know which other gateways do and don't implement it 👀 There was also talk of a gateway to a network in radio silence, and how to keep TCP connections going with hosts that literally can't talk back 🙈 The project is also thinking about network reconstitution, security, survivability, congestion control, and supporting multimedia data (voice, bitmaps, etc.) in applications 🎀 A gateway is being built in ADA for a MC68000 machine (SUN), and the first version is supposed to be up in May 84 ✨

Muuss then drops the notes, and they're giving Navy internet energy 🌊

  • Multimedia mail and conf.
  • Radio silence (EMCON)
  • Security and Survivability.

EMCON causes special problems for EGP and IGP one way nonTCP mail delivery 😭 There are no Acks. It uses a name screen to redirect mail to a special one-way mail catcher, who then forwards it using ordinary methods. Iconic workaround, no notes 🫶

For security and survivability, the access control is a "capability", a 32/64 bit key that changes frequently (every hour or so) 🔐 Reconstitution covers partitioning, coalescing, and mobile host 🌈 Test and monitoring is HMP 🧚 The gateway target is a 68000 in ADA, using the Telesoft compiler 💜

Address Mapping and Translation -- UCL - Crowcroft

Postel says this was a discussion of some issues in interconnecting networks of different types, including the Internet and networks in England like the Universe network 🇬🇧 The Universe network is made up of Cambridge Rings at several sites, linked via a satellite channel 🛰️

Muuss notes: ARPA, SATNET, NULLNET, UCLNET, UNIVERSE Satellite, and 3 UCL rings 💖 The SAM setup has:

  • IP switch to several 1822 hosts
  • IP/universe mapper, which overlays UCLNET on universe
  • Mask and match: 128. 11. code. host

There are three types:

  1. Direct: code --> subnet
  2. Redirect: 2nd lookup (for multihoming)
  3. Logical: Logical address into a table of universe names. Name lookups give addresses and routes.

IP tunnels through X.25 🚇 There's also a BBN Van gateway PSS - IPSS - Telenet, for hosts that can't use SATNET 🌸

SAM does access control and multihoming ✨ The clever multihoming gives a host a second address and sends an ICMP/Redirect to force the TCP connection to go through a different route, but it winds up at the same place!!! 🙃 Main character plot twist 😭

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

Design of the FACC Multinet Gateway -- FACC - Cook

Postel says this is a distributed multiprocessor machine using a special bus network for interprocessor communication 🤖 The software is written in C, and the gateway is in an early test phase 🍓

Muuss says it's an RADC program 🎀 They started with AUTODIN II, then switched to DDN 💅 It covers small to large switching devices, DoD uses of PDNs, and partitioned network problems 🦋

The distributed processing architecture is giving main character:

  • Parallel contention, 90M bps bus, 22 wires. Each node has a cpu, memory, and optimal comm line.
  • Wire-OR presentation of address. Contention happens each time the bus becomes free, and all requestors put out type of msg, pri, and address.
  • They read back the wire-OR of the result, and the highest gwy wins, sorted by (pri, type, higher addr).
  • The bus was originally designed for the FAA fail-soft application.
  • Z-800l w/MMU. Not binary addressing, but unitary (base1).
  • One element is resolved per bus transaction.
  • Boards may be plugged in while running 🔥
  • There is inherent parallelism in layered protocols.

The interface connector clues the board to modem levels and data rate. It's up to 100K bps now, soon up to T1 rate ⭐

The multiprocessor approach lets the routing calculation happen out-of-band from the measurement of delay and traffic, and allows use of more compute power for routing 🧠 It's mostly written in C, with some assembler, on a multiprocessor operating system designed from scratch 🌈

SAC Gateway -- SRI - Su/Lewis

Postel says this was a presentation of the design for the gateways used in the advanced SAC demo experiments on network partitioning and reconstitution, plus communication between intermingling mobile networks 🛰️ Much of the demo will be done with packet radio units and networks 📡 Some ideas are to use gateway-centered addressing and double encapsulation (i.e., an extra IP header) to route datagrams 🫶

Muuss adds: network dynamics due to component mobility or failure, plus mobile host, reconstitution, and partitioning 🌸

  • H/W: 11/23
  • S/W: Some "C" gateway
  • OS: VMOS (SRI)

Gateway-centered addressing, rather than network. It's a gw host instead of net.host 🦋 Double encapsulation means an additional IP header. TCP uses the addr as an ID, but IP uses it as an ADDRESS (-> route), so they need to separate these dual uses of the address field 👀 There's also incremental routing (next-hop indication) 💜

EGP -- Linkabit - Mills

Postel says this was a presentation of the EGP design 💖 EGP has three major aspects: neighbor acquisition, neighbor reachability, and network reachability. The autonomous system concept was discussed too 👑

Muuss covers the background, implementation, experience, and disparaging remarks 🙈 The design goals are:

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

The non goals (not trying to do these!) are:

  • Flexibility of topology
  • Rapid response (very slow update)
  • Adaptive routing
  • Common routing metric (no agreement at all)
  • Load sharing or splitting

"Good news travels fast and bad news travels forever." 💀 It's not for routing, it only provides reachability 🧚

RFC827 is the initial mode, and RFC888 is the stub protocol 📜

The neighbor acquisition protocol is:

  • 2-way shake
  • Flow-rates
  • Explicit acquisition/cause

The neighbor reachability protocol is:

  • Periodic polling
  • Parasitic information
  • Reachability algorithm

The network reachability protocol is:

  • Periodic pulling
  • Remote information
  • Direct and indirect neighbors
  • Indirect internal and indirect external neighbors
  • Distance information

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

The shortcomings are:

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

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

System models:

  • "Appropriate first hop" criterion
    • Not useful for implementation
    • Requires global information
    • Inadequate for verification
  • Graph models
    • N-graph shows net connectivity
    • T-graph shows system connectivity
    • T-acycloc criterion insures loop-free
  • Derived features
    • Induces spanning tree

The N-graph looks like this ✨

                                        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

The test is to ensure that there are no cycles 🔁 Then there's the spanning subtree 🌳

Specification effort: status report, and the state machine was designed 🎀

Remaining issues:

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

Congestion Control -- FACC - Nagle

Postel says this was a discussion of the situation leading to the ideas presented in RFC 896, and how the policies described there improved overall performance 📈

Muuss says the first principle of congestion control is:

DON'T DROP PACKETS (unless absolutely necessary) 🙅‍♀️

The second principle is: hosts must behave themselves (or else) 😤 The enemies list is:

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

The third principle is: memory won't help (beyond a certain point). The small packet problem: big packets are good, small are bad (big = 576) 🍓

Suggested fix: when the user writes to TCP, initiate a send only if there are NO outstanding packets on the connection (or if you fill a segment). No change when Acks come back. It's good for TELNET, at least 💕 The assumption is that there is a pipe-like buffer between the user and the TCP 🫧

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

Also: 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, and this probably won't work so well for SATNET 🛰️

There are also problems about propagation time of links biasing the validity of this result!! 😬

A Gateway Congestion Control Policy--NW Systems - Niznik

Postel says this talk was (for Postel) hard to follow 😵 There were a number of references to well known results in queuing theory etc., but he couldn't follow how they were being used 🤷‍♀️

Muuss notes:

  • 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 presentations 🙈 But there was a LOT of discussion during the breaks, at lunch, and at the end of each day 💬

Some things that occurred to Postel during the meeting, which may have been triggered by something someone said (or maybe by the view out the window) 🪟

Bestie, the open questions are a LOT 😭 but here they are, no cap 💅

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. The whole network would be screaming at you 💀

Has anyone actually worked out the routing traffic costs for GGP vs the SPF procedures for the real Internet case? 🤔 Like for real, not vibes 🧚

How is the fact that routing in the core autonomous system is cast in terms of an entry and an exit gateway gonna effect other things? 👑 Will there be special arrangements between the entry and exit gateway? Will an autonomous system basically turn into 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? 😬

MEETING ATTENDEES 💖

Here's the whole squad who showed up, iykyk 🫶

   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
📦 where this page comes from