GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1385

Network Working Group Z. Wang Request for Comments: 1385 University College London

                                                         November 1992
                EIP: The Extended Internet Protocol
         A Framework for Maintaining Backward Compatibility

Status of this Memo

 This memo provides information for the Internet community. It does
 not specify an Internet standard. Distribution of this memo is
 unlimited.

Summary

 The Extended Internet Protocol (EIP) provides a framework for solving
 the problem of address space exhaustion with a new addressing and
 routing scheme, yet maintaining maximum backward compatibility with
 current IP. EIP can substantially reduce the amount of modifications
 needed to the current Internet systems and greatly ease the
 difficulties of transition. This is an "idea" paper and discussion is
 strongly encouraged on Big-Internet@munnari.oz.au.

Introduction

 The Internet faces two serious scaling problems: address exhaustion
 and routing explosion [1-2]. The Internet will run out of Class B
 numbers soon and the 32-bit IP address space will be exhausted
 altogether in a few years time.  The total number of IP networks will
 also grow to a point where routing algorithms will not be able to
 perform routing based a flat network number.
 A number of short-term solutions have been proposed recently which
 attempt to make more efficient use of the the remaining address space
 and to ease the immediate difficulties [3-5].  However, it is
 important that a long term solution be developed and deployed before
 the 32-bit address space runs out.
 An obvious approach to this problem is to replace the current IP with
 a new internet protocol that has no backward compatibility with the
 current IP. A number of proposals have been put forward: Pip[7],
 Nimrod [8], TUBA [6] and SIP [14].  However, as IP is really the
 cornerstone of the current Internet, replacing it with a new "IP"
 requires fundamental changes to many aspects of the Internet system
 (e.g., routing, routers, hosts, ARP, RARP, ICMP, TCP, UDP, DNS, FTP).
 Migrating to a new "IP" in effect creates a new "Internet".  The

Wang [Page 1] RFC 1385 EIP November 1992

 development and deployment of such a new "Internet" would take a very
 large amount of time and effort. In particular, in order to maintain
 interoperability between the old and new systems during the
 transition period, almost all upgraded systems have to run both the
 new and old versions in parallel and also have to determine which
 version to use depending on whether the other side is upgraded or
 not.
 Let us now have a look at the detailed changes that will be required
 to replace the current IP with a completely new "IP" and to maintain
 the interoperability between the new and the old systems.
 1) Border Routers: Border routers have to be upgraded and to provide
    address translation service for IP packets across the boundaries.
    Note that the translation has to be done on the outgoing IP
    packets as well as the in-coming packets to IP hosts.
 2) Subnet Routers: Subnet Routers have to be upgraded and have to
    deal with both the new and the old packet formats.
 3) Hosts: Hosts have to be upgraded and run both the new and the
    old protocols in parallel. Upgraded hosts also have to determine
    whether the other side is upgraded or not in order to choose the
    correct protocol to use.
 4) DNS: The DNS has to be modified to provide mapping for domain
    names and new addresses.
 5) ARP/RARP: ARP/RARP have to be modified, and upgraded hosts and
    routers have to deal with both the old and new ARP/RARP packets.
 6) ICMP: ICMP has to be modified, and the upgraded routers have to
    be able to generate both both old and new ICMP packets.  However,
    it may be impossible for a backbone router to determine
    whether the packet comes from an upgraded host or an IP host but
    translated by the border router.
 7) TCP/UDP Checksum: The pseudo headers may have to be modified to
    use the new addresses.
 8) FTP: The DATA PORT (PORT) command has to be changed to pass new
    addresses.
 In this paper, we argue that an evolutionary approach can extend the
 addressing space yet maintain backward compatibility.  The Extended
 Internet Protocol (EIP) we present here can be used as a framework by
 which a new routing and addressing scheme may solve the problem of
 address exhaustion yet maintain maximum backward compatibility to

