GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:ien:ien191

Internet Experiment Note: 191 C. Sunshine

                                                              D. Cohen
                                                             J. Postel
                                                                   ISI
                                                             July 1981
                     Comments on Rosen's Memos

INTRODUCTION

 This memo comments on recent IEN's by Eric Rosen of BBN (numbers 182,
 183, 184, 187, 188, 189) [1,2,3,4,5,6].  We think these notes raise
 some important and interesting issues which require further
 discussion.  In the following we focus on the points of disagreement
 (but don't assume that we agree with something simply because we
 don't mention it here).  After a brief general comment we discuss
 each note in turn.
 There are some good points raised in this series.  Unfortunately the
 presentation is both verbose and incomplete.  There is nothing wrong
 with taking a certain aspect of a topic and exploring it at length,
 but these memos seemingly present all available alternatives and
 select the "best" for further development.  Our concern is that, in
 fact, not all alternatives are studied, and not all evaluation
 criteria are given the proper weight in selecting the "best"
 alternative.  A minor problem is the informality of the references.
 It is unclear exactly which earlier memos, reports, and papers the
 author has in mind in some of the discussion, and it is unclear if
 the author is aware of some very relevant material.  In some sections
 it appears that the author is unfamiliar with much of the relevant
 material, and hence fails to include important points in his
 presentation.

IEN 182

 This note on "Issues in Buffer Management" is, in the main, a
 description of buffer management in the ARPANET IMPs.  This is quite
 useful and should be food for thought for gateway designers and
 implementers since gateways may have some of the same constraints and
 concerns in buffer management as IMPs.  However, the differences that
 do exist in the goals for gateways and IMPs are not taken into
 account, so the policies adopted for IMPs are not necessarily
 appropriate for gateways.  Differences in the level of reliability of
 delivery, and the end-to-end virtual circuit vs. the datagram style
 of service can lead to substantial differences in the requirements
 for buffer management.
 This is a useful memo in that it exposes a good deal about the buffer
 management polices used in the ARPANET IMPs, information that is not
 easily found elsewhere.  But it is contains some weakly supported

Sunshine & Cohen & Postel Page [1]

July 1981 IEN 191 Comments on Rosen's Memos

 overly broad conclusions that seem to ignore and sometimes contradict
 existing results in this area.

IEN 183

 This memo presents a proposal for a logical addressing mechanism in
 the ARPANET, and includes a good deal of discussion of alternatives.
 Interested readers should see earlier IEN's on the subject from MIT,
 ISI, and Xerox, plus the classic paper by Shoch, and recent work on
 "naming authorities" at Xerox, which the author fails to credit or
 reference [7,8,9].
 We prefer the more commonly used term "name" to the phrase "logical
 address" which the author uses.
 The key proposal is to include a name-to-address lookup function in
 the source switches of a network so that the "user" will not have to
 supply ("physical") addresses.  This seems a worthwhile goal, but the
 meaning of "user" seems confused between (1) people or application
 programs using the network, and (2) network access software (such as
 NCP or TCP) supporting (1) in the hosts.  The author seems oblivious
 of this distinction.
 Everyone agrees that category (1) "users" should be able to use
 names.  Of course, most ARPANET hosts' category (2) software already
 provides this function (the host table) for category (1) "users".
 The proper discussion should be whether this function is best located
 in the switches, or in the network support software of the hosts, but
 this is not explicitly addressed by the author.
 The author presents a reasonable approach to implementing a name
 lookup function without requiring broadcast of dynamic changes to all
 participants.  A basic table of all potentially usable addresses for
 each name must be distributed to all parties (the "authorized"
 table), but this is expected to change relatively slowly.  Entries in
 this table are assumed usable ("effective") until an explicit
 exception message ("destination not accessable") results from using
 them.  The unusable markings are reset after a time interval.
 We agree that this is a worthwhile proposal, but the placement of
 this function in the hosts, the switches, or a separate name lookup
 service needs further discussion.  Since most hosts are already
 performing this function as noted above, it is clearly within their
 capabilities.  An advantage of placement in the switches seems to be
 prevention of "spoofing" since hosts can only send/receive messages
 from/for a specified name if that name is "authorized" for the

Page [2] Sunshine & Cohen & Postel

IEN 191 July 1981

                                             Comments on Rosen's Memos
 addresses they are physically attached to.  Of course this requires
 source and destination switches to check messages in a "trusted"
 fashion.
 There is a small inconsistency in the author's discussion of
 source-only vs. intermediate ("tandem") node name lookup.  At the top
 of page 11, it is stated that the tandem nodes will be "no more
 likely" than the source node to have new information during a
 transient update period.  However, on page 12-13, it is pointed out
 (correctly) that tandem nodes likely WILL produce a "better route
 selection ... if delay changes or topology changes take place while a
 packet is in transit."
 There will be substantial modification needed to the host software in
 order to implement this scheme.  It is proposed (we think) that both
 the current scheme and the logical address scheme be available at the
 same time.  The details of the logical address are not very clear,
 but a 16-bit logical address is suggested, which would require a
 character string to number lookup in the hosts to make it convenient.

IEN 184

 This memo claims that the previous work on the Internet is deficient
 due to reliance on an inadequate model of the structure of the
 Internet.  IEN 184 claims to present a new model of the Internet that
 does provide a basis for future work.
 The proposed model of internetwork operation views the gateways more
 explicitly as switching nodes, with the hosts attached to these
 nodes.  In particular, each host is multi-hommed on all the gateways
 on the same network as the host.
 There is some merit to this model and the questions it raises, but
 the author is not the first to think of this viewpoint (see for
 example IEN-135 [10]).  There are also some problems with this model
 that the author seems unaware of.
 This new model might be acceptable if one wanted to build a super
 ARPANET based solely on lines and super-IMPs, but if one is planning
 to include other technologies such as broadcast satellite and
 broadcast local networks, the  proposed model has serious flaws.
 For example, two hosts on the same net may still wish to use Internet
 protocols to communicate.  In the author's model, they would have to
 do so by going through an intermediate gateway on their net, since by
 definition, no hosts can communicate directly over a "Pathway" with

Sunshine & Cohen & Postel Page [3]

July 1981 IEN 191 Comments on Rosen's Memos

 no intervening "Switch."  This is clearly inefficient in the intranet
 case, and one way in which it differs from the ARPANET.  This would
 also be true in many single broadcast nets where there are no
 intervening switches between hosts even at the single network level
 of "Network Structure."
 This memo fails to consider the impact on the host systems.  Host
 will be designed to use a common approach to communication with other
 hosts whether they be across the room or across the world.  With the
 existing model and Internet Protocol, the same procedures and formats
 can be used between hosts on the same network and between hosts many
 networks apart (though different performance parameters may be
 necessary).
 The model developed in the Internet Working Group and described by
 Cerf (IEN-48 [11]) continues to be the most reasonable basis for
 developing the Internet.

IEN 187

 This memo assumes the model (of IEN 184) of hosts always sending and
 receiving internet traffic via an "Internet Switch".  It goes on to
 describe the interactions of a host and an internet switch, and then
 criticizes the existing Internet Protocol for not being a perfect
 host-switch interface protocol.
 We cannot possibly take on all of the topics and "lessons" presented,
 but Section 2.4 of IEN-187 on fragmentation provides a good example
 of what is wrong with these reports.  Again, the author seems unaware
 of previous important work on this subject, for example IEN-20 by
 Shoch (expanded and published in Computer Networks in 1979) [13], or
 the paper by Sunshine on interconnection of networks published in
 Computer Networks in 1977 [14].  If the author had read these, he
 might have avoided several serious deficiencies in his presentation:
    1. After a long discussion of the evils of final destination (or
    internet) fragmentation, the author reveals his preferred approach
    of hop-by-hop (or intranet) fragmentation as if he invented the
    idea.
    2. There is an important goal that internet fragmentation
    supports, but intranet fragmentation does not: independent and
    possibly different routing of each fragment through different exit
    gateways from a "small packet" net (and subsequently).  The author
    fails to consider this point.

Page [4] Sunshine & Cohen & Postel

IEN 191 July 1981

                                             Comments on Rosen's Memos
    3. In presenting scenarios (page 58) showing the evils of internet
    fragmentation, the author omits the important scenario of several
    small packet nets in a row, where repeated intranet fragmentation
    is just the WRONG thing to do.
    4. Packets with the Don't Fragment flag on are not "simply lost in
    transit" (page 53) if they cannot be forwarded without
    fragmentation.  Specific error packets are returned to the source
    host, which may try to resend smaller packets.
    5. After all his discussion, the author admits in the final
    paragraph that destination host fragmentation is necessary anyway
    if the final network gets too large a packet.  The author claims
    this will be necessary only for hosts on nets with "unusually
    small" maximum packet sizes, but in fact it will be necessary on
    all nets with less than the maximum maximum packet size of any net
    in the system if they wish to receive packets from the largest
    packet size nets.
 The net effect of this sort of incomplete presentation is a step
 backward from the current imperfect level of understanding of this
 important issue.
 The author also attacks the Type of Service (TOS), Time to Live
 (TTL), Source Routing (SR), Flow Control (FC), and Fault Isolation
 (FI) features of IP and ICMP.
 On Type of Service the author tells us for ten pages all the bad
 things about the Internet Protocol provision for TOS, while agreeing
 it is an important concept, but has nothing different to offer,
 except some vague notion that service catagories should correspond
 more closely to application types.
 On Time to Live the author complains that there is an inconsistency
 since the TTL is stated to be in seconds, and that the gateways must
 decrement the TTL by one, and that the gateways are expected to
 process datagrams faster than one a second.  If one assumes that the
 intention is to guarantee that datagrams stay alive as long as the
 TTL, he is right.  But the intention is really to guarantee that they
 disappear before TTL.  So TTL is an upper bound on how long the
 datagram may exist.  Most reliable transport protocols assume a
 maximum datagram lifetime (sometimes unknowningly) for the correct
 operation of their reliability procedures [15].
 On Source Routing the author suggests that this feature exists due
 only to problems with existing routing procedures and for

Sunshine & Cohen & Postel Page [5]

July 1981 IEN 191 Comments on Rosen's Memos

 experiments, and that any really adequate routing procedure in the
 gateways will eliminate the need for source routing in normal
 operations.  We suggest that the Internet will be a much more dynamic
 environment than the author has yet imagined and that source routing
 will be essential to reach through the Internet to local environments
 not fully integrated into the main Internet routing world.
 On Flow Control and Fault Isolation the author indicates that the
 current mechanisms are inadequate, but does not suggest workable
 alternatives.  On FC the ICMP "Source Quench" message is cited as a
 case of "choke packet" flow control which the author does not believe
 in (page 64).  Earlier (page 63) the author complains that "source
 quench" is only advisory, and later (page 66) the author makes vague
 suggestions that a better flow control scheme would use advisory
 messages to suggest that datagrams had been discarded (exactly what
 source quench does).
 All in all this memo comes across as an attack on the Internet
 Protocol, with few suggestions for improvement.  But it is based on
 an assumption:  that the Internet Protocol is a host-switch access
 protocol.  This assumption requires further discussion.

IEN 188

 This memo describes logical addressing in the Internet, primarily by
 recasting the method of IEN 183 in generalized terms.  There are a
 number of inaccuracies and omissions in the discussion.  One serious
 limitation is failure to consider the case of hosts sending Internet
 datagrams to each other directly on a single net as discussed above.
 On page 4 (middle), the author correctly states that IP addresses are
 hierarchical, but incorrectly states that their second component is
 necessarily a "physical address."  In fact, it may be a name or
 "logical address" in networks that provide that capability (but must
 be carried in 24 bits).
 On page 7, the author proposes using a "unique name which is
 meaningful at each level of internet hierarchy."  This seems to be a
 strong violation of layering, and as the author admits, would require
 the switches in every constituent network to "understand" and be able
 to lookup the names, probably an intolerable demand on individual
 network autonomy.
 On page 34, the author's claim that hierarchical addressing requires
 less table space than flat addressing is false.  His justification is
 incomprehensible to us, particularly since he has just finished

Page [6] Sunshine & Cohen & Postel

IEN 191 July 1981

                                             Comments on Rosen's Memos
 proposing an "area" addressing scheme similar to hierarchical schemes
 in order to reduce table sizes!
 In the detailed model of operation given in Section 3.4, an important
 step is omitted when the first sentence states, "Let's assume that a
 source Host has given a message to a source Switch ..."  How does the
 source host pick the source switch?  In fact, it must pick both a
 network level (e.g., IMP) and internet level (gateway) switch,
 assuming it is multi-homed, which at least at the internet level is
 quite likely.  In order to make this selection, the host will have to
 have a table giving the best switch (at each level) for each possible
 destination name.  But these are precisely the sort of tables the
 author's scheme is meant to avoid having in the hosts.  In light of
 the comment above about hosts talking to each other directly on the
 same net, the hosts must at least know the names and addresses of
 every other host on their own net.
 The treatment of mobile hosts is quite brief and offers no
 improvement over previously proposed solutions.

IEN 189

 This memo discusses routing in the Internet, and proposes that the
 existing gateway routing procedure be replaced by the SFP procedure
 now used in the ARPANET.  This is surely a useful suggestion.  The
 note does however raise a number of issues in its examples of routing
 problems that indicate an incomplete understanding of the whole area.
 The note proposes a "gateway discovery protocol" that could be
 provided by individual nets.  This idea seems worthwhile, although it
 is not clear how many individual nets would be willing to make such
 additions.  We should like to point out that it is also possible to
 perform this function directly among gateways in networks which
 support broadcast or group addressing.
 The discussion of routing alternatives makes generally sound if
 qualitative conclusions, but a few details are confused.  The
 discussion of throughput performance on page 41 assumes TCP will
 operate with a small enough window over a high delay path so that
 throughput is reduced, but this is precisely the situation in which
 proper "tuning" requires a large window, which would allow high
 throughput.
 The analogy with "whole picture" algorithms on pages 44-45 fails to
 mention that in the whole picture scenario, each person would have to
 get a piece of paper 100 times bigger than with the local scheme, and

Sunshine & Cohen & Postel Page [7]

July 1981 IEN 191 Comments on Rosen's Memos

 hence this approach has an information distribution requirement that
 is much higher.
 This memo contains several informal citations that could be usefully
 spelled out for the IEN audience.  The author mentions algorithms by
 Gallager (page 17), Dijkstra (page 20), and Floyd (page 20), all
 without references.  It is safe to say that any list of references
 containing only the author and his coworkers (as consistently done in
 this series) cannot be adequate.
 One particular example provokes the following response:
    Please replace the second paragraph of page 49 of IEN-189 with the
    following paragraph:
       "In fact the situation could be even worse.  If Switches in
       Boston know nothing about what happening inside the building on
       4676 Admiralty Way then data for the North section of the 11th
       floor which arrives at the South section of the 11th floor is
       then sent back from the South section to Boston for alternate
       routing will just loop back to the South section.  The data
       will be stuck in an infinite loop, never reaching its
       destination.  In IEN 179 [12] Danny Cohen proposed a regional
       scheme like this, apparently not realizing that it suffers from
       loops.  His proposal also includes a form of hierarchical
       addressing which is closely bound up with routing, so that a
       Switch is Boston might not even be able to distinguish data for
       the South section from data for the North section.  That is, in
       Cohen's scheme, data for the South section and data for the
       North section would be indistinguishable at the Boston
       Switches; all such data would appear to be addressed to the
       South section.  Only the Switches at the South section would
       look further down the address hierarchy to determine whether
       the data needs further forwarding to the North section.  Any
       such scheme is hopelessly loop-prone, except in a Network
       Structure whose connectivity is extraordinarily rich, much more
       so than the Catenet's will ever be."
    Since the above suggestion was merely to follow the routing
    strategy used by the phone companies, TELENET and others, you
    should warn them immediately about this hopelessly loop-prone
    situation.
    I believe that if the Boston Switch has ALL the information about
    EVERYthing, EVERYwhere it would be in position to make better
    decisions, ALWAYS, especially if that information is updated with

Page [8] Sunshine & Cohen & Postel

IEN 191 July 1981

                                             Comments on Rosen's Memos
    absolutely ZERO time delay.  If this information is absolutely
    free (in terms of communication, storage and processing) it may be
    dumb not to make every Switch always know everything about
    everything, down to (or "up to"?) the finest granularity
    (location? site? process? file? register? bit?). However, if this
    is not absolutely free, some compromises may have to take place.
    Oh, one point which I did not quite follow: why if the
    Nevada/California lines are broken forever, Boston is never told
    about it - as described by you?  By the way, what made you
    understand that the "The Switch at Nevada would look further down
    the address hierarchy to determine whether the data needs further
    forwarding to California" ?
    I highly recommend that you get hold of any telephone directory
    and read the area-codes tables.  This may help you understanding
    that the California area codes are neither above, nor below, nor
    further on any hierarchy than the Nevada ones, and vice versa.
    This is a very subtle point which may escape the casual reader.
    Mastering this idea may help you understand what IEN-179 is all
    about. In short, IEN-179 is not an attempt to describe the ideas
    which you have in mind by using the telephone scenario, but an
    attempt (which obviously failed, at least in your case) to
    introduced old well-proven ideas from other communication arenas
    into ours.

SUMMARY

 In summary we are glad to have this information and these opinions
 presented for discussion in the Internet Working Group, and we hope
 that others will speak up with their opinions too.  We are concerned
 that too many will be so overwhelmed by the wide ranging arguments to
 notice that some important considerations were not mentioned.
 We especially want to make clear that a fundamentally different model
 of the Internet architecture is proposed by Rosen, and that we have
 serious reservations about aspects of that model.

Sunshine & Cohen & Postel Page [9]

July 1981 IEN 191 Comments on Rosen's Memos

REFERENCES

 [1]  Rosen, E., "Issues in Buffer Management", IEN 182, Bolt Beranek
      and Newman, May 1981.
 [2]  Rosen, E., "Logical Addressing", IEN 183, Bolt Beranek and
      Newman, May 1981.
 [3]  Rosen, E., "Issues in Internetting Part 1: Modelling the
      Internet", IEN 184, Bolt Beranek and Newman, May 1981.
 [4]  Rosen, E., "Issues in Internetting Part 2: Accessing the
      Internet", IEN 187, Bolt Beranek and Newman, June 1981.
 [5]  Rosen, E., "Issues in Internetting Part 3: Addressing", IEN 188,
      Bolt Beranek and Newman, June 1981.
 [6]  Rosen, E., "Issues in Internetting Part 4: Routing", IEN 189,
      Bolt Beranek and Newman, June 1981.
 [7]  Clark, D., "A Proposal for Addressing and Routing in the
      Internet", IEN 46, MIT/Laboratory for Computer Science, June
      1978.
 [8]  Cerf, V., "Internet Addressing and Naming in a Tactical
      Environment", IEN 110, Information Processing Techniques Office,
      Defense Advanced Research Projects Agency, August 1979.
 [9]  Shoch, J., "Inter-Network Naming, Addressing, and Routing",
      Proceedings 17th IEEE Computer Society International Conference,
      pp72-79, September 1978.
 [10] Sunshine, C., "Addressing Mobile Hosts in the ARPA Internet
      Environment", IEN 135, USC/Information Sciences Institute, March
      1980.
 [11] Cerf, V., "The Catenet Model for Internetworking", IEN 48,
      Information Processing Techniques Office, Defense Advanced
      Research Projects Agency, July 1978.
 [12] Cohen, D., "Addressing and Routing", IEN 179, USC/Information
      Sciences Institute, March 1981.
 [13]  Shoch, J., "Packet Fragmentation in Inter-Network Protocols",
      Computer Networks, V.3, N.1, pp3-8, February 1979.

Page [10] Sunshine & Cohen & Postel

IEN 191 July 1981

                                             Comments on Rosen's Memos
 [14]  Sunshine, C., "Interconnection of Computer Networks", Computer
      Networks, V.1, N.3, pp175-195, January 1977.
 [15]  Watson, R., "Timer-Based Mechanisms in Reliable Transport
      Protocol Connection Management", Computer Networks, V.5, N.1,
      pp47-56, February 1981.

Sunshine & Cohen & Postel Page [11]

/data/webs/external/dokuwiki/data/pages/rfc/ien/ien191.txt · Last modified: 2001/06/25 20:58 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki