rfc875.txt

RFC 的详细文档！

          Functionality mismatch is not, of course, limited to
     Host-Host protocols.  Indeed, the following interesting situation
     was observed at University College London:  In their "Terminal
     Gateway", which translates/maps ARPANET Telnet and "Triple X"
     (CCITT X.25, X.28, X.29), they were able to get data across, as
     might be expected, but only one option (echoing), which is rather
     worse than might be expected.  (And the UCL people are quite
     competent, so the problem almost certainly doesn't have to do
     with inadequate ingenuity.)

          It could be argued that the real problem with Expedite Data
     and Triple X is that some protocol sets are a lot worse than
     others.  I wouldn't dispute that.  But it's still the case, to
     re-use a Great Network One-liner, that:

                   sometimes, when you try to turn an apple into an
                   orange, you get back a lemon.

          Nor is the likelihood of encountering irresolvable
     functionality  mismatches the only technical shortcoming of
     Translating/Mapping Gateways.  A somewhat subtle but rather
     fascinating point arises if we ask what happens when traffic is
     heavy enough to warrant more than one T/MG between a given pair
     of protocol-incompatible nets (or even if we'd like to add some
     reliability, regardless of traffic).  What happens, if we think
     about it a little, is a big problem.  Suppose you actually could
     figure out a way to translate/map between two given sets of
     protocols.  That would mean that for each logical connection you
     had open, you'd have a wealth of state information about it for
     each net you were gatewaying.  But "you" now stand revealed as a
     single T/MG -- and your clone next door doesn't have that state
     information, so any logical connection that started its life with
     you has to spend its life with you, in a state of perpetual
     monogamy, as it were.  Naturally, this epoxied pair-bonding could
     perhaps be dealt with by still another new protocol between
     T/MG's, but it's abundantly clear that there will be no easy
     analogue to no-fault divorce.  That is, to put it less
     metophorically, it becomes at best extremely complex to do
     translating/mapping at more






                                     4
     RFC 875                                            September 1982


     than one T/MG for the same logical connection.  As with the
     broader issue of reconciling given protocol sets at all, doing so
     at multiple loci of control may or may not turn out to be
     feasible in practice and certainly will be a delicate and complex
     design task.

          One more NCP/TCP problem:  When sending mail on an NCP-based
     net, the mail (actually, File Transfer) protocol currently only
     uses the addressee's name, because the Host was determined by the
     Host-Host Protocol.  If you're trying to get mail from an
     NCP-based net to a TCP-based net, though, you're back in the Host
     addressing bind already discussed.  If you don't want to change
     NCP (which, after all, is being phased out), you have to do
     something at the process level.  You can, but the "Simple Mail
     Transfer Protocol" to do it takes 62 pages to specify in ARPANET
     Request for Comments 788.

          If things get that complicated when going from NCP to TCP,
     where there's a close evolutionary link between the Host-Host
     protocols, and the process-level protocols are nominally the
     same, what happens when you want to go from DECNET, or from SNA,
     or from the as-yet incomplete NBS or ISO protocol sets?  There
     may or may not turn out to be any aspects that no amount of
     ingenuity can reconcile, but it's abundantly clear that
     Translating/Mapping Gateways are going to have to be far more
     powerful systems than IP Gateways (which are what you use if both
     nets use the same protocol sets above the Host to Comm Subnet
     Processor protocol).  And you're going to need a different T/MG
     for each pair of protocol sets.  And you may have to tinker with
     CSNP internals....  An analogy to the kids' game of Telephone (or
     Gossip) comes to mind:  How much do you lose each time you
     whisper to your neighbor who in turn whispers to the next
     neighbor?  What, for that matter, if we transplant the game to
     the United Nations and have the whisperers be translators who
     have speakers of different languages on each side?

          Other problem areas could be adduced.  For example, it's
     clear that interpreting two protocol sets rather than one would
     take more time, even if it could be done.  Also, it should be
     noted that the RFNM's Problem generalizes into a concern over
     resolving Flow Control mismatches for any pair of protocol sets,
     and could lead to the necessity of having more memory for buffers
     on the T/MG than on any given Host even for those cases where
     it's doable in principle. But only one other problem area seems
     particularly major, and that is the old Moving Target bugaboo:
     For when any protocol changes, so must all the T/MG's involving
     it, and as there have already been three versions of SNA,
     presumably a like number of versions of DECNET, and as there are
     at least two additional levels which ISO should be acknowledging
     the existence of, the fear of having to re-do T/MG's should serve
     as a considerable deterrent to doing them




                                     5
     RFC 875                                            September 1982


     in the first place.  (This apparent contravention of the
     Padlipsky's Law to the effect that Implemented Protocols Have
     Barely Finite Inertia Of Rest is explained by a brand-new
     Padlipsky's Law:  To The Technologically Naive, Change Equals
     Progress; To Vendors, Change Equals Profit.)

          At any rate, it's just not clear that a given Translating/
     Mapping Gateway can even be built; you have to look very closely
     at the protocol sets in question to determine even that.  It's
     abundantly clear that if a given one can be built it won't be
     easy to do (see Figure 3).  Yet "system architect" after "system
     architect", apparently in good faith, toss such things into their
     block diagrams.  Assuming that the architectural issue isn't
     resolved by a fondness for the Gothic in preference to the more
     modern view that form should follow function, let's pause briefly
     to visualize an immense, turreted, crenellated, gargoyled  ...
     microprocessor, and return to the question of why this sort of
     thing happens.

          It's clear that buzzwording is a factor.  After all, "system
     architects" in our context are usually employees of contractors
     and their real role in life is not to build more stately mansions
     but to get contracts, so it's not surprising to find appeal to
     the sort of salesmanship that relies more heavily on fast patter
     than precision. Another good analogy: I once went to one of the
     big chain electronics stores in response to an ad for a cassette
     recorder that "ran on batteries or house current" for $18, only
     to find that they wanted an additional $9 for the (outboard) AC
     adaptor.  Given the complexities of T/MG's, however, in our case
     it's more like an $18 recorder and a $36 adaptor.

          But is buzzwording all there is?  Clearly not, for as
     mentioned earlier there's also ignorance of the Oral Tradition in
     play. Whether the ignorance is willful or not is probably better
     left unexamined, but if we're willing to entertain the notion
     that it's not all a bait-and-switch job akin to the
     separately-priced AC adaptor, we see that those who casually
     propose T/MG's haven't done enough homework as to the real state
     of the art.
















                                     6
     RFC 875                                            September 1982


          What ever became of that early reference to The Relevant
     Literature, though?  Surely you didn't think I'd never ask.  The
     answers are both implied in the assertion that:

                          Gateways are Heffalumps

     as you'll plainly see once you've been reminded of what
     Heffalumps are.  Dipping into The Relevant Literature, then,
     let's reproduce the opening of the Heffalumps story:

                  One day, when Christopher Robin and Winnie-the-Pooh
             and Piglet were all talking together, Christopher Robin
             finished the mouthful he was eating and said carelessly:
             "I saw a Heffalump today, Piglet."
                  "What was it doing?"  asked Piglet.
                  "Just lumping along," said Christopher Robin.
             "I don't think it saw me."
                  "I saw one once," said Piglet. "At least, I think
             I did," he said.  "Only perhaps it wasn't."
                  "So did I," said Pooh, wondering what a Heffalump
             was like.
                  "You don't often see them," said Christopher Robin
             carelessly.
                  "Not now," said Piglet.
                  "Not at this time of year," said Pooh.
                  Then they all talked about something else, until it
             was time for Pooh and Piglet to go home together.

          (To satisfy the lazy reader -- who'd actually be better off
     searching for it in both -- it's from Winnie-the Pooh, not The House  at
     Pooh Corner.)

          Pooh, in case you still don't recall, decides to make a Heffalump
     Trap.  (Piglet is sorry he didn't think of it first.)  He baits it with
     a jar of honey, after making sure that it really was honey all the way
     to the bottom, naturally.  In the middle of the night, he goes to the
     Trap to get what's left of the honey and gets his head stuck in the jar.
     Along comes Piglet, who sees this strange creature with a jar-like head
     making frightful noises, and, having known no more than Pooh what
     Heffalumps really were, assumes that a Heffalump has indeed been Trapped
     and is duly terrified.














                                     7
     RFC 875                                            September 1982


          It would probably be too moralistic to wonder how much Christopher
     Robin actually knew about Heffalumps in the first place. The
     "Decorator", based on the picture on page 60 of my edition, clearly
     thinks C.R. thought they were elephants, but I still wonder. At best,
     though, he knew no more about them than the contractor did about
     Gateways in the proposal that started this whole tirade off.

          NOTE:  FIGURE 1.  Defining Characteristic of All Flavors of
     Gateways, FIGURE 2.  Gateway and Translating/Mapping Gateway,
     Approximately to Scale, and FIGURE 3.  Respective Internals Schematics,
     may be obtained by writing to:  Mike Padlipsky, MITRE Corporation, P.O.
     Box 208, Bedford, Massachusetts, 01730, or sending computer mail to
     Padlipsky@ISIA.

          








































                                     8