Wang [Page 2] RFC 1385 EIP November 1992

 current IP.
 EIP has a number of very desirable features:
 1) EIP allows the Internet to have virtually unlimited number of
    network numbers and over 10**9 hosts in each network.
 2) EIP is flexible to accommodate most routing and addressing
    schemes, such as those proposed in Nimrod [8], Pip [7], NSAP [9]
    and CityCodes [10]. EIP also allows new fields such as Handling
    Directive [7] or CI [11] to be added.
 3) EIP can substantially reduce the amount of modifications to
    current systems and greatly ease the difficulties in transition.
    In particular, it does not require the upgraded hosts and subnet
    routers to run two set of protocols in parallel.
 4) EIP requires no changes to all assigned IP addresses and subnet
    structures in local are networks.  and requires no modifications
    to ARP/RARP, ICMP, TCP/UDP checksum.
 5) EIP can greatly ease the difficulties of transition.  During the
    transition period, no upgrade is required to the subnet routers.
    EIP hosts maintain full compatibility with IP hosts within the
    same network, even after the transition period.  During the
    transition period, IP hosts can communicate with any hosts in
    other networks via a simple translation service.
 In the rest of the paper, IP refers to the current Internet Protocol
 and EIP refers to the Extended Internet Protocol (EIP is pronounced
 as "ape" - a step forward in the evolution :-).

Extended Internet Protocol (EIP)

 The EIP header format is shown in Figure 1 and the contents of the
 header follows.

Wang [Page 3] RFC 1385 EIP November 1992

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version|  IHL  |Type of Service|          Total Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Identification        |Flags|      Fragment Offset    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Time to Live |    Protocol   |         Header Checksum       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Source Host Number                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Destination Host Number                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     EIP ID    | EIP Ext Length|   EIP Extension (variable)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 1: EIP Header Format
 Version:  4 bits
   The Version field is identical to that of IP. This field is set
   purely for compatibility with IP hosts. It is not checked by EIP
   hosts.
 IHL:  4 bits
   Internet Header Length is identical to that of IP. IHL is set to
   the length of EIP header purely for compatibility with IP. This
   field is not checked by EIP hosts.  see below the EIP Extension
   Length field for more details)
 Type of Service:  8 bits
   The ToS field is identical to that of IP.
 Total Length:  16 bits
   The Total Length field is identical to that of IP.
 Identification:  16 bits
   The Identification field is identical to that of IP.
 Flags:  3 bits
   The Flags field is identical to that of IP.

Wang [Page 4] RFC 1385 EIP November 1992

 Fragment Offset:  13 bits
   The Fragment Offset field is identical to that of IP.
 Time to Live:  8 bits
   The Time to Live field is identical to that of IP.
 Protocol:  8 bits
   The Protocol field is identical to that of IP.
 Header Checksum:  16 bits
   The Header Checksum field is identical to that of IP.
 Source Host Number:  32 bits
   The Source Host Number field is used for identifying the
   source host but is unique only within the source network
   (the equivalent of the host portion of the source IP address).
 Destination Host Number:  32 bits
   The Destination Host Number field is used for identifying the
   destination host but is unique only within the destination network
   (the equivalent of the host portion of the destination IP address).
 EIP ID: 8 bits
   The EIP ID field equals to 0x8A. The EIP ID value is chosen
   in such a way that, to IP hosts and IP routers, an EIP appears
   to be an IP packet with a new IP option of following parameters:
     COPY CLASS NUMBER LENGTH DESCRIPTION
     ---- ----- ------ ------ -----------
       1    0     TBD    var
     Option:  Type=TBD
 EIP Extension Length: 8 bits
      The EIP Extension Length field indicates the total length
      of the EIP ID field, EIP Extension Length field and the
      EIP Extension field in octets. The maximum length that the
      IHL field above can specify is 60 bytes, which is considered
      too short in future. EIP hosts actually use the EIP Extension
      Length field to calculate the total header length:

