From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1385.txt | 955 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 955 insertions(+) create mode 100644 doc/rfc/rfc1385.txt (limited to 'doc/rfc/rfc1385.txt') 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 -- cgit v1.2.3