summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1385.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1385.txt')
-rw-r--r--doc/rfc/rfc1385.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc1385.txt b/doc/rfc/rfc1385.txt
new file mode 100644
index 0000000..f96ccf7
--- /dev/null
+++ b/doc/rfc/rfc1385.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+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]
+ \ No newline at end of file