Wang [Page 5] RFC 1385 EIP November 1992

   The total header length = EIP Extension Length + 20.
   The maximum header length of an EIP packet is then 276 bytes.
 EIP Extension: variable
   The EIP Extension field holds the Source Network Number,
   Destination Network Number and other fields. The format
   of the Extension field is not specified here. In its simplest
   form, it can be used to hold two fixed size fields as the
   Source Network Number and Destination Network Number as the
   extension to the addressing space. Since the Extension
   field is variable in length, it can accommodate almost any
   routing and addressing schemes. For example, the Extension
   field can be used to hold "Routing Directive" etc specified
   in Pip [7] or "Endpoint IDs" suggested in Nimrod [8], or the
   "CityCode" [10]. It can also hold other fields such as the
   "Handling Directive" [7] or "Connectionless ID" [11].
 EIP achieves maximum backward compatibility with IP by making the
 extended space appear to be an IP option to the IP hosts and routers.
 When an IP host receives an EIP packets, the EIP Extension field is
 safely ignored as it appears to the IP hosts as an new, therefore an
 unknown, IP option.  As a result, there is no need for translation
 for in-coming EIP packets destined to IP hosts and there is also no
 need for subnet routers to be upgraded during the transition period
 see later section for more details).
 EIP hosts or routers can, however, determine whether a packet is an
 IP packet or an EIP packet by examining the EIP ID field, whose
 position is fixed in the header.
 The EIP Extension field holds the Source and Destination Network
 Numbers, which are only used for communications between different
 networks. For communications within the same network, the Network
 Numbers may be omitted. When the Extension field is omitted, there is
 little difference between an IP packet and an EIP packet.  Therefore,
 EIP hosts can maintain completely compatibility with IP hosts within
 one network.
 In EIP, the Network Numbers and Host Numbers are separate and the IP
 address field is used for the Host Number in EIP. There are a number
 of advantages:
 1) It maintains full compatibility between IP hosts and EIP hosts
    for communications within one network.  Note that the Network
    Number is not needed for communications within one network. A

Wang [Page 6] RFC 1385 EIP November 1992

    host can omit the Extension field if it does not need any other
    information in the Extension field, when it communicates with
    another host within the same network.
 2) It allows the IP subnet routers to route EIP packet by treating
    the Host Number as the IP address during the transition period,
    therefore the subnet routers are not required to be updated
    along the border routers.
 3) It allows ARP/RARP to work with both EIP and IP hosts without
    any modifications.
 4) It allows the translation at the border routers much easier.
    During the transition period when the IP addresses are still
    unique, the network portion of the IP addresses can be directly
    extracted and mapped to EIP Network Numbers.

Modifications to IP Systems

 In this section, we outline the modifications to the IP systems that
 are needed for transition to EIP. Because of the similarity between
 the EIP and IP, the amount of modifications needed to current systems
 are substantially reduced.
 1) Network Numbers: Each network has to be assigned a new EIP Network
    Number based on the addressing scheme used. The mapping
    between the IP network numbers and the EIP Network Numbers can
    be used for translation service (see below).
 2) Host Numbers: There is no need for assigning EIP Host Numbers.
    All existing hosts can use their current IP addresses as their
    EIP Host Numbers. New machines may be allocated any number from
    the 32-bit Host Number space since the structure posed on IP
    addressing is no longer necessary. However, during the transition,
    allocation of EIP Host Numbers should still follow the IP
    addressing rule, so that the EIP Host Numbers are still globally
    unique and can still be interpreted as IP addresses.  This will
    allow a more gradual transition to EIP (see below).
 3) Translation Service: During the transition period when the EIP
    Host Numbers are still unique, an address translation service
    can be provided to IP hosts that need communicate with hosts in
    other networks cross the upgraded backbone networks.  The
    translation service can be provided by the border routers.  When a
    border router receives an IP packet, it obtains the Destination
    Network Number by looking up in the mapping table between IP
    network numbers and EIP Network Numbers. The border router then
    adds the Extension field with the Source and Destination Network

Wang [Page 7] RFC 1385 EIP November 1992

    Numbers into the packet, and forwards to the backbone networks.
    It is only necessary to translate the out-going IP packets to
    the EIP packets.  There is no need to translate the EIP packets
    back to IP packets even when they are destined to IP hosts.
    This is because that the Extension field in the EIP packets
    appears to IP hosts just an unknown IP option and is ignored by
    the IP hosts during the processing.
 4) Border Routers: The new EIP Extension has to be implemented and
    routing has to be done based on the Network Number in the EIP
    Extension field. The border routers may have to provide the
    translation service for out-going IP packets during the transition
    period.
 5) Subnet Routers: No modifications are required during the transition
    period when EIP Host Numbers (which equals to the IP
    addresses) are still globally unique. The subnet routing is carried
    out based on the EIP Host Numbers and when the EIP Host
    IDs are still unique, subnet routers can determine, by treating
    the EIP Host Number as the IP addresses, whether a packet is
    destined to remote networks or not and forward correctly. The
    Extension field in the EIP packets also appear to the IP subnet
    routers an unknown IP option and is ignored in the processing.
    However, subnet routers eventually have to implement the EIP
    Extension and carry out routing based on Network Numbers when
    EIP Host Numbers are no longer globally unique.
 6) Hosts: The EIP Extension has to be implemented.  routing has to
    be done based on the Network Number in the EIP Extension field,
    and also based on the Host Number and subnet mask if subnetting
    is used. IP hosts may communication with any hosts within the
    same network at any time. During the transition period when the
    EIP Host Numbers are still unique, IP hosts can communicate with
    any hosts in other network via the translation service.
 7) DNS: A new resource record (RR) type "N" has to be added for EIP
    Network Numbers. The RR type "A", currently used for IP
    addresses, can still be used for EIP Host Numbers. RR type "N"
    entries have to be added and RR type "PTR" to be updated.  All
    other entries remain unchanged.
 8) ARP/RARP: No modifications are required. The ARP and RARP are
    used for mapping between EIP Host Numbers and physical
    addresses.
 9) ICMP: No modifications are required.
 10) TCP/UDP Checksum: No modifications are required. The pseudo

Wang [Page 8] RFC 1385 EIP November 1992

     header includes the EIP Source and Destination IDs instead of
     the source and destination IP addresses.
 11) FTP: No modifications are required during the transition period
     when the IP hosts can still communicate with hosts in other
     networks via the translation service. After the transition period,
     however, the "DATA Port (Port)" command has to be modified to
     pass the port number only and ignore the IP address.  A new FTP
     command may be created to pass both the port number and the EIP
     address to allow a third party to be involved in the file
     transfer.

Transition to EIP

 In this section, we outline a plan for transition to EIP.
 EIP can greatly reduce the complexity of transition. In particular,
 there is no need for the updated hosts and subnet routers to run two
 protocols in parallel in order to achieve interoperability between
 old and new systems.  During the transition, IP hosts can still
 communicate with any machines in the same network without any
 changes.  When the EIP Host Numbers (i.e., the 32-bit IP addresses)
 are still globally unique, IP hosts can contact hosts in other
 networks via translation service provided in the border routers.
 The transition goes as follows:
 Phase 0:
      a) Choose an addressing and routing scheme for the Internet.
      b) Implement the routing protocol.
      c) Assign new Network Numbers to existing networks.
 Phase 1:
      a) Update all backbone routers and border routers.
      b) Update DNS servers.
      c) Start translation service.
 Phase 2:
      a) Update first the key hosts such as mail servers, DNS servers,
      FTP servers and central machines.
      b) Update gradually the rest of the hosts.
 Phase 3:
      a) Update subnet routers
      b) Withdraw the translation service.
 The translation service can be provided as long as the Host IDs
 (i.e., the 32-bit IP address) are still globally unique. When the IP

Wang [Page 9] RFC 1385 EIP November 1992

 address space is exhausted, the translation service will be withdrawn
 and the remaining IP hosts can only communicate with hosts within the
 the same network. At the same time, networks can use any numbers in
 the 32-bit space for addressing their hosts.

Related Work

 A recent proposal called IPAE by Hinden and Crocker also attempts to
 minimize the modifications to the current IP system yet to extend the
 addressing space [12]. IPAE uses encapsulation so that the extended
 space is carried as IP data. However, it has been found that the 64
 bits IP data returned by an ICMP packet is too small to hold the
 Global IP addresses. Thus, when a router receives an ICMP generated
 by an old IP host, it is not able to convert it into a proper ICMP
 packet. More details can be found in [13].

Discussions

 EIP does not necessary increase the header length significantly as
 most of the fields in the current IP will be still needed in the new
 internet protocol. There are debates as to whether fragmentation and
 header checksum are necessary in the new internet protocol but no
 consensus has been reached.
 EIP assumes that IP hosts and routers ignore unknown IP option
 silently as required by [15,16].  Some people have expressed some
 concerns as to whether current IP routers and hosts in the Internet
 can deal with unknown IP options properly.
 In order to look into the issues further, we carried out a number of
 experiments over the use of IP option. We selected 35 hosts over 30
 countries across the Internet. A TCP test program (based on ttcp.c)
 then transmitted data to the echo port (tcp port 7) of each of the
 hosts. Two tests were carried out for each host, one with an unknown
 option (type 0x8A, length 40 bytes) and the other without any
 options.
 It is difficult to ensure that the conditions under which the two
 tests run are identical but we tried to make them as close as
 possible. The two tests (test-opt and test-noopt) run on the same
 machine a Sun4) in parallel, i.e., "test-opt& ; test-noopt&" and then
 again in the reverse order, i.e., "test-noopt& ; test-opt&", so each
 test pair actually run twice.  Each host was ping'ed before the tests
 so that the domain name information was cached before the name
 lookup.
 The experiments were carried out at three sites: UCL, Bellcore and
 Cambridge University. The tcp echo throughput (KB/Sec) results are

Wang [Page 10] RFC 1385 EIP November 1992

 listed in Appendix.
 The results show that the IP option was dealt with properly and there
 is no visible performance difference under the test setup.

References

 [1] Chiappa, N., "The IP Addressing Issue", Work in Progress, October
     1990.
 [2] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby,
     "Towards the Future Architecture", RFC 1287, MIT, BBN, CNRI, ISI,
     UCDavis , December 1991.
 [3] Solensky, F. and F. Kastenholz, "A Revision to IP Address
     Classifications", Work in Progress, March 1992.
 [4] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an
     Address Assignment and Aggregation Strategy", RFC 1338, BARRNet,
     cisco, Merit, OARnet, June 1992.
 [5] Wang, Z., and J. Crowcroft, "A Two-Tier Address Structure for the
     Internet: a solution to the problem of address space exhaustion",
     RFC 1335, University College London, May 1992.
 [6] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), a Simple
     Proposal for Internet Addressing and Routing", RFC 1347, DEC,
     June 1992.
 [7] Tsuchiya, P., "Pip: The 'P' Internet Protocol", Work in Progress,
     May 1992
 [8] Chiappa N., "A New IP Routing and Addressing Architecture", Work
     in Progress, 1992.
 [9] Colella, R., Gardner, E., and R. Callon, "Guidelines for OSI NSAP
     Allocation in the Internet" RFC 1237, NIST, Mitre, DEC, July
     1991.
[10] Deering, S., "City Codes: An Alternative Scheme for OSI NSAP
     Allocation in the Internet", Work in Progress, January 1992.
[11] Clark, D., "Building routers for the routing of tomorrow", in his
     message to Big-Interent@munnari.oz.au, 14 July 1992.
[12] Hinden, R., and D. Crocker, "A Proposal for IP Address
     Encapsulation (IPAE): A Compatible Version of IP with Large
     Addresses", Work in Progress, July 1992.

Wang [Page 11] RFC 1385 EIP November 1992

[13] Partridge, C., "Re: Note on implementing IPAE", in his message to
     Big-Interent@munnari.oz.au, 17 July 1992.
[14] Deering, S., "SIP: Simple Internet Protocol", Work in Progress,
     September 1992.
[15] Braden, R., Editor, "Requirements for Internet Hosts
      -- Communication Layers", RFC 1122, ISI, October 1989.
[16] Almquist, P., Editor, "Requirements for IP Routers", Work in
     Progress, October 1991.

Appendix

     Throughput Test from UCL (sartre.cs.ucl.ac.uk)
    Destination Host          test-noopt     test-opt
    -------------------        ----------     ---------
    oliver.cs.mcgill.ca          1.128756      1.285345
    oliver.cs.mcgill.ca          1.063096      1.239709
    bertha.cc.und.ac.za          0.094336      0.043917
    bertha.cc.und.ac.za          0.075681      0.057120
    vnet3.vub.ac.be              2.090622      2.228181
    vnet3.vub.ac.be              1.781374      1.692740
    itdsrv1.ul.ie                1.937596      2.062579
    itdsrv1.ul.ie                1.928313      1.936784
    sunic.sunet.se              11.064797     11.724055
    sunic.sunet.se              10.861720     10.840306
    pascal.acm.org               2.463790      0.810133
    pascal.acm.org               1.619088      0.860198
    iti.gov.sg                   1.565320      1.983795
    iti.gov.sg                   1.564788      1.921803
    rzusuntk.unizh.ch            9.903805     11.335920
    rzusuntk.unizh.ch            9.597806     10.678098
    funet.fi                     9.897876      9.382925
    funet.fi                    10.487118     11.023745
    odin.diku.dk                 5.851407      5.482946
    odin.diku.dk                 5.992257      6.243283
    cphkvx.cphk.hk               0.758044      0.844406
    cphkvx.cphk.hk               0.784532      0.745606
    bootes.cus.cam.ac.uk        28.341705     29.655824
    bootes.cus.cam.ac.uk        24.804125     23.240990
    pesach.jct.ac.il             1.045922      1.115802
    pesach.jct.ac.il             1.330429      0.978184
    sun1.sara.nl                10.546733     11.500778
    sun1.sara.nl                 9.624833     10.214136
    cocos.fuw.edu.pl             1.747777      1.702324
    cocos.fuw.edu.pl             1.676151      1.716435

Wang [Page 12] RFC 1385 EIP November 1992

    apple.com                    4.449559      4.145081
    apple.com                    6.431675      5.520443
    gorgon.tf.tele.no            1.199810      1.374546
    gorgon.tf.tele.no            0.508642      0.993261
    kogwy.cc.keio.ac.jp          3.626448      3.249590
    kogwy.cc.keio.ac.jp          3.913777      4.094849
    exu.inf.puc-rio.br           1.913925      1.795235
    exu.inf.puc-rio.br           1.154936      1.114775
    inria.inria.fr               2.299561      0.599665
    inria.inria.fr               1.219282      0.873672
    kum.kaist.ac.kr              0.252704      0.254199
    kum.kaist.ac.kr              0.236196      0.172367
    sunipc1.labein.es            1.398777      1.243588
    sunipc1.labein.es            0.876177      0.602964
    wifosv.wsr.ac.at             0.531153      0.803387
    wifosv.wsr.ac.at             0.773935      0.557798
    uunet.uu.net                 7.813556      6.764543
    uunet.uu.net                 7.969203      6.657325
    infnsun.aquila.infn.it       2.321197      2.402477
    infnsun.aquila.infn.it       2.400196      2.695016
    muttley.fc.ul.pt             0.545775      0.434672
    muttley.fc.ul.pt             0.284124      0.266017
    dmssyd.syd.dms.csiro.au      2.734685      2.857545
    dmssyd.syd.dms.csiro.au      1.168154      1.462789
    hamlet.caltech.edu           2.552804      2.897286
    hamlet.caltech.edu           3.839141      2.407945
    sztaki.hu                    0.294196      0.403697
    sztaki.hu                    0.236260      0.388755
    menvax.restena.lu            0.465066      0.515361
    menvax.restena.lu            0.358646      0.511985
    nctu.edu.tw                  0.484372      0.816722
    nctu.edu.tw                  0.705733      1.109228
    xalapa.lania.mx              0.899529      0.822544
    xalapa.lania.mx              1.150058      0.881713
    truth.waikato.ac.nz          1.438481      1.993749
    truth.waikato.ac.nz          1.325041      1.833999

Wang [Page 13] RFC 1385 EIP November 1992

       Throughput Test from Bellcore (latour.bellcore.com)
    Destination Host          test-noopt     test-opt
    ------------------        ----------     ---------
    oliver.cs.mcgill.ca          1.820014      2.128104
    oliver.cs.mcgill.ca          1.979981      1.866815
    bertha.cc.und.ac.za          0.099289      0.035877
    bertha.cc.und.ac.za          0.118627      0.103763
    vnet3.vub.ac.be              0.368476      0.694463
    vnet3.vub.ac.be              0.443269      0.644050
    itdsrv1.ul.ie                0.721444      0.960068
    itdsrv1.ul.ie                0.713952      0.953275
    sunic.sunet.se               2.989907      2.956766
    sunic.sunet.se               2.100563      2.010292
    pascal.acm.org               2.487185      3.896253
    pascal.acm.org               1.944085      4.269323
    iti.gov.sg                   2.401733      2.735445
    iti.gov.sg                   2.950990      2.793121
    rzusuntk.unizh.ch            4.094820      3.618023
    rzusuntk.unizh.ch            2.952650      2.245001
    funet.fi                     6.703408      5.928008
    funet.fi                     7.389722      5.815122
    odin.diku.dk                 2.094152      2.450695
    odin.diku.dk                 5.362362      4.690722
    cphkvx.cphk.hk               0.092698      0.106880
    cphkvx.cphk.hk               0.496394      0.681994
    bootes.cus.cam.ac.uk         2.632951      2.631322
    bootes.cus.cam.ac.uk         3.717170      1.335914
    pesach.jct.ac.il             0.684029      0.921621
    pesach.jct.ac.il             0.390263      1.095265
    sun1.sara.nl                 3.186035      2.325166
    sun1.sara.nl                 3.053797      3.081236
    cocos.fuw.edu.pl             0.154405      0.124795
    cocos.fuw.edu.pl             0.120283      0.105825
    apple.com                   12.588979     12.957880
    apple.com                   13.861733     12.211125
    gorgon.tf.tele.no            1.280217      1.112675
    gorgon.tf.tele.no            0.243205      0.631096
    kogwy.cc.keio.ac.jp          6.249789      5.075968
    kogwy.cc.keio.ac.jp          3.387490      4.583511
    exu.inf.puc-rio.br           2.089536      2.233711
    exu.inf.puc-rio.br           2.476758      2.249439
    inria.inria.fr               0.653974      0.866246
    inria.inria.fr               0.739127      1.130521
    kum.kaist.ac.kr              1.541682      1.312546
    kum.kaist.ac.kr              0.906632      1.042793
    sunipc1.labein.es            0.101496      0.091456
    sunipc1.labein.es            0.054245      0.101585

Wang [Page 14] RFC 1385 EIP November 1992

    wifosv.wsr.ac.at             1.044443      0.369528
    wifosv.wsr.ac.at             0.596935      0.870377
    uunet.uu.net                 9.530348      8.999789
    uunet.uu.net                 8.941888      6.075660
    infnsun.aquila.infn.it       1.619418      1.569645
    infnsun.aquila.infn.it       1.156780      1.158000
    muttley.fc.ul.pt             0.353632      0.416126
    muttley.fc.ul.pt             0.221522      0.155505
    dmssyd.syd.dms.csiro.au      3.433901      3.272839
    dmssyd.syd.dms.csiro.au      3.408975      3.130188
    hamlet.caltech.edu           5.367756      6.325031
    hamlet.caltech.edu           4.828718      5.676571
    sztaki.hu                    0.301120      0.362481
    sztaki.hu                    0.253222      0.519892
    menvax.restena.lu            0.364221      0.480789
    menvax.restena.lu            0.456882      0.580778
    nctu.edu.tw                  0.246523      1.199412
    nctu.edu.tw                  0.423476      0.630833
    xalapa.lania.mx              0.748642      0.607284
    xalapa.lania.mx              0.716781      0.643030
    truth.waikato.ac.nz          2.197595      2.072601
    truth.waikato.ac.nz          2.489748      2.186684

Wang [Page 15] RFC 1385 EIP November 1992

        Throughput Test from Cam U (cus.cam.ac.uk)
    Destination Host          test-noopt     test-opt
    ------------------        ----------     ---------
    oliver.cs.mcgill.ca           1.128756       1.285345
    oliver.cs.mcgill.ca           1.063096       1.239709
    bertha.cc.und.ac.za           0.031218       0.031221
    bertha.cc.und.ac.za           0.034405       0.034925
    vnet3.vub.ac.be               0.568487       0.731320
    vnet3.vub.ac.be               0.558238       0.581415
    itdsrv1.ul.ie                 1.064302       1.284707
    itdsrv1.ul.ie                 0.852089       1.025779
    sunic.sunet.se                7.179942       6.270326
    sunic.sunet.se                5.772485       6.689160
    pascal.acm.org                1.661248       1.726725
    pascal.acm.org                1.557839       1.428193
    iti.gov.sg                    0.600616       0.926690
    iti.gov.sg                    0.772887       0.956636
    rzusuntk.unizh.ch             3.645913       4.504969
    rzusuntk.unizh.ch             1.853503       2.671272
    funet.fi                      4.190147       3.421110
    funet.fi                      2.270988       3.789678
    odin.diku.dk                  1.361227       0.993901
    odin.diku.dk                  1.977774       2.415716
    cphkvx.cphk.hk                1.173451       1.298421
    cphkvx.cphk.hk                1.151376       1.184210
    bootes.cus.cam.ac.uk        269.589141     238.920081
    bootes.cus.cam.ac.uk        331.203020     293.556436
    pesach.jct.ac.il              0.343598       0.492202
    pesach.jct.ac.il              0.582809       0.930958
    sun1.sara.nl                  1.529277       1.470571
    sun1.sara.nl                  0.896041       0.894923
    cocos.fuw.edu.pl              0.131180       0.142239
    cocos.fuw.edu.pl              0.137697       0.148895
    apple.com                     1.330794       0.453590
    apple.com                     0.856476       0.714661
    gorgon.tf.tele.no             0.094793       0.099981
    gorgon.tf.tele.no             0.167257       0.151625
    kogwy.cc.keio.ac.jp           0.154681       0.178868
    kogwy.cc.keio.ac.jp           1.095814       0.871496
    exu.inf.puc-rio.br            0.454272       0.384484
    exu.inf.puc-rio.br            0.705198       0.690708
    inria.inria.fr                0.149511       0.150021
    inria.inria.fr                0.071125       0.077257
    kum.kaist.ac.kr               0.721184       0.549511
    kum.kaist.ac.kr               0.250285       0.296195
    sunipc1.labein.es             0.519284       0.491745
    sunipc1.labein.es             0.990174       1.009475

Wang [Page 16] RFC 1385 EIP November 1992

    wifosv.wsr.ac.at              0.360751       0.418554
    wifosv.wsr.ac.at              0.344268       0.326605
    uunet.uu.net                  4.247430       3.305592
    uunet.uu.net                  3.139251       2.945469
    infnsun.aquila.infn.it        0.480731       0.782631
    infnsun.aquila.infn.it        0.230471       0.292273
    muttley.fc.ul.pt              0.239624       0.334286
    muttley.fc.ul.pt              0.586156       0.419485
    dmssyd.syd.dms.csiro.au       3.630623       3.607504
    dmssyd.syd.dms.csiro.au       1.743162       2.994665
    hamlet.caltech.edu            5.897946       4.650703
    hamlet.caltech.edu            5.118200       5.622022
    sztaki.hu                     0.338358       0.225206
    sztaki.hu                     0.113328       0.112637
    menvax.restena.lu             0.224967       0.359237
    menvax.restena.lu             0.452945       0.472345
    nctu.edu.tw                   2.549709       2.037245
    nctu.edu.tw                   2.229093       2.469851
    xalapa.lania.mx               0.713586       0.810107
    xalapa.lania.mx               0.612278       0.731705
    truth.waikato.ac.nz           1.438481       1.993749
    truth.waikato.ac.nz           1.325041       1.833999

Security Considerations

 Security issues are not discussed in this memo.

Author's Address

 Zheng Wang
 Dept of Computer Science
 University College London
 London WC1E 6BT, UK
 EMail: z.wang@cs.ucl.ac.uk

Wang [Page 17]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1385.txt · Last modified: 1992/11/12 00:26 